V8 Sandbox feature
mlafeldt opened this issue · 4 comments
After reading https://v8.dev/blog/sandbox, I wonder whether you plan to enable the sandbox feature anytime soon?
The V8 Sandbox is a new security mechanism designed to prevent memory corruption in V8 from impacting other memory in the process. The sandbox is motivated by the fact that current memory safety technologies are largely inapplicable to optimizing JavaScript engines. While these technologies fail to prevent memory corruption in V8 itself, they can in fact protect the V8 Sandbox attack surface. The sandbox is therefore a necessary step towards memory safety.
It's currently disabled:
Line 33 in 89fbf2a
And needs to be enabled at build time:
The V8 Sandbox must be enabled/disabled at build time using the v8_enable_sandbox build flag. It is (for technical reasons) not possible to enable/disable the sandbox at runtime. The V8 Sandbox requires a 64-bit system as it needs to reserve a large amount of virtual address space, currently one terabyte.
The V8 Sandbox has already been enabled by default on 64-bit (specifically x64 and arm64) versions of Chrome on Android, ChromeOS, Linux, macOS, and Windows for roughly the last two years. Even though the sandbox was (and still is) not feature complete, this was mainly done to ensure that it does not cause stability issues and to collect real-world performance statistics. Consequently, recent V8 exploits already had to work their way past the sandbox, providing helpful early feedback on its security properties.
Thanks!
I already found one complication: v8_enable_sandbox requires v8_enable_pointer_compression, which was disabled in #1302 due to a mem leak.
diff --git .gn .gn
index f7097dd..0c1f746 100644
--- .gn
+++ .gn
@@ -30,7 +30,7 @@ default_args = {
symbol_level = 1
use_debug_fission = false
- v8_enable_sandbox = false
+ v8_enable_sandbox = true
v8_enable_javascript_promise_hooks = true
v8_promise_internal_field_count = 1
v8_use_external_startup_data = false
@@ -63,7 +63,7 @@ default_args = {
# be cleaned which causes resource exhaustion. Disabling pointer compression
# makes sure that the EPT is not used.
# https://bugs.chromium.org/p/v8/issues/detail?id=13640&q=garbage%20collection&can=2
- v8_enable_pointer_compression = false
+ v8_enable_pointer_compression = true
# Maglev *should* be supported when pointer compression is disabled as per
# https://chromium-review.googlesource.com/c/v8/v8/+/4753150, but it still
@wingo is working on a fix for the memory leak, which will hopefully allow us to re-enabling pointer compression.
ref
https://bugs.chromium.org/p/v8/issues/detail?id=13640
https://chromium-review.googlesource.com/c/v8/v8/+/5185345
Fix has been completed. Andy wrote a blog post about it https://wingolog.org/archives/2024/05/13/partitioning-pitfalls-for-generational-collectors
We're waiting for a new V8 LKGR before re-enabling pointer compression.