- 26 Apr, 2022 1 commit
-
-
Igor Sheludko authored
It's necessary to support fast W^X permission switching on MacOS on ARM64 ("Apple M1"/Apple Silicon) where permission modification of RWX pages to anything else is prohibited. On all the other architectures/platforms RecommitPages() is equivalent to SetPermissions(). The new API will be used in a follow-up CLs. Bug: v8:12797 Change-Id: Id0d8b8c42c81b80cd8fa6b47c227680d7d1f9b10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606231Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Samuel Groß <saelo@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#80190}
-
- 25 Apr, 2022 1 commit
-
-
Igor Sheludko authored
This CL extends BoundedPageAllocator with PageFreeingMode parameter which controls how pages should be freed: by setting permissions to kNoAccess (preferred) or by discarding pages (Apple Silicon specific behavior for RWX pages). The latter mode allows to ensure that once pages are configured with RWX permissions they are never reconfigured to anything else again. The new mode will be used in a follow-up CL. Bug: v8:12797 Change-Id: I3277f56ea6fee9c9b38b1682e68c22e66e9a02a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606228Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#80162}
-
- 25 Feb, 2022 1 commit
-
-
Clemens Backes authored
Instead of returning false and failing in the caller, do fail inside the PageAllocator directly. Failure to free pages should never happen, and handling this case in the PageAllocator directly gives us better options to surface more detailed information in follow-up patches. R=mlippautz@chromium.org Bug: v8:12656, chromium:1299735 Change-Id: I6d2aa3a5613c0f1102210fccbccc6ad0e522a6ed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3484323Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#79276}
-
- 19 Nov, 2021 1 commit
-
-
Samuel Groß authored
Previously, an allocation from a separate thread could grab the just-released region and make it accessible before the regions permissions are changed to kNoAccess at the end of ReleasePages. Bug: v8:12414 Change-Id: I98c8f8e3df76d4a44c357ddab107cfeff20049b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293083Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77997}
-
- 13 Oct, 2021 1 commit
-
-
Samuel Groß authored
This is a reland of 1ea76c13 Disabled the failing test on Fuchsia until its PageAllocator respects allocation hints. Original change's description: > Implement a fake virtual memory cage mechanism > > On operating systems where reserving virtual address space is expensive, > notably Windows pre 8.1, it is not possible to create a proper virtual > memory cage. In order to still be able to reference caged objects > through offsets from the cage base on these systems, this CL introduces > a fake cage mechanism. When the fake cage is used, most of the virtual > memory for the cage is not actually reserved. Instead, the cage's page > allocator simply relies on hints to the OS to obtain pages inside the > cage. This does, however, not provide the same security benefits as a > real cage as unrelated allocations might end up inside the cage. > > Bug: chromium:1218005 > Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3 > 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/+/3217200 > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77367} Bug: chromium:1218005 Change-Id: I2ed95d121db164679c38085115e8fa92690c057e 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/+/3220151Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77378}
-
- 12 Oct, 2021 2 commits
-
-
Deepti Gandluri authored
This reverts commit 1ea76c13. Reason for revert: The unit test added fails on the Fuchsia bot https://ci.chromium.org/p/v8/builders/ci/V8%20Fuchsia/25976? Original change's description: > Implement a fake virtual memory cage mechanism > > On operating systems where reserving virtual address space is expensive, > notably Windows pre 8.1, it is not possible to create a proper virtual > memory cage. In order to still be able to reference caged objects > through offsets from the cage base on these systems, this CL introduces > a fake cage mechanism. When the fake cage is used, most of the virtual > memory for the cage is not actually reserved. Instead, the cage's page > allocator simply relies on hints to the OS to obtain pages inside the > cage. This does, however, not provide the same security benefits as a > real cage as unrelated allocations might end up inside the cage. > > Bug: chromium:1218005 > Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3 > 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/+/3217200 > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77367} Bug: chromium:1218005 Change-Id: I541bb9656ab2a6a080c2a30d372226fcc5c95391 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219086 Auto-Submit: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/main@{#77368}
-
Samuel Groß authored
On operating systems where reserving virtual address space is expensive, notably Windows pre 8.1, it is not possible to create a proper virtual memory cage. In order to still be able to reference caged objects through offsets from the cage base on these systems, this CL introduces a fake cage mechanism. When the fake cage is used, most of the virtual memory for the cage is not actually reserved. Instead, the cage's page allocator simply relies on hints to the OS to obtain pages inside the cage. This does, however, not provide the same security benefits as a real cage as unrelated allocations might end up inside the cage. Bug: chromium:1218005 Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3 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/+/3217200 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77367}
-
- 07 Oct, 2021 1 commit
-
-
Samuel Groß authored
Currently, when compiling with V8_VIRTUAL_MEMORY_CAGE enabled, the behavior of the BoundedPageAllocator changes from simply making freed pages inaccessible to decommitting them, which guarantees that they will be zero-initialized after the next allocation. As this seems to cause some performance regressions on Mac, this CL introduces a new enum that specifies how the allocator should behave: kAllocatedPagesMustBeZeroInitialized causes the pages to be decommitted during FreePages() and ReleasePages() and thus guarantees zero-initialization during AllocPages(). kAllocatedPagesCanBeUninitialized only causes the pages to be made inaccessible, and so does not generally guarantee zero-initialization for AllocPages(). Finally, this CL also removes some dead code in allocation.cc. Bug: chromium:1257089 Change-Id: I53fa52c8913df869bee2b536efe252780d1ad893 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208812 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@{#77285}
-
- 17 Aug, 2021 1 commit
-
-
Samuel Groß authored
Changing the protections of a kNoAccess region to something different can fail due to OOM. We should handle this properly. Bug: chromium:1240062 Change-Id: I35e8837a57d66930390067eb0d1ab4bc76709948 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3099685Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/master@{#76342}
-
- 11 Aug, 2021 1 commit
-
-
Samuel Groß authored
When this is enabled, v8 reserves a large region of virtual address space during initialization, at the start of which it will place its 4GB pointer compression cage. The remainder of the cage is used to store ArrayBuffer backing stores and WASM memory buffers. This will later allow referencing these buffers from inside V8 through offsets from the cage base rather than through raw pointers. Bug: chromium:1218005 Change-Id: I300094b07f64985217104b14c320cc019f8438af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010195Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@google.com> Cr-Commit-Position: refs/heads/master@{#76234}
-
- 09 Aug, 2021 1 commit
-
-
Clemens Backes authored
BoundedPageAllocator was added in https://crrev.com/c/1226915 with lots of CHECKs. There was no special reason given for that, and it's inconsistent with the default choice for DCHECKs that we have in other parts of the code. Hence this CL degrades most of these CHECKs to DCHECKs, except for the {SetPermissions} calls which we need to execute in all configurations, and where checking the return value makes sense to detect memory bugs or OOM situations. R=ishell@chromium.org CC=bikineev@chromium.org Bug: v8:11879 Change-Id: I23e3a961f2f5a6893bceaa4fb75be61fe895d5f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059691Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#76159}
-
- 29 Jul, 2021 1 commit
-
-
Anton Bikineev authored
Due to missing locks, there is a race between AllocatePagesAt (or ReserveForSharedMemoryMapping) and other functions that modify std::sets in RegionAllocator (e.g. AllocatePages or ReleasePages). The CL adds locks to AllocatePagesAt and ReserveForSharedMemoryMapping. Bug: chromium:1232067 Change-Id: I0ec503ab1ab432952ea067eb916299ea88566879 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056985 Auto-Submit: Anton Bikineev <bikineev@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75981}
-
- 31 Jul, 2020 1 commit
-
-
Dan Elphick authored
This allows the configuration v8_enable_shared_ro_heap and v8_enable_pointer_compression on Linux and Android, although it still defaults to off. When pointer compression and read-only heap sharing are enabled, sharing is achieved by allocating ReadOnlyPages in shared memory that are retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are then remapped into the address space of the Isolate ultimately using mremap. To simplify the creation process the ReadOnlySpace memory for the first Isolate is created as before without any sharing. It is only when the ReadOnlySpace memory has been finalized that the shared memory is allocated and has its contents copied into it. The original memory is then released (with PC this means it's just released back to the BoundedPageAllocator) and immediately re-allocated as a shared mapping. Because we would like to make v8_enable_shared_ro_heap default to true at some point but can't make this conditional on the value returned by a method in the code we are yet to compile, the code required for sharing has been mostly changed to use ifs with ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where a compile error would result due to the absence of a class members without sharing. IsReadOnlySpaceShared() will evaluate CanAllocateSharedPages in the platform PageAllocator (with pointer compression and sharing enabled) once and cache that value so sharing cannot be toggled during the lifetime of the process. Bug: v8:10454 Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69174}
-
- 30 Oct, 2018 1 commit
-
-
Igor Sheludko authored
to control how the memory for Isolate object is allocated. This is the support for pointer-compression friendly heap layout. Bug: v8:8182 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ida36b81ee22bd865005c394748b62d4c0897d746 Reviewed-on: https://chromium-review.googlesource.com/c/1251548 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#57131}
-
- 22 Oct, 2018 1 commit
-
-
Hannes Payer authored
Bug: chromium:897074 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I728572cda9a8914ee689eeee68a060b5713e4c6b Reviewed-on: https://chromium-review.googlesource.com/c/1290972Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56845}
-
- 12 Oct, 2018 1 commit
-
-
Clemens Hammacher authored
LockGuard is mostly used with Mutex. Since both are defined outside the internal namespace, we often have to write {base::LockGuard<base::Mutex>}. This CL shortens this to {base::MutexGuard} across the code base R=mlippautz@chromium.org Bug: v8:8238 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I020d5933b73aafb98c4b72e3bb2dfd07c979ba73 Reviewed-on: https://chromium-review.googlesource.com/c/1278796Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56612}
-
- 08 Oct, 2018 1 commit
-
-
Andreas Haas authored
R=clemensh@chromium.org bug: v8:8275 Change-Id: I4f0beb7064e1a87691e02890b5f96160b1b6c37a Reviewed-on: https://chromium-review.googlesource.com/c/1268157Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#56448}
-
- 28 Sep, 2018 1 commit
-
-
Igor Sheludko authored
Trimming may free up some allocatable pages that can be reused by subsequent allocations. This CL also fixes base::AddressRegion::contains(Address, size_t). Bug: v8:8096 Change-Id: I3b7381fd32f7dbf186dffc1a26d5a88cd8a30d2f Reviewed-on: https://chromium-review.googlesource.com/1249127Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#56284}
-
- 15 Sep, 2018 1 commit
-
-
Igor Sheludko authored
This is a reland of 16816e53 Bug: v8:8096 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I257fc391931a0a4bf01f2e8136183aaed044231c Reviewed-on: https://chromium-review.googlesource.com/1226915 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#55928}
-
- 12 Sep, 2018 1 commit
-
-
Michael Achenbach authored
Revert "[ptr-compr] Introduce BoundedPageAllocator and use it instead of CodeRange." This reverts commit 16816e53. Revert "[cleanup] Introduce LsanPageAllocator decorator" This reverts commit 0606bf91. Revert "[ptr-compr][heap] Fix TODOs about always using proper page allocator" This reverts commit b0edf8e6. The fist CL in the list is suspected to block the roll: https://chromium-review.googlesource.com/c/chromium/src/+/1216022 Pseudo bisect points to that CL: https://chromium-review.googlesource.com/c/chromium/src/+/1219612 TBR=ishell@chromium.org Bug: v8:8096 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I9fafedd3810e14cdfc2068df7727cf90fc0cc85a Reviewed-on: https://chromium-review.googlesource.com/1219695 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#55818}
-
- 10 Sep, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:8096 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: If44c1a9a76c517fe329485d385f445b2be9f5ec2 Reviewed-on: https://chromium-review.googlesource.com/1213186Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#55744}
-