We've worked with the security and performance teams to re-evaluate the W^X policy
we have in place to mark JIT code memory pages as either writable or executable
(but not both).
Recommendation from the security team is to disable this mitigation in the content
process, because it's not worth the performance cost since there are known and reusable
techniques to bypass it. The V8 team has recently reached a similar conclusion.
We still leave write protection enabled in the parent process and other non-content
processes, because performance is less of a concern there and it's unclear if the techniques
to bypass this mitigation apply to these processes as well.
This patch adds a `javascript.options.content_process_write_protect_code` pref for this
and sets it to false. The JS shell has a new `--write-protect-code=off/on` flag. This
defaults to `on` for now to help catch W^X violations early on.
This is expected to improve performance on Speedometer 3 by about 3-4%. We've seen similar
numbers for other benchmarks including page load measurements.
Depends on D179468
Differential Revision: https://phabricator.services.mozilla.com/D179469
We've worked with the security and performance teams to re-evaluate the W^X policy
we have in place to mark JIT code memory pages as either writable or executable
(but not both).
Recommendation from the security team is to disable this mitigation in the content
process, because it's not worth the performance cost since there are known and reusable
techniques to bypass it. The V8 team has recently reached a similar conclusion.
We still leave write protection enabled in the parent process and other non-content
processes, because performance is less of a concern there and it's unclear if the techniques
to bypass this mitigation apply to these processes as well.
This patch adds a `javascript.options.content_process_write_protect_code` pref for this
and sets it to false. The JS shell has a new `--write-protect-code=off/on` flag. This
defaults to `on` for now to help catch W^X violations early on.
This is expected to improve performance on Speedometer 3 by about 3-4%. We've seen similar
numbers for other benchmarks including page load measurements.
Differential Revision: https://phabricator.services.mozilla.com/D179469
clang is warning that C++20 expects comparison operators to be commutative: `a == b` and `b == a` should resolve to the same comparison operator function. Warnings about the comparison of const and non-const objects can be fixed by making the comparison operator function const.
Depends on D179020
Differential Revision: https://phabricator.services.mozilla.com/D179021
Set the `--enable-change-array-by-copy` shell flag and the
`javascript.options.experimental.enable_change_array_by_copy` pref to true
by default in all builds.
Remove the `--enable-change-array-by-copy` build flag from `js/moz.configure`
and make all code previously guarded by `#ifdef ENABLE_CHANGE_ARRAY_BY_COPY`
compile unconditionally.
Remove `change-array-by-copy` from testing build configurations (non262
and jit-test tests are no longer guarded with
`getBuildConfiguration()['change-array-by-copy']`
Remove all code from test config files that sets
`javascript.options.experimental.enable_change_array_by_copy`; only
`StaticPrefList.yaml` should set this pref.
Fix non262 unscopables test that apparently wasn't running before to use
the correct names for change-array-by-copy methods
Remove the `TypedArray` property from `gPrototypeProperties` in
`test_xrayToJS.xhtml`, as this property was written but never read.
Differential Revision: https://phabricator.services.mozilla.com/D174699
Set the `--enable-change-array-by-copy` shell flag and the
`javascript.options.experimental.enable_change_array_by_copy` pref to true
by default in all builds.
Remove the `--enable-change-array-by-copy` build flag from `js/moz.configure`
and make all code previously guarded by `#ifdef ENABLE_CHANGE_ARRAY_BY_COPY`
compile unconditionally.
Remove `change-array-by-copy` from testing build configurations (non262
and jit-test tests are no longer guarded with
`getBuildConfiguration()['change-array-by-copy']`
Remove all code from test config files that sets
`javascript.options.experimental.enable_change_array_by_copy`; only
`StaticPrefList.yaml` should set this pref.
Fix non262 unscopables test that apparently wasn't running before to use
the correct names for change-array-by-copy methods
Remove the `TypedArray` property from `gPrototypeProperties` in
`test_xrayToJS.xhtml`, as this property was written but never read.
Differential Revision: https://phabricator.services.mozilla.com/D174699
Improves the clarity of defineLazyPreferenceGetter by resolving
ambiguity around the intended type of parameter aDefaultValue
Differential Revision: https://phabricator.services.mozilla.com/D178828
Set the `--enable-change-array-by-copy` shell flag and the
`javascript.options.experimental.enable_change_array_by_copy` pref to true
by default in all builds.
Remove the `--enable-change-array-by-copy` build flag from `js/moz.configure`
and make all code previously guarded by `#ifdef ENABLE_CHANGE_ARRAY_BY_COPY`
compile unconditionally.
Remove `change-array-by-copy` from testing build configurations (non262
and jit-test tests are no longer guarded with
`getBuildConfiguration()['change-array-by-copy']`
Remove all code from test config files that sets
`javascript.options.experimental.enable_change_array_by_copy`; only
`StaticPrefList.yaml` should set this pref.
Fix non262 unscopables test that apparently wasn't running before to use
the correct names for change-array-by-copy methods
Remove the `TypedArray` property from `gPrototypeProperties` in
`test_xrayToJS.xhtml`, as this property was written but never read.
Differential Revision: https://phabricator.services.mozilla.com/D174699