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
The motivation for this change is for metering, which is related to coverage analysis instrumentation.
In coverage analysis instrumentation, compartments need:
a global that can capture coverage information
a transform that converts every expression into an equivalent expression that also notes coverage information.
For example, the expression value would be transformed to (coverage._x0fd++, value), where the arbitrary key _x0fd uniquely identifies the expression.
For coverage analysis, we might not be worried about user code “attacking” their coverage analysis, so adding coverage to globalThis is sufficient. However, user code could alter its coverage results by including the statement coverage._x0fd = 1e10, for example.
The coverage tooling can censor the word coverage, throwing an exception if the user code includes this word anywhere. This would even frustrate user code that attempted to reach for coverage through computing an evaluated string, likee (0, eval("cov" + "er" + "age")), because within the compartment, the argument to eval is itself user code subject to all the compartment’s transforms.
This is not sufficient because user code can still compute properties of globalThis, like globalThis["cov" + "er" + "age"]. A transform that virtualizes all computed properties would be impractically slow. So, instead, we propose that the Compartment constructor accept a globalLexicals option. The global lexicals would exist in a scope that overshadows globalThis but cannot be named in that scope. By using globalLexicals instead of globalThis, banning the word “coverage” is sufficient to prevent user code from manipulating this special register.
The compartment constructor must capture a snapshot of the given global lexicals and present these as constants in the scope of all modules and all evaluated code. Changes to the given global lexicals should not be observable. An accessor property on a global lexical must be called exactly once in the scope of the constructor.
This proposal bears a resemblance to the concept hitherto named “global contour” #34. Ideally global lexicals and the global contour could be reconciled into a single feature, though that requires reconciling the immutability of global lexicals with the mutability of the global contour, and that the global contour must be manipulated by evaluated code should not be observable in modules.
The text was updated successfully, but these errors were encountered:
The motivation for this change is for metering, which is related to coverage analysis instrumentation.
In coverage analysis instrumentation, compartments need:
For example, the expression
value
would be transformed to(coverage._x0fd++, value)
, where the arbitrary key_x0fd
uniquely identifies the expression.For coverage analysis, we might not be worried about user code “attacking” their coverage analysis, so adding
coverage
toglobalThis
is sufficient. However, user code could alter its coverage results by including the statementcoverage._x0fd = 1e10
, for example.The coverage tooling can censor the word
coverage
, throwing an exception if the user code includes this word anywhere. This would even frustrate user code that attempted to reach forcoverage
through computing an evaluated string, likee(0, eval("cov" + "er" + "age"))
, because within the compartment, the argument toeval
is itself user code subject to all the compartment’s transforms.This is not sufficient because user code can still compute properties of
globalThis
, likeglobalThis["cov" + "er" + "age"]
. A transform that virtualizes all computed properties would be impractically slow. So, instead, we propose that the Compartment constructor accept aglobalLexicals
option. The global lexicals would exist in a scope that overshadowsglobalThis
but cannot be named in that scope. By usingglobalLexicals
instead ofglobalThis
, banning the word “coverage” is sufficient to prevent user code from manipulating this special register.The compartment constructor must capture a snapshot of the given global lexicals and present these as constants in the scope of all modules and all evaluated code. Changes to the given global lexicals should not be observable. An accessor property on a global lexical must be called exactly once in the scope of the constructor.
This proposal bears a resemblance to the concept hitherto named “global contour” #34. Ideally global lexicals and the global contour could be reconciled into a single feature, though that requires reconciling the immutability of global lexicals with the mutability of the global contour, and that the global contour must be manipulated by evaluated code should not be observable in modules.
The text was updated successfully, but these errors were encountered: