You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can nicely disable taint tracking (i.e., introducing taints at sources) via about.config. Therefore, we can directly analyze whether our changes introduce performance penalties even in the complete absence of any tainted values.
I was playing with the built-in benchmarks, primarily jetstream2, and noticed something strange.
When running the above, the resulting numbers barely differed between setting tainting.active to false or true. This means that disabling tainting does not gain any performance benefit, which was somewhat unexpected.
Thankfully, profiling this is straightforward. Adding the --extra-profiler-run flag stores symbolized profiling data, which you can analyze under profiler.firefox.com/. Here, the culprit became obvious right away.
Generally, when tracking taints, the expensive part is creating the TaintOperation object. One would assume that if tainting is disabled, we do not need to create any of those. This is a misconception, however.
voidJS::MarkTaintedFunctionArguments(JSContext* cx, JSFunction* function, const CallArgs& args)
{
if (!function)
return;
RootedValue name(cx);
JS::Rooted<JSAtom*> atom(cx);
if (function->getDisplayAtom(cx, &atom)) {
name = StringValue(atom);
}
RootedFunction fun(cx, function);
std::u16string sourceinfo(u"unknown");
if (fun->isInterpreted() && fun->hasBaseScript()) {
RootedScript script(cx, JSFunction::getOrCreateScript(cx, fun));
if (script) {
int lineno = script->lineno();
js::ScriptSource* source = script->scriptSource();
if (source && source->filename()) {
std::string filename(source->filename());
sourceinfo = ascii2utf16(filename) + u":" + ascii2utf16(std::to_string(lineno));
}
}
}
TaintLocation location = TaintLocationFromContext(cx);
for (unsigned i = 0; i < args.length(); i++) {
if (args[i].isString()) {
RootedString arg(cx, args[i].toString());
if (arg->isTainted()) {
arg->taint().extend(
TaintOperation("function", location,
{ taintarg(cx, name), sourceinfo, taintarg(cx, i), taintarg(cx, args.length()) } ));
}
}
}
}
Here, the TaintLocation object (the expensive part of the TaintOperation object) is created regardless of whether any argument string is actually tainted. I will prepare a PR later today where we bail out before creating any expensive objects if none of the arguments is a tainted string. Currently measuring the performance impact of doing so.
The text was updated successfully, but these errors were encountered:
We can nicely disable taint tracking (i.e., introducing taints at sources) via
about.config
. Therefore, we can directly analyze whether our changes introduce performance penalties even in the complete absence of any tainted values.I was playing with the built-in benchmarks, primarily
jetstream2
, and noticed something strange.When running the above, the resulting numbers barely differed between setting
tainting.active
to false or true. This means that disabling tainting does not gain any performance benefit, which was somewhat unexpected.Thankfully, profiling this is straightforward. Adding the
![Profiling Output](https://private-user-images.githubusercontent.com/49810/388845458-5e80fdd1-a501-4e91-8d35-119b4b6f9f8b.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg5NTY3ODMsIm5iZiI6MTczODk1NjQ4MywicGF0aCI6Ii80OTgxMC8zODg4NDU0NTgtNWU4MGZkZDEtYTUwMS00ZTkxLThkMzUtMTE5YjRiNmY5ZjhiLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA3VDE5MjgwM1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWYxMGY5YjM0MmNhZTM1NWRhODBhNWQxNzU2YmMxNmRhZDYyMDY1MmM1Y2FjZmMwODUxZDkwZDVhYzhkMWQ3YWYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.pY7xxZCTwvgnsS1k2SW1mTuSmOBXMROjFQkWLv2WAMo)
--extra-profiler-run
flag stores symbolized profiling data, which you can analyze under profiler.firefox.com/. Here, the culprit became obvious right away.Generally, when tracking taints, the expensive part is creating the
TaintOperation
object. One would assume that if tainting is disabled, we do not need to create any of those. This is a misconception, however.Here, the TaintLocation object (the expensive part of the
TaintOperation
object) is created regardless of whether any argument string is actually tainted. I will prepare a PR later today where we bail out before creating any expensive objects if none of the arguments is a tainted string. Currently measuring the performance impact of doing so.The text was updated successfully, but these errors were encountered: