- 07 Jul, 2022 1 commit
-
-
Manos Koukoutos authored
Mostly src/codegen, src/compiler, src/snapshot, src/utils. Bug: v8:13006 Change-Id: I2fb31acc749a7376e6f2a7424ed2e67ff479d971 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749178 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81575}
-
- 27 Jun, 2022 2 commits
-
-
Samuel Groß authored
The ExternalPointerTags are assumed to be compile-time constants in most cases, so turning them into template parameters enforces that. As decisions such as whether to use the per-isolate or the shared external pointer table are encoded into the tag values, forcing those to be compile-time constants guarantees that the compiler will be able to inline the correct logic when accessing an external pointer. With this, there are now two (high-level) ways of accessing external pointer fields from C++: the Read/WriteExternalPointerField methods which require the ExternalPointerTag to be a template parameter, and the ExternalPointerSlot class which takes the tag as an argument. The latter is for example used for snapshot deserialization and by the garbage collector (more generally, by the ObjectVisitor::VisitExternalPointer method), where the tag is not a compile-time constant. Finally, this CL also introduces a new ExternalPointerHandle type which represents the (opaque) on-heap representation of a reference to an entry in an ExternalPointerTable when sandboxing is enabled. Making this its own type makes the code a bit more readable. Bug: v8:10391 Change-Id: I867b8ce41d15d485f1dc66786f233c710c56afcb Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3720641Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#81402}
-
Samuel Groß authored
Instead of creating smaller sandboxes when the allocation of the virtual address space reservation fails, we now create partially-reserved sandboxes and halve the reservation size until the initialization succeeds. That way, the unreserved part of the sandbox can still be used for allocating objects. Bug: v8:10391 Change-Id: I89a7790ffcda87ab71cc7b7f1101c0a1c3c62829 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714241Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#81379}
-
- 23 Jun, 2022 1 commit
-
-
Patrick Thier authored
To be able to share external strings, we need to share the external pointer table in sandbox builds. To avoid branches at runtime all pointers for external strings are stored in the shared external pointer table. Bug: v8:12957 Change-Id: Iaa6be7839a2f5e50f80fd58c5b33fb9c6af61057 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695263Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#81324}
-
- 21 Jun, 2022 1 commit
-
-
Samuel Groß authored
This is a reland of commit 5b9401dd Now also skip tests that require large amounts of virtual address space if tsan is enabled as tsan may cause V8 to create a smaller sandbox which is then unable to allocate the required amount of memory. Original change's description: > [sandbox] Also enable the sandbox outside of Chromium builds > > Drive-by: include the right header in sandboxed-pointer-inl.h and fix > missing sandbox initialization in generate-bytecode-expectations.cc. > > Bug: v8:10391 > Change-Id: Ic39ba04b7c98eaa58ea3943189c23b297f581f5a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630082 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Samuel Groß <saelo@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81216} Bug: v8:10391 Change-Id: I141080fdf61a77ef48b22e353e3cfbc1ff816e5a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3716474Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#81277}
-
- 20 Jun, 2022 1 commit
-
-
Nico Hartmann authored
This reverts commit 5b9401dd. Reason for revert: A few memory tests flake on tsan (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/20190/overview) Original change's description: > [sandbox] Also enable the sandbox outside of Chromium builds > > Drive-by: include the right header in sandboxed-pointer-inl.h and fix > missing sandbox initialization in generate-bytecode-expectations.cc. > > Bug: v8:10391 > Change-Id: Ic39ba04b7c98eaa58ea3943189c23b297f581f5a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630082 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Samuel Groß <saelo@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81216} Bug: v8:10391 Change-Id: I22560a6bdcffbf71651f655bdf7d183d5c832620 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3714239 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#81256}
-
- 17 Jun, 2022 3 commits
-
-
Shu-yu Guo authored
Bug: v8:12547 Change-Id: I94697ebf41ce5c132ad4bfc6472b9fc925d1f176 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3709240Reviewed-by:
Samuel Groß <saelo@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#81224}
-
Samuel Groß authored
Bug: v8:12878 Change-Id: I79ca182fcf59f520cdf8f25dd0daac9ced07881a Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3707283 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#81222}
-
Samuel Groß authored
Drive-by: include the right header in sandboxed-pointer-inl.h and fix missing sandbox initialization in generate-bytecode-expectations.cc. Bug: v8:10391 Change-Id: Ic39ba04b7c98eaa58ea3943189c23b297f581f5a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630082Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#81216}
-
- 15 Jun, 2022 2 commits
-
-
Adam Klein authored
Extend V8_OS_LINUX ifdef guards to surround PrintToStderr() helper. Change-Id: Ia27d532eef60aa162b99c6989b1312515a038110 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3708021 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/main@{#81197}
-
Samuel Groß authored
SIGABRT is harmless as it indicates a CHECK failure. Further, memory access violations at non-canonical addresses and memory permission violations should be ignored as well as they can legitimately be triggered from memory corruption inside the sandbox and are not directly exploitable. See code comments for more details. Bug: v8:12878 Change-Id: Idddd805f5d52c87f2b67a974716acd5d5abf11cf Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3707106Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#81191}
-
- 10 Jun, 2022 1 commit
-
-
Igor Sheludko authored
... into VisitExternalPointer(HeapObject, ExternalPointerSlot, ExternalPointerTag). Drive-by: introduce ExternalPointerSlot - a slot containing an ExternalPointer_t value. This cleanup is a prerequisite for inlining Foreign object fields into field's holder objects. Bug: v8:12949 Change-Id: Ifd74ed285796b0952d7d06de82b56c63fd1f7f3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695361Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#81064}
-
- 08 Jun, 2022 1 commit
-
-
Samuel Groß authored
If enabled, a signal handler is installed which intercepts memory access violations (e.g. SIGSEGV) and checks whether they occurred inside the sandbox address space, in which case the process is terminated cleanly as this does not represent a (security) issue with the sandbox. However, if the access violation occurred outside the sandbox, the access violation is forwarded to the original signal handler. The filter can be enabled in d8 by specifying --enable-sandbox-crash-filter. Bug: v8:12878 Change-Id: If9d76267e90ee79ee81ab793d7774afed6226b7c Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688408Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#80999}
-
- 07 Jun, 2022 1 commit
-
-
Samuel Groß authored
When the sandbox cannot be initialized, it's either because there is not enough virtual address space available, or because there is not enough memory for the kernel data structures needed for the reservation (this typically happens on Windows 7/8 where reserving virtual memory is expensive). Both cases should be reported as OOMs, not CHECK failures. Bug: chromium:1325302 Change-Id: I17bde9bcd4fbd6e3d54075b8891287c8fb01c1d7 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688406 Auto-Submit: Samuel Groß <saelo@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#80975}
-
- 20 May, 2022 1 commit
-
-
Samuel Groß authored
When enabled, this API exposes a new global 'Sandbox' object which contains a number of functions and objects that in effect emulate typical memory corruption primitives constructed by exploits. In particular, the 'MemoryView' constructor can construct ArrayBuffers instances that can corrupt arbitrary memory inside the sandbox. Further, the getAddressOf(obj) and getSizeInBytesOf(obj) functions can be used respectively to obtain the address (relative to the base of the sandbox) and size of any HeapObject that can be accessed from JavaScript. This API is useful for testing the sandbox, for example to facilitate developing PoC sandbox escapes or writing regression tests. In the future, it may also be used by custom V8 sandbox fuzzers. Bug: v8:12878 Change-Id: I4e420b2ff28bd834b0693f1546942e51c71bfdda Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3650718Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#80659}
-
- 16 May, 2022 1 commit
-
-
Samuel Groß authored
This CL removes some deprecated sandbox APIs and introduces new ones, in particular IsSandboxInitialized and GetSandboxReservationSizeInBytes. In additon, this CL also adds comments to the various public methods of the Sandbox class. Bug: v8:10391 Change-Id: If5c3081a0b9f7f192966150a0d2716099357363a Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647362Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#80544}
-
- 13 May, 2022 2 commits
-
-
Samuel Groß authored
This is more consistent with similar features, for example V8_ENABLE_WEBASSEMBLY or V8_ENABLE_MAGLEV. Drive-by: remove V8_SANDBOX_IS_AVAILABLE as it's no longer needed. Bug: v8:10391 Change-Id: I8658c5b0c331a4c73892737083b2c2f9b8f84056 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647355 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Samuel Groß <saelo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#80530}
-
Clemens Backes authored
Now that we require C++17 support, we can just use the standard static_assert without message, instead of our STATIC_ASSERT macro. R=leszeks@chromium.org Bug: v8:12425 Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80524}
-
- 07 Mar, 2022 2 commits
-
-
Samuel Groß authored
Instead of returning a boolean success/failure value, the Free* methods of the VirtualAddressSpace API now terminate the process on failure, as this implies a bug in the caller. This is simpler than CHECKing for success in all callers and also provides more details about the possible cause of the failure. Bug: v8:12656 Change-Id: I5b469ae2c564068cff74e60b7e98f6a4776a239d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3506992Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#79388}
-
Samuel Groß authored
This simplifies various bits of logic around EmbedderDataSlots as the raw part will now always contain a valid index into an external pointer table entry. This CL also unifies the initialization of EmbedderDataSlots by providing a EmbedderDataSlots::Initialize method and adds more documentation about the layout of EmbedderDataSlots in the different configurations. Bug: v8:10391 Change-Id: Ie952598898a7a6c9d40b28d3a7370bfc1291bcf0 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472495Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#79384}
-
- 16 Feb, 2022 1 commit
-
-
Samuel Groß authored
These should not be allowed inside the sandbox as they could be corrupted by an attacker, thus posing a security risk. Furthermore, executable pages require MAP_JIT on macOS, which causes fork() to become excessively slow, in turn causing tests to time out. Due to this, the sandbox now requires the external code space. In addition, this CL adds a max_page_permissions member to the VirtualAddressSpace API to make it possible to verify the maximum permissions of a subspace. Bug: v8:10391 Change-Id: Ib9562ecff6f018696bfa25143113d8583d1ec6cd Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460406Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#79119}
-
- 10 Feb, 2022 1 commit
-
-
Samuel Groß authored
With external code space and background compilation, external pointer table entries are now allocated on background threads. For this to work properly, the implementation must be atomic. As atomic operations are not currently available in CSA, the fast path in CSA::InitializeExternalPointerField has been removed for now. Bug: v8:10391 Change-Id: I1119a9b5f97bc8d5f48de6872b62b9ddf001e9ce Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3448381Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#79037}
-
- 01 Feb, 2022 1 commit
-
-
Samuel Groß authored
Previously, when accessing SandboxedPointer fields with the sandbox disabled, we would always do a ReadUnalignedValue/WriteUnalignedValue. However, that is only necessary when pointer compression is enabled. Otherwise, the field will be properly aligned. This CL also factors out the logic to determine when to use an unaligned or aligned read/write for a field into two new helper functions. Bug: chromium:1292669 Change-Id: I2c1af187c5b2699101c3fee9cc551be788d3a845 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3429200Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78887}
-
- 31 Jan, 2022 1 commit
-
-
Samuel Groß authored
This guarantees that they are smaller than the maximum external pointer table index when shifted to the right on load. Bug: v8:10391 Change-Id: I601f37fbb9640ee4b5215958afcc474c5e0eb9af Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359631Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78873}
-
- 25 Jan, 2022 1 commit
-
-
Samuel Groß authored
When sandboxed external pointers are enabled, external pointers now only require 32 bits of storage space in a HeapObject. This CL does not shrink the size of EmbedderDataSlots, which will happen in a follow-up CL. Bug: v8:10391 Change-Id: I3cf8b68c3b985cf806a45183717f50462a88c281 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359629Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78754}
-
- 20 Jan, 2022 1 commit
-
-
Samuel Groß authored
The external pointer table is now managed by the GC, which marks entries that are alive during major GC, then sweeps the table afterwards to free all dead entries and build a free list from them. For now, only major GCs are supported, Scavenger GCs do not interact with the external pointer table. In more detail, garbage collection of the external pointer table works as follows: 1. The external pointer table now reserves a large region of virtual address space for its backing buffer and is then never reallocated, only grown in place until the maximum size is reached. 2. When the GC's marking visitor marks a HeapObject with an external pointer as alive, it also marks the corresponding external pointer table entry as alive. This can happen on a background thread. 3. For that, it uses the MSB of each entry in the table to indicate whether the entry has been marked or not. This works because the MSB is always cleared during the AND-based type check performed when accessing an external pointer. 4. After marking, the external pointer table is swept while the mutator is stopped. This builds an inline, singly-linked freelist of all newly-dead and previously-free entries. 5. When allocating an entry from the table, the first entry on the freelist is used. If the freelist is empty, the table grows, populating the freelist with the new entries. 6. Every newly-allocated entry is marked as alive, and every store to an existing entry also automatically marks that entry as alive (by also setting the MSB). This simplifies the design of the table GC with regards to concurrency (See ExternalPointerTable::Mark). Bug: v8:10391 Change-Id: I8877fdf5576af3761bde65298951bb09e601bd14 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359625Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78708}
-
- 14 Jan, 2022 1 commit
-
-
Samuel Groß authored
This CL removes the global IsValidBackingStorePointer function and turns the DCHECKs that ensure that sandboxed pointers point into the sandbox, which essentially cover the same condition, into CHECKs. This is mostly to facilitate debugging during the initial rollout, and the CHECKs can later be turned back into DCHECKs. In addition, this CL adds a fallback to a partially-reserved sandbox when sandboxed pointers are enabled and when the regular initialization fails. Bug: chromium:1218005 Change-Id: I75526f1a00ddb9095ae0e797dc9bb80a210f867b Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367617Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78620}
-
- 04 Jan, 2022 1 commit
-
-
Samuel Groß authored
Previously, guard regions were created by allocating pages with PROT_NONE and relying on an allocation hint. This could fail however, for example on Fuchsia (where it would allocate a VMO to back the guard region) and possibly on Windows (where a placeholder mapping was replaced by a "real" mapping). Introducing an explicit VirtualAddressSpace::AllocateGuardRegion routine now makes this operation more efficient and effectively guarantees that it cannot fail if used correctly: in a regular subspace, there is no need to allocate anything when creating guard regions since the address space reservation backing the subspace is guaranteed to be inaccessible when no pages are allocated in it. Bug: chromium:1218005 Change-Id: I6945f17616b6b8dad47241af96d4cb1f660e8858 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366237Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78480}
-
- 15 Dec, 2021 1 commit
-
-
Samuel Groß authored
This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
-