Closed
Bug 1129013
Opened 10 years ago
Closed 10 years ago
Enable cross-compartment checks by default and put it on the trains
Categories
(Core :: JavaScript: GC, defect)
Core
JavaScript: GC
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: terrence, Assigned: terrence)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
It is time.
Assignee | ||
Comment 1•10 years ago
|
||
Attachment #8558615 -
Flags: review?(wmccloskey)
I'd like to see some measurements about how this affects benchmark scores (and not just shell tests).
Assignee | ||
Comment 3•10 years ago
|
||
Good thought! Let's see if it survives talos:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=98926fca2aa1
You're comparing to nightly, where compartment checks are already enabled.
Comment 5•10 years ago
|
||
What do we gain from this, exactly? Are we actually seeing many compartment mismatches these days?
Well, the benefit to having them on by default is that compartment mismatches would no longer be security bugs.
Even if we don't enable them on release, it might be nice to enable them on beta. It seems like we might get a lot more weird add-on usage there.
But no, I don't think we see them much at all on crash-stats. Andrew was telling me last week that he was worried we don't see any, which might be a signal that something is broken in the reporting.
Updated•10 years ago
|
Target Milestone: flash10 → ---
Comment 7•10 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #6)
> Well, the benefit to having them on by default is that compartment
> mismatches would no longer be security bugs.
Well, mismatches that we assert against. I'm concerned that we'll also want to assert against them in performance-critical cases (stuff used in dom bindings for example), and then we'll need 2 kinds, and then we'll always have to decide which to use.
> Even if we don't enable them on release, it might be nice to enable them on
> beta. It seems like we might get a lot more weird add-on usage there.
This is fair, though I think beta is supposed to behave as much like release as possible.
> But no, I don't think we see them much at all on crash-stats. Andrew was
> telling me last week that he was worried we don't see any, which might be a
> signal that something is broken in the reporting.
Or maybe the couple of buggy addons finally got marked incompatible or something, or maybe we've just removed enough of the old codepaths that were crashing (like the stuff in nsDOMClassInfo). In general, the only addons that can create unavoidable mismatches are binary addons, of which there are fewer and fewer. Script-only addons can't create compartment mismatches if we don't have bugs.
Comment 8•10 years ago
|
||
Even before they disappeared entirely, there was just a thin smattering of these crashes, where you'd see one or two that looked like one thing, and another that looked like another. This included things like the JS interpreter.
Comment on attachment 8558615 [details] [diff] [review]
enable_xcompartment_checks_by_default-v0.diff
Canceling this for now.
Attachment #8558615 -
Flags: review?(wmccloskey)
Assignee | ||
Comment 10•10 years ago
|
||
It seems we're happy enough with the status-quo here for now.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•