v8/include/v8-internal.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

646 lines
25 KiB
C
Raw Normal View History

// Copyright 2018 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#ifndef INCLUDE_V8_INTERNAL_H_
#define INCLUDE_V8_INTERNAL_H_
#include <stddef.h>
#include <stdint.h>
#include <string.h>
#include <type_traits>
#include "v8-version.h" // NOLINT(build/include_directory)
#include "v8config.h" // NOLINT(build/include_directory)
namespace v8 {
class Array;
class Context;
class Data;
class Isolate;
template <typename T>
class Local;
namespace internal {
class Isolate;
typedef uintptr_t Address;
static const Address kNullAddress = 0;
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
constexpr int KB = 1024;
constexpr int MB = KB * 1024;
constexpr int GB = MB * 1024;
#ifdef V8_TARGET_ARCH_X64
constexpr size_t TB = size_t{GB} * 1024;
#endif
/**
* Configuration of tagging scheme.
*/
const int kApiSystemPointerSize = sizeof(void*);
const int kApiDoubleSize = sizeof(double);
const int kApiInt32Size = sizeof(int32_t);
const int kApiInt64Size = sizeof(int64_t);
const int kApiSizetSize = sizeof(size_t);
// Tag information for HeapObject.
const int kHeapObjectTag = 1;
const int kWeakHeapObjectTag = 3;
const int kHeapObjectTagSize = 2;
const intptr_t kHeapObjectTagMask = (1 << kHeapObjectTagSize) - 1;
Allowing map word to be used for other state in GC header. This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
2021-04-06 12:01:44 +00:00
// Tag information for fowarding pointers stored in object headers.
// 0b00 at the lowest 2 bits in the header indicates that the map word is a
// forwarding pointer.
const int kForwardingTag = 0;
const int kForwardingTagSize = 2;
const intptr_t kForwardingTagMask = (1 << kForwardingTagSize) - 1;
// Tag information for Smi.
const int kSmiTag = 0;
const int kSmiTagSize = 1;
const intptr_t kSmiTagMask = (1 << kSmiTagSize) - 1;
template <size_t tagged_ptr_size>
struct SmiTagging;
constexpr intptr_t kIntptrAllBitsSet = intptr_t{-1};
constexpr uintptr_t kUintptrAllBitsSet =
static_cast<uintptr_t>(kIntptrAllBitsSet);
// Smi constants for systems where tagged pointer is a 32-bit value.
template <>
struct SmiTagging<4> {
enum { kSmiShiftSize = 0, kSmiValueSize = 31 };
static constexpr intptr_t kSmiMinValue =
static_cast<intptr_t>(kUintptrAllBitsSet << (kSmiValueSize - 1));
static constexpr intptr_t kSmiMaxValue = -(kSmiMinValue + 1);
V8_INLINE static int SmiToInt(const internal::Address value) {
int shift_bits = kSmiTagSize + kSmiShiftSize;
// Truncate and shift down (requires >> to be sign extending).
return static_cast<int32_t>(static_cast<uint32_t>(value)) >> shift_bits;
}
V8_INLINE static constexpr bool IsValidSmi(intptr_t value) {
// Is value in range [kSmiMinValue, kSmiMaxValue].
// Use unsigned operations in order to avoid undefined behaviour in case of
// signed integer overflow.
return (static_cast<uintptr_t>(value) -
static_cast<uintptr_t>(kSmiMinValue)) <=
(static_cast<uintptr_t>(kSmiMaxValue) -
static_cast<uintptr_t>(kSmiMinValue));
}
};
// Smi constants for systems where tagged pointer is a 64-bit value.
template <>
struct SmiTagging<8> {
enum { kSmiShiftSize = 31, kSmiValueSize = 32 };
static constexpr intptr_t kSmiMinValue =
static_cast<intptr_t>(kUintptrAllBitsSet << (kSmiValueSize - 1));
static constexpr intptr_t kSmiMaxValue = -(kSmiMinValue + 1);
V8_INLINE static int SmiToInt(const internal::Address value) {
int shift_bits = kSmiTagSize + kSmiShiftSize;
// Shift down and throw away top 32 bits.
return static_cast<int>(static_cast<intptr_t>(value) >> shift_bits);
}
V8_INLINE static constexpr bool IsValidSmi(intptr_t value) {
// To be representable as a long smi, the value must be a 32-bit integer.
return (value == static_cast<int32_t>(value));
}
};
#ifdef V8_COMPRESS_POINTERS
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
// See v8:7703 or src/common/ptr-compr-inl.h for details about pointer
// compression.
constexpr size_t kPtrComprCageReservationSize = size_t{1} << 32;
constexpr size_t kPtrComprCageBaseAlignment = size_t{1} << 32;
static_assert(
kApiSystemPointerSize == kApiInt64Size,
"Pointer compression can be enabled only for 64-bit architectures");
const int kApiTaggedSize = kApiInt32Size;
#else
const int kApiTaggedSize = kApiSystemPointerSize;
#endif
constexpr bool PointerCompressionIsEnabled() {
return kApiTaggedSize != kApiSystemPointerSize;
}
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
#ifdef V8_31BIT_SMIS_ON_64BIT_ARCH
using PlatformSmiTagging = SmiTagging<kApiInt32Size>;
#else
using PlatformSmiTagging = SmiTagging<kApiTaggedSize>;
#endif
// TODO(ishell): Consinder adding kSmiShiftBits = kSmiShiftSize + kSmiTagSize
// since it's used much more often than the inividual constants.
const int kSmiShiftSize = PlatformSmiTagging::kSmiShiftSize;
const int kSmiValueSize = PlatformSmiTagging::kSmiValueSize;
const int kSmiMinValue = static_cast<int>(PlatformSmiTagging::kSmiMinValue);
const int kSmiMaxValue = static_cast<int>(PlatformSmiTagging::kSmiMaxValue);
constexpr bool SmiValuesAre31Bits() { return kSmiValueSize == 31; }
constexpr bool SmiValuesAre32Bits() { return kSmiValueSize == 32; }
V8_INLINE static constexpr internal::Address IntToSmi(int value) {
return (static_cast<Address>(value) << (kSmiTagSize + kSmiShiftSize)) |
kSmiTag;
}
/*
* Sandbox related types, constants, and functions.
*/
constexpr bool SandboxIsEnabled() {
#ifdef V8_SANDBOX
return true;
#else
return false;
#endif
}
V8 Sandbox rebranding 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/+/3322981 Reviewed-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}
2021-12-15 13:39:15 +00:00
constexpr bool SandboxedExternalPointersAreEnabled() {
#ifdef V8_SANDBOXED_EXTERNAL_POINTERS
return true;
#else
return false;
#endif
}
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
// SandboxedPointers are guaranteed to point into the sandbox. This is achieved
// for example by storing them as offset rather than as raw pointers.
using SandboxedPointer_t = Address;
// ExternalPointers point to objects located outside the sandbox. When sandboxed
// external pointers are enabled, these are stored in an external pointer table
// and referenced from HeapObjects through indices.
using ExternalPointer_t = Address;
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
#ifdef V8_SANDBOX_IS_AVAILABLE
// Size of the sandbox, excluding the guard regions surrounding it.
constexpr size_t kSandboxSizeLog2 = 40; // 1 TB
constexpr size_t kSandboxSize = 1ULL << kSandboxSizeLog2;
// Required alignment of the sandbox. For simplicity, we require the
// size of the guard regions to be a multiple of this, so that this specifies
// the alignment of the sandbox including and excluding surrounding guard
// regions. The alignment requirement is due to the pointer compression cage
// being located at the start of the sandbox.
constexpr size_t kSandboxAlignment = kPtrComprCageBaseAlignment;
// Sandboxed pointers are stored inside the heap as offset from the sandbox
// base shifted to the left. This way, it is guaranteed that the offset is
// smaller than the sandbox size after shifting it to the right again. This
// constant specifies the shift amount.
constexpr uint64_t kSandboxedPointerShift = 64 - kSandboxSizeLog2;
// Size of the guard regions surrounding the sandbox. This assumes a worst-case
// scenario of a 32-bit unsigned index used to access an array of 64-bit
// values.
constexpr size_t kSandboxGuardRegionSize = 32ULL * GB;
static_assert((kSandboxGuardRegionSize % kSandboxAlignment) == 0,
"The size of the guard regions around the sandbox must be a "
"multiple of its required alignment.");
// Minimum size of the sandbox, excluding the guard regions surrounding it. If
// the virtual memory reservation for the sandbox fails, its size is currently
// halved until either the reservation succeeds or the minimum size is reached.
// A minimum of 32GB allows the 4GB pointer compression region as well as the
// ArrayBuffer partition and two 10GB WASM memory cages to fit into the
// sandbox. 32GB should also be the minimum possible size of the userspace
// address space as there are some machine configurations with only 36 virtual
// address bits.
constexpr size_t kSandboxMinimumSize = 32ULL * GB;
static_assert(kSandboxMinimumSize <= kSandboxSize,
"The minimal size of the sandbox must be smaller or equal to the "
"regular size.");
// On OSes where reserving virtual memory is too expensive to reserve the
// entire address space backing the sandbox, notably Windows pre 8.1, we create
// a partially reserved sandbox that doesn't actually reserve most of the
// memory, and so doesn't have the desired security properties as unrelated
// memory allocations could end up inside of it, but which still ensures that
// objects that should be located inside the sandbox are allocated within
// kSandboxSize bytes from the start of the sandbox. The minimum size of the
// region that is actually reserved for such a sandbox is specified by this
// constant and should be big enough to contain the pointer compression cage as
// well as the ArrayBuffer partition.
constexpr size_t kSandboxMinimumReservationSize = 8ULL * GB;
static_assert(kSandboxMinimumSize > kPtrComprCageReservationSize,
"The sandbox must be larger than the pointer compression cage "
"contained within it.");
static_assert(kSandboxMinimumReservationSize > kPtrComprCageReservationSize,
"The minimum reservation size for a sandbox must be larger than "
"the pointer compression cage contained within it.");
// For now, even if the sandbox is enabled, we still allow backing stores to be
// allocated outside of it as fallback. This will simplify the initial rollout.
// However, if sandboxed pointers are also enabled, we must always place
// backing stores inside the sandbox as they will be referenced though them.
#ifdef V8_SANDBOXED_POINTERS
constexpr bool kAllowBackingStoresOutsideSandbox = false;
#else
constexpr bool kAllowBackingStoresOutsideSandbox = true;
#endif // V8_SANDBOXED_POINTERS
#endif // V8_SANDBOX_IS_AVAILABLE
V8 Sandbox rebranding 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/+/3322981 Reviewed-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}
2021-12-15 13:39:15 +00:00
// If sandboxed external pointers are enabled, these tag values will be ORed
// with the external pointers in the external pointer table to prevent use of
// pointers of the wrong type. When a pointer is loaded, it is ANDed with the
// inverse of the expected type's tag. The tags are constructed in a way that
// guarantees that a failed type check will result in one or more of the top
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
// bits of the pointer to be set, rendering the pointer inacessible. Besides
// the type tag bits (48 through 62), the tags also have the GC mark bit (63)
// set, so that the mark bit is automatically set when a pointer is written
// into the external pointer table (in which case it is clearly alive) and is
// cleared when the pointer is loaded. The exception to this is the free entry
// tag, which doesn't have the mark bit set, as the entry is not alive. This
V8 Sandbox rebranding 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/+/3322981 Reviewed-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}
2021-12-15 13:39:15 +00:00
// construction allows performing the type check and removing GC marking bits
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
// (the MSB) from the pointer at the same time.
// Note: this scheme assumes a 48-bit address space and will likely break if
// more virtual address bits are used.
// clang-format off
enum ExternalPointerTag : uint64_t {
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
kExternalPointerNullTag = 0b0000000000000000ULL << 48,
kExternalPointerFreeEntryTag = 0b0111111110000000ULL << 48,
kExternalStringResourceTag = 0b1000000011111111ULL << 48,
kExternalStringResourceDataTag = 0b1000000101111111ULL << 48,
kForeignForeignAddressTag = 0b1000000110111111ULL << 48,
kNativeContextMicrotaskQueueTag = 0b1000000111011111ULL << 48,
kEmbedderDataSlotPayloadTag = 0b1000000111101111ULL << 48,
kCodeEntryPointTag = 0b1000000111110111ULL << 48,
};
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
// clang-format on
constexpr uint64_t kExternalPointerTagMask = 0xffff000000000000;
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
// The size of the virtual memory reservation for an external pointer table.
// This determines the maximum number of entries in a table. Using a maximum
// size allows omitting bounds checks on table accesses if the indices are
// guaranteed (e.g. through shifting) to be below the maximum index. This
// value must be a power of two.
static const size_t kExternalPointerTableReservationSize = 128 * MB;
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
// The maximum number of entries in an external pointer table.
static const size_t kMaxSandboxedExternalPointers =
kExternalPointerTableReservationSize / kApiSystemPointerSize;
// Converts encoded external pointer to address.
V8_EXPORT Address DecodeExternalPointerImpl(const Isolate* isolate,
ExternalPointer_t pointer,
ExternalPointerTag tag);
// {obj} must be the raw tagged pointer representation of a HeapObject
// that's guaranteed to never be in ReadOnlySpace.
V8_EXPORT internal::Isolate* IsolateFromNeverReadOnlySpaceObject(Address obj);
// Returns if we need to throw when an error occurs. This infers the language
// mode based on the current context and the closure. This returns true if the
// language mode is strict.
V8_EXPORT bool ShouldThrowOnError(v8::internal::Isolate* isolate);
V8_EXPORT bool CanHaveInternalField(int instance_type);
/**
* This class exports constants and functionality from within v8 that
* is necessary to implement inline functions in the v8 api. Don't
* depend on functions and constants defined here.
*/
class Internals {
Allowing map word to be used for other state in GC header. This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
2021-04-06 12:01:44 +00:00
#ifdef V8_MAP_PACKING
V8_INLINE static constexpr internal::Address UnpackMapWord(
internal::Address mapword) {
// TODO(wenyuzhao): Clear header metadata.
return mapword ^ kMapWordXorMask;
}
#endif
public:
// These values match non-compiler-dependent values defined within
// the implementation of v8.
static const int kHeapObjectMapOffset = 0;
static const int kMapInstanceTypeOffset = 1 * kApiTaggedSize + kApiInt32Size;
static const int kStringResourceOffset =
1 * kApiTaggedSize + 2 * kApiInt32Size;
static const int kOddballKindOffset = 4 * kApiTaggedSize + kApiDoubleSize;
static const int kJSObjectHeaderSize = 3 * kApiTaggedSize;
static const int kFixedArrayHeaderSize = 2 * kApiTaggedSize;
static const int kEmbedderDataArrayHeaderSize = 2 * kApiTaggedSize;
static const int kEmbedderDataSlotSize = kApiSystemPointerSize;
V8 Sandbox rebranding 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/+/3322981 Reviewed-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}
2021-12-15 13:39:15 +00:00
#ifdef V8_SANDBOXED_EXTERNAL_POINTERS
static const int kEmbedderDataSlotRawPayloadOffset = kApiTaggedSize;
#endif
Reland^2 "[runtime] Move Context::native_context to the map" This is a reland of c7c47c68f2c0eb1155cfacab785aba54f61d9218. This makes TSAN happy in addition to: Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Bug: v8:9860 Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64360}
2019-10-17 15:58:38 +00:00
static const int kNativeContextEmbedderDataOffset = 6 * kApiTaggedSize;
static const int kStringRepresentationAndEncodingMask = 0x0f;
static const int kStringEncodingMask = 0x8;
static const int kExternalTwoByteRepresentationTag = 0x02;
static const int kExternalOneByteRepresentationTag = 0x0a;
static const uint32_t kNumIsolateDataSlots = 4;
static const int kStackGuardSize = 7 * kApiSystemPointerSize;
static const int kBuiltinTier0EntryTableSize = 13 * kApiSystemPointerSize;
static const int kBuiltinTier0TableSize = 13 * kApiSystemPointerSize;
// IsolateData layout guarantees.
static const int kIsolateCageBaseOffset = 0;
static const int kIsolateStackGuardOffset =
kIsolateCageBaseOffset + kApiSystemPointerSize;
static const int kBuiltinTier0EntryTableOffset =
kIsolateStackGuardOffset + kStackGuardSize;
static const int kBuiltinTier0TableOffset =
kBuiltinTier0EntryTableOffset + kBuiltinTier0EntryTableSize;
static const int kIsolateEmbedderDataOffset =
kBuiltinTier0TableOffset + kBuiltinTier0TableSize;
static const int kIsolateFastCCallCallerFpOffset =
kIsolateEmbedderDataOffset + kNumIsolateDataSlots * kApiSystemPointerSize;
static const int kIsolateFastCCallCallerPcOffset =
kIsolateFastCCallCallerFpOffset + kApiSystemPointerSize;
static const int kIsolateFastApiCallTargetOffset =
kIsolateFastCCallCallerPcOffset + kApiSystemPointerSize;
static const int kIsolateLongTaskStatsCounterOffset =
kIsolateFastApiCallTargetOffset + kApiSystemPointerSize;
static const int kIsolateRootsOffset =
kIsolateLongTaskStatsCounterOffset + kApiSizetSize;
static const int kExternalPointerTableBufferOffset = 0;
static const int kExternalPointerTableCapacityOffset =
[sandbox] Implement GC for the external pointer table 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/+/3359625 Reviewed-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}
2022-01-20 16:01:41 +00:00
kExternalPointerTableBufferOffset + kApiSystemPointerSize;
static const int kExternalPointerTableFreelistHeadOffset =
kExternalPointerTableCapacityOffset + kApiInt32Size;
static const int kUndefinedValueRootIndex = 4;
static const int kTheHoleValueRootIndex = 5;
static const int kNullValueRootIndex = 6;
static const int kTrueValueRootIndex = 7;
static const int kFalseValueRootIndex = 8;
static const int kEmptyStringRootIndex = 9;
static const int kNodeClassIdOffset = 1 * kApiSystemPointerSize;
static const int kNodeFlagsOffset = 1 * kApiSystemPointerSize + 3;
static const int kNodeStateMask = 0x7;
static const int kNodeStateIsWeakValue = 2;
static const int kNodeStateIsPendingValue = 3;
static const int kFirstNonstringType = 0x80;
static const int kOddballType = 0x83;
static const int kForeignType = 0xcc;
static const int kJSSpecialApiObjectType = 0x410;
static const int kJSObjectType = 0x421;
static const int kFirstJSApiObjectType = 0x422;
static const int kLastJSApiObjectType = 0x80A;
static const int kUndefinedOddballKind = 5;
static const int kNullOddballKind = 3;
// Constants used by PropertyCallbackInfo to check if we should throw when an
// error occurs.
static const int kThrowOnError = 0;
static const int kDontThrow = 1;
static const int kInferShouldThrowMode = 2;
// Soft limit for AdjustAmountofExternalAllocatedMemory. Trigger an
// incremental GC once the external memory reaches this limit.
static constexpr int kExternalAllocationSoftLimit = 64 * 1024 * 1024;
Allowing map word to be used for other state in GC header. This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
2021-04-06 12:01:44 +00:00
#ifdef V8_MAP_PACKING
static const uintptr_t kMapWordMetadataMask = 0xffffULL << 48;
// The lowest two bits of mapwords are always `0b10`
static const uintptr_t kMapWordSignature = 0b10;
// XORing a (non-compressed) map with this mask ensures that the two
// low-order bits are 0b10. The 0 at the end makes this look like a Smi,
// although real Smis have all lower 32 bits unset. We only rely on these
// values passing as Smis in very few places.
static const int kMapWordXorMask = 0b11;
#endif
V8_EXPORT static void CheckInitializedImpl(v8::Isolate* isolate);
V8_INLINE static void CheckInitialized(v8::Isolate* isolate) {
#ifdef V8_ENABLE_CHECKS
CheckInitializedImpl(isolate);
#endif
}
V8_INLINE static bool HasHeapObjectTag(const internal::Address value) {
return (value & kHeapObjectTagMask) == static_cast<Address>(kHeapObjectTag);
}
V8_INLINE static int SmiValue(const internal::Address value) {
return PlatformSmiTagging::SmiToInt(value);
}
V8_INLINE static constexpr internal::Address IntToSmi(int value) {
return internal::IntToSmi(value);
}
V8_INLINE static constexpr bool IsValidSmi(intptr_t value) {
return PlatformSmiTagging::IsValidSmi(value);
}
V8_INLINE static int GetInstanceType(const internal::Address obj) {
typedef internal::Address A;
A map = ReadTaggedPointerField(obj, kHeapObjectMapOffset);
Allowing map word to be used for other state in GC header. This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
2021-04-06 12:01:44 +00:00
#ifdef V8_MAP_PACKING
map = UnpackMapWord(map);
#endif
return ReadRawField<uint16_t>(map, kMapInstanceTypeOffset);
}
V8_INLINE static int GetOddballKind(const internal::Address obj) {
return SmiValue(ReadTaggedSignedField(obj, kOddballKindOffset));
}
V8_INLINE static bool IsExternalTwoByteString(int instance_type) {
int representation = (instance_type & kStringRepresentationAndEncodingMask);
return representation == kExternalTwoByteRepresentationTag;
}
V8_INLINE static uint8_t GetNodeFlag(internal::Address* obj, int shift) {
uint8_t* addr = reinterpret_cast<uint8_t*>(obj) + kNodeFlagsOffset;
return *addr & static_cast<uint8_t>(1U << shift);
}
V8_INLINE static void UpdateNodeFlag(internal::Address* obj, bool value,
int shift) {
uint8_t* addr = reinterpret_cast<uint8_t*>(obj) + kNodeFlagsOffset;
uint8_t mask = static_cast<uint8_t>(1U << shift);
*addr = static_cast<uint8_t>((*addr & ~mask) | (value << shift));
}
V8_INLINE static uint8_t GetNodeState(internal::Address* obj) {
uint8_t* addr = reinterpret_cast<uint8_t*>(obj) + kNodeFlagsOffset;
return *addr & kNodeStateMask;
}
V8_INLINE static void UpdateNodeState(internal::Address* obj, uint8_t value) {
uint8_t* addr = reinterpret_cast<uint8_t*>(obj) + kNodeFlagsOffset;
*addr = static_cast<uint8_t>((*addr & ~kNodeStateMask) | value);
}
V8_INLINE static void SetEmbedderData(v8::Isolate* isolate, uint32_t slot,
void* data) {
internal::Address addr = reinterpret_cast<internal::Address>(isolate) +
kIsolateEmbedderDataOffset +
slot * kApiSystemPointerSize;
*reinterpret_cast<void**>(addr) = data;
}
V8_INLINE static void* GetEmbedderData(const v8::Isolate* isolate,
uint32_t slot) {
internal::Address addr = reinterpret_cast<internal::Address>(isolate) +
kIsolateEmbedderDataOffset +
slot * kApiSystemPointerSize;
return *reinterpret_cast<void* const*>(addr);
}
V8_INLINE static void IncrementLongTasksStatsCounter(v8::Isolate* isolate) {
internal::Address addr = reinterpret_cast<internal::Address>(isolate) +
kIsolateLongTaskStatsCounterOffset;
++(*reinterpret_cast<size_t*>(addr));
}
V8_INLINE static internal::Address* GetRoot(v8::Isolate* isolate, int index) {
internal::Address addr = reinterpret_cast<internal::Address>(isolate) +
kIsolateRootsOffset +
index * kApiSystemPointerSize;
return reinterpret_cast<internal::Address*>(addr);
}
template <typename T>
V8_INLINE static T ReadRawField(internal::Address heap_object_ptr,
int offset) {
internal::Address addr = heap_object_ptr + offset - kHeapObjectTag;
#ifdef V8_COMPRESS_POINTERS
if (sizeof(T) > kApiTaggedSize) {
// TODO(ishell, v8:8875): When pointer compression is enabled 8-byte size
// fields (external pointers, doubles and BigInt data) are only
// kTaggedSize aligned so we have to use unaligned pointer friendly way of
// accessing them in order to avoid undefined behavior in C++ code.
T r;
memcpy(&r, reinterpret_cast<void*>(addr), sizeof(T));
return r;
}
#endif
return *reinterpret_cast<const T*>(addr);
}
V8_INLINE static internal::Address ReadTaggedPointerField(
internal::Address heap_object_ptr, int offset) {
#ifdef V8_COMPRESS_POINTERS
uint32_t value = ReadRawField<uint32_t>(heap_object_ptr, offset);
Reland^2 "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" This is a reland of e28dadc2070b202aab77b9e50a46e50be02f8f1c The original failure was due to a stale Win32 bot. The reland failure was due to idempotent task deduplication returning the exact same failure. See crbug/1196064 Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Bug: v8:11460 > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Auto-Submit: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73790} Bug: v8:11460 No-Try: true Tbr: ishell@chromium.org Tbr: rmcilroy@chromium.org Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546 Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73795}
2021-04-05 19:42:59 +00:00
internal::Address base =
GetPtrComprCageBaseFromOnHeapAddress(heap_object_ptr);
return base + static_cast<internal::Address>(static_cast<uintptr_t>(value));
#else
return ReadRawField<internal::Address>(heap_object_ptr, offset);
#endif
}
V8_INLINE static internal::Address ReadTaggedSignedField(
internal::Address heap_object_ptr, int offset) {
#ifdef V8_COMPRESS_POINTERS
uint32_t value = ReadRawField<uint32_t>(heap_object_ptr, offset);
return static_cast<internal::Address>(static_cast<uintptr_t>(value));
#else
return ReadRawField<internal::Address>(heap_object_ptr, offset);
#endif
}
V8 Sandbox rebranding 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/+/3322981 Reviewed-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}
2021-12-15 13:39:15 +00:00
V8_INLINE static internal::Isolate* GetIsolateForSandbox(
internal::Address obj) {
V8 Sandbox rebranding 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/+/3322981 Reviewed-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}
2021-12-15 13:39:15 +00:00
#ifdef V8_SANDBOXED_EXTERNAL_POINTERS
return internal::IsolateFromNeverReadOnlySpaceObject(obj);
#else
// Not used in non-sandbox mode.
return nullptr;
#endif
}
V8_INLINE static Address DecodeExternalPointer(
const Isolate* isolate, ExternalPointer_t encoded_pointer,
ExternalPointerTag tag) {
V8 Sandbox rebranding 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/+/3322981 Reviewed-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}
2021-12-15 13:39:15 +00:00
#ifdef V8_SANDBOXED_EXTERNAL_POINTERS
return internal::DecodeExternalPointerImpl(isolate, encoded_pointer, tag);
#else
return encoded_pointer;
#endif
}
V8_INLINE static internal::Address ReadExternalPointerField(
internal::Isolate* isolate, internal::Address heap_object_ptr, int offset,
ExternalPointerTag tag) {
V8 Sandbox rebranding 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/+/3322981 Reviewed-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}
2021-12-15 13:39:15 +00:00
#ifdef V8_SANDBOXED_EXTERNAL_POINTERS
internal::ExternalPointer_t encoded_value =
ReadRawField<uint32_t>(heap_object_ptr, offset);
// We currently have to treat zero as nullptr in embedder slots.
return encoded_value ? DecodeExternalPointer(isolate, encoded_value, tag)
: 0;
#else
return ReadRawField<Address>(heap_object_ptr, offset);
#endif
}
#ifdef V8_COMPRESS_POINTERS
Reland^2 "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" This is a reland of e28dadc2070b202aab77b9e50a46e50be02f8f1c The original failure was due to a stale Win32 bot. The reland failure was due to idempotent task deduplication returning the exact same failure. See crbug/1196064 Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Bug: v8:11460 > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Auto-Submit: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73790} Bug: v8:11460 No-Try: true Tbr: ishell@chromium.org Tbr: rmcilroy@chromium.org Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546 Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73795}
2021-04-05 19:42:59 +00:00
V8_INLINE static internal::Address GetPtrComprCageBaseFromOnHeapAddress(
internal::Address addr) {
Reland^2 "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" This is a reland of e28dadc2070b202aab77b9e50a46e50be02f8f1c The original failure was due to a stale Win32 bot. The reland failure was due to idempotent task deduplication returning the exact same failure. See crbug/1196064 Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Bug: v8:11460 > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Auto-Submit: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73790} Bug: v8:11460 No-Try: true Tbr: ishell@chromium.org Tbr: rmcilroy@chromium.org Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546 Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73795}
2021-04-05 19:42:59 +00:00
return addr & -static_cast<intptr_t>(kPtrComprCageBaseAlignment);
}
V8_INLINE static internal::Address DecompressTaggedAnyField(
internal::Address heap_object_ptr, uint32_t value) {
Reland^2 "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" This is a reland of e28dadc2070b202aab77b9e50a46e50be02f8f1c The original failure was due to a stale Win32 bot. The reland failure was due to idempotent task deduplication returning the exact same failure. See crbug/1196064 Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Bug: v8:11460 > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Auto-Submit: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73790} Bug: v8:11460 No-Try: true Tbr: ishell@chromium.org Tbr: rmcilroy@chromium.org Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546 Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73795}
2021-04-05 19:42:59 +00:00
internal::Address base =
GetPtrComprCageBaseFromOnHeapAddress(heap_object_ptr);
return base + static_cast<internal::Address>(static_cast<uintptr_t>(value));
}
#endif // V8_COMPRESS_POINTERS
};
// Only perform cast check for types derived from v8::Data since
// other types do not implement the Cast method.
template <bool PerformCheck>
struct CastCheck {
template <class T>
static void Perform(T* data);
};
template <>
template <class T>
void CastCheck<true>::Perform(T* data) {
T::Cast(data);
}
template <>
template <class T>
void CastCheck<false>::Perform(T* data) {}
template <class T>
V8_INLINE void PerformCastCheck(T* data) {
CastCheck<std::is_base_of<Data, T>::value &&
!std::is_same<Data, std::remove_cv_t<T>>::value>::Perform(data);
}
// A base class for backing stores, which is needed due to vagaries of
// how static casts work with std::shared_ptr.
class BackingStoreBase {};
// The maximum value in enum GarbageCollectionReason, defined in heap.h.
// This is needed for histograms sampling garbage collection reasons.
constexpr int kGarbageCollectionReasonMaxValue = 25;
} // namespace internal
} // namespace v8
#endif // INCLUDE_V8_INTERNAL_H_