On 08/09/2013 02:59 PM, Jim Blandy wrote:
Ivan Alagenchev and Mark Goodwin asked me to take a look at their project to bring DOMinator, a taint analysis for SpiderMonkey, […]
On Tuesday, Koushik Sen made a presentation which is available on Air Mozilla[1] where he presented some JavaScript instrumentation which use some parser-hook to rewrite the original script with some extensible instrumentation.
In his presentation, he highlights that only hundreds of lines are necessary to instrument a few parts of the engine with one kind of analysis. One of the example is tainting analysis, which is made such as it works on objects.
The parser hook, is used to transform the source such as it can replace JavaScript operations by functions calls which are doing the original operation. The example given in the presentation is that 'x + y' is transformed to Binary('+', x, y).
I think this is the kind of problem that we can address at the Bytecode emitter level. We could make a second bytecode emitter which generates calls into some non-instrumented code registered for the analysis. I think we could require that the analysis must be loaded ahead of time and only generate hooks if there is any instrumentation.
This approach would be way slower than the tainting suggested by the DOMinator project, but at the same time it serves a generic purpose for instrumenting the engine in any customizable way.
As he suggested in the presentation, we might want to make this visible to the user. Which means that we need to think of a way to provide some differential testing, such as analysis developers can check that they are not changing the behavior of the manipulated program (unless expected).
[1] https://air.mozilla.org/test-and-cure-your-javascript-blues-with-jalangi/ -- Nicolas B. Pierron _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
