Would it work to sample the compartment checks? Make them a no-op for 999/1000 of the cases? You'd probably find the ones you cared about, if the (annotated) crash reports are what you need. Could even submit a "soft crash".
phone-typed On Nov 21, 2012, at 1:44 PM, Boris Zbarsky <[email protected]> wrote: > On 11/21/12 2:13 PM, Bobby Holley wrote: > >> 1 - Objects cannot reach cross-compartment objects without going through a >> cross-compartment wrapper (and thus receiving a security audit from >> XPConnect). > > This is empirically false in Gecko. See testcase in your email. > > This invariant _would_ be true if we exercised all possible codepaths in our > tests; then our compartment-mismatch assertions would catch it. But we don't > exercise all codepaths in our tests... > > So we've replaced one sort of whack-a-mole with another, slightly more > manageable one: JS_WrapValue/Object whack-a-mole, hopefully enforced by > sufficient test coverage. > > The question is whether we can do anything better. And maybe not involving > the performance pain of JS_WrapValue/Object.... > >> Now, the flip side of this is that same operations that could have >> potentially violated the above invariants now manifest themselves as >> compartment mismatches. > > Which are not fatal in release builds, note. > >> But I contend that this is much better than the alternative > > Sure. > >> I think these invariants are extremely important, and I haven't thought of >> a way to make them happen without callers being minimally aware of them (in >> the sense of 'enter a compartment'). > > I think the long-term path forward here is to excise all non-binding JSAPI > usage from the DOM, because I'm becoming more and more convinced that there > are too many footguns in JSAPI that people are just not aware of. And trying > to make them aware is a waste of resources, in my opinion, especially as the > set of things to be aware of keeps changing. > >> then I think we should just make compartment checking run on release builds > > I doubt the perf hit there is acceptable, unfortunately. :( > > -Boris > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
