528968 - typeof hook addition

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, enhancement)

Description

[Eric Hennigan]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9
Build Identifier: Trunk

For security purposes we need a way to allow an object to transparently wrap a primitive. For wrapped primitives typeof should return the type of the underlying primitive.

Reproducible: Always

Comment 1

[Brendan Eich [:brendan]]

See bug 408416. We can make patch-wise progress as part of a grand plan. It may be best for JSClass to grow a typeof hook. Thoughts?

/be

Comment 2

[Jeff Walden [:Waldo]]

typeof hooks sound perhaps reasonable (but I do worry about unexpected typeofs breaking old code that doesn't expect a typeof outside the ones in the standard, and maybe outside xml as well), but intentionally adding this to support faking primitives sets off perf warning bells in my mind.  I sense slow boxing and unboxing coming back to bite us when we start doing that.

Comment 3

[Brendan Eich [:brendan]]

This is not about unexpected typeof operator string results -- we can phrase the UI in terms of the JSType enum. This is (currently) about security research that needs transparent "boxing" of cross-domain primitive values in order to carry a trust label with the value.

This "boxing cross-domain primitive values" path is a slow path, no doubt about it, but it is alleged to be rare (we'll measure), and we are not increasing its frequency by adding a typeof hook -- we are simply making it possible to track at all. Right now there's no possibility of labeling such data.

/be

Comment 4

[Brendan Eich [:brendan]]

See https://wiki.mozilla.org/index.php?title=FlowSafe and docs Eric may have up at UCI for more.

/be

Comment 5

[Mike Shaver (:shaver emeritus)]

Not to argue against the hook, which I support as long as it doesn't impact the fast single-domain paths, but it seems like we could carry the trust label out of band by segregating allocations from separate trust domains in separate address ranges?  That might not be any more efficient, of course -- I don't fully understand how the primitives are meant to mix, or interact with unit strings and so forth.

Comment 6

[Brendan Eich [:brendan]]

(In reply to comment #5)
> Not to argue against the hook, which I support as long as it doesn't impact the
> fast single-domain paths, but it seems like we could carry the trust label out
> of band by segregating allocations from separate trust domains in separate
> address ranges?

What allocation? Consider boolean and int jsvals.

> That might not be any more efficient, of course -- I don't
> fully understand how the primitives are meant to mix, or interact with unit
> strings and so forth.

For heap-allocated values the GC's page or segment may still be too coarse grained, and without a copying GC *and* the ability to tolerate multiple copies to migrate primitives (one by one, worst case) to their own pages or segments, in order to have the correct trust label (which also increases fragmentation, internal fragmentation that is), there's no way to deal with the "adoptNode" case involving primitive data hand-off cross-domain.

Wrapping (overloaded; "transparent boxing", ugh; need a better verb) is needed at the limit.

/be

Comment 7

[Brendan Eich [:brendan]]

The typeof hook would clean up random logic messes in jsapi.cpp and possibly a few other places, so it's good on its own, phrased in terms of the JSType enum.

/be

Comment 8

[Brendan Eich [:brendan]]

Alternative to using objects to box primitive values transparently entail yet another jsval type or subtype (JSVAL_SPECIAL awaits). But adding that *does* hurt many code paths that want to be fast and have fixed extension points alongside faster inextensible cases (NativeToValue, ValueToNative, etc. in the JIT).

Objects are not obviously too heavyweight. The only issue is how they lack the needed transparency, not only with typeof of course -- also ToBoolean(anyobj) => true in ES1-5 and our code. That's a topic for another bug.

Besides the security research agenda, this bug serves a "value types" Harmony agenda item. It could block tracking bugs for both projects. I owe a "value types ad-hoc meeting notes" post to es-discuss, which I'll do this week after fixing some bugs.

/be

Comment 9

[Mike Shaver (:shaver emeritus)]

Yep, totally like the hook.  I hadn't thought of boolean and int cases, and clearly need to read the wiki page to understand how domain1(5) == domain2(5) is to evaluate, etc.

(I was thinking of smaller-than-GC-page regions, and that we would allocate a new string/double primitive when there was a handoff that was meant to import to the new domain, but that's all trumped by the fact that it doesn't work in the first place!)

Comment 10

[Jason Orendorff [:jorendorff]]

This will end up touching the slow paths in every arithmetic opcode. Any operator overloading proposal would want to add hooks in many of the same places.

I imagine the intent is for `domain1(5) == 5` to evaluate to `domain1(true)`. That calls for Python-like "rich comparisons" at the implementation level, even if the capability is not exposed to scripts.