Longer term, I think we should consider putting all synchronously-accessible realms in the same compartment which would mean content never observed a transparent wrapper. (There are important security/testing/defense-in-depth questions to answer here, but iirc, there are reasonable answers.) Unfortunately, this wouldn't remove most of the wrapper goo in the engine since it sounds like there is still a lot of use of (full or partial) transparent wrapping from Web Extensions and Chrome JS, but it would mean that we wouldn't have to do backflips to support every last pathological spec corner case since the transparent wrappers would only need to be Good Enough.
On Mon, Sep 10, 2018 at 9:13 AM, Lars Hansen <lhan...@mozilla.com> wrote: > Right, and we don't even need to throw: type testing just fails when we > try to unbox anyref and we get a failed downcast; other ref types can't > cross the JS->wasm boundary at all at the moment. So it's literally zero > effort to deal with this now, I'm more worried about the longer term. > > --lars > > On Mon, Sep 10, 2018 at 3:57 PM, Luke Wagner <lwag...@mozilla.com> wrote: > >> You're right that, to correctly handle transparent wrappers, wasm would >> have to do a lot of work to deal with them (they can't simply be unwrapped) >> and I agree that we don't want to do that. >> >> After Jan's work, the only case where normal Web content would see >> transparent wrappers would be the case where two origins started >> different-origin and then both set document.domain to dynamically become >> same-origin... and an object created in one flowed into the other. So I >> this is why I think bholley is right that we can just punt and throw for >> now. >> >> On Mon, Sep 10, 2018 at 6:30 AM, Lars Hansen <lhan...@mozilla.com> wrote: >> >>> I don't know enough about wrappers yet to have a definite opinion, but >>> it's >>> my understanding that if I encounter a wrapper I can't just unwrap the >>> value and pass the resulting pointer on and let it escape unwrapped back >>> into content. If that is so, then we have a problem, because it means >>> that >>> potentially every typed reference in wasm may need to be unwrapped, and >>> this will greatly increase the cost of all pointer operations in wasm, >>> notably field accesses through them. At the moment references are >>> nullable >>> so we always pay for a null check but we hope to allow code generators to >>> ask for non-nullable pointers too; at which point a field reference is a >>> single indirect load. And indeed when there is a null check it might >>> well >>> be handleable as a trap, the way we handle OOB accesses already. >>> >>> (If I'm mistaken, and it's ok to unwrap something and let it stay >>> unwrapped >>> and let the unwrapped pointer escape back into content, then things are >>> much simpler, as the unwrapping can take place during the unboxing from >>> anyref -> typed ref.) >>> >>> --lars >>> >>> On Fri, Sep 7, 2018 at 7:56 PM, Bobby Holley <bobbyhol...@gmail.com> >>> wrote: >>> >>> > I don't think we're anywhere close to a point where transparent >>> wrappers >>> > (js::CrossCompartmentWrapper) will go away, or can be ignored by SM >>> devs. >>> > Even after Jan's changes, we'll still use them for lots of things >>> > (including Chrome->Content XrayWaivers). >>> > >>> > For stuff that's super edge-casey, it may be ok to punt and throw, but >>> we >>> > don't want to get ourselves into a situation where CCWs gradually stop >>> > working because devs stop caring about them. They're an important >>> > engineering tool, and I don't doubt that we'll continue to rely on >>> them and >>> > find new uses. >>> > >>> > On Fri, Sep 7, 2018 at 2:11 AM Lars Hansen <lhan...@mozilla.com> >>> wrote: >>> > >>> >> Thanks. Same-origin should be plenty good for what I'm doing. >>> >> >>> >> In the mean time, trapping / throwing when attempting to unbox an >>> anyref >>> >> that needs to be unwrapped is probably fine. >>> >> >>> >> --lars >>> >> >>> >> On Fri, Sep 7, 2018 at 11:05 AM, Jan de Mooij <jdemo...@mozilla.com> >>> >> wrote: >>> >> >>> >> > On Fri, Sep 7, 2018 at 10:47 AM, Lars Hansen <lhan...@mozilla.com> >>> >> wrote: >>> >> > >>> >> >> So: what's the story, and what's the status? >>> >> >> >>> >> > >>> >> > Bug 1357862 will eliminate a lot of wrappers (it requires some Gecko >>> >> > changes still before we can enable it), but it will only get rid of >>> >> > same-origin wrappers at first. There has been some discussion about >>> >> > follow-up work to eliminate more wrappers, but I don't know if/when >>> that >>> >> > will happen. >>> >> > >>> >> > Jan >>> >> > >>> >> > >>> >> >> >>> >> >> --lars >>> >> >> _______________________________________________ >>> >> >> dev-tech-js-engine-internals mailing list >>> >> >> dev-tech-js-engine-internals@lists.mozilla.org >>> >> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals >>> >> >> >>> >> > >>> >> > >>> >> _______________________________________________ >>> >> dev-tech-js-engine-internals mailing list >>> >> dev-tech-js-engine-internals@lists.mozilla.org >>> >> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals >>> >> >>> > >>> _______________________________________________ >>> dev-tech-js-engine-internals mailing list >>> dev-tech-js-engine-internals@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals >>> >> >> > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
