We are no longer using Dart VM in a setting where this
matters as a security measure and it just complicates
portability for no benefit.
There is an indication that it is causing problems when
running Linux build of Dart VM under Docker on Mac OS X.
Fixes https://github.com/dart-lang/sdk/issues/54446
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-fuchsia-release-arm64-try,vm-fuchsia-release-x64-try
Change-Id: I11bdaa8faebaca1df6fd59097049bdaea9cb8e12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/344581
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Some cleanups factored out of a larger CL (which refactors enter/exit of threads):
* remove unused `#include "vm/thread_registry.h"`
* remove unused/unnecessary fields from [Thread] object
* rename IsMutator() -> IsDartMutator()
* make tests using setjmp() drain the sticky error
=> to ensure there's no sticky error on isolate shutdown
TEST=ci
Change-Id: I53935e8bd0628ab3768627d6d5e01c3f0e3a57ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296582
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This region is mostly unused after loading, but it may be accessed again if
- Isolate.spawn is invoke with isolate groups disabled
- A secondary snapshot produced by splitting is loaded
- An external typed data in the snapshot is accessed (usually a kernel file)
- Likely other cases
Even if these cases did not exist, the region is often part of a shared library and so unable to be released independently.
madvise(DONT_NEED) on this region will cause the OS to release the memory in this region but keep the address space reservation and mapping. If it is touched again, it will be brought back in from the file. If it is not backed by a file, such as malloc memory, it will be brought back in as zeros and the program will likely fail.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/44019
Bug: https://github.com/flutter/flutter/issues/92120
Change-Id: I315a049b0f7d440e181d0a5e87fa6770a2fd4f79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216580
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Don't allocate zones, timeline events or profile samples in the compressible region, since these allocations don't yeild compressed pointers and are competing for a limited resource.
TEST=ci
Bug: b/196510517
Change-Id: I4fc2f0d67060f927fa10d241b15b1cae3b73d919
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212400
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This relands https://dart-review.googlesource.com/c/sdk/+/205633
but without renaming TARGET_OS_IPHONE to DART_TARGET_OS_IPHONE.
It also changes uses of TARGET_OS_IOS to
DART_TARGET_OS_MACOS_IOS to be consistent with the rest of the
VM.
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: Ie775c19dd23cfdf5f65e5ebc6ee4ec3a561676fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205860
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: I3b33a03b4a9a14b76d55fe12f8cdefec4b3c3664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205633
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This CL:
* Moves [Heap]/[SharedClassTable] from [Isolate] to [IsolateGroup], which
will make all isolates in the group use the same heap. The GC will use
the shared class table for object size information.
* Adds support for entering/leaving an isolate group as a helper thread
(e.g. via [Thread::EnterIsolateGroupAsHelper]). The current active
isolate group can be accessed via TLS `IsolateGroup::Current()` or
`Thread::isolate_group_`. When entering as a helper thread there will be
no current isolate.
* Changes the GC to use the above mechanism and ensures GC works without
a currently active isolate. The GC will use information purely available via
[IsolateGroup]. The GC will iterate all isolates within an isolate
group e.g. for scanning roots.
* Makes spawning of new isolates start in their own isolate group.
Once the isolate is fully functional it's heap will be merged into
the original isolate group
* Moves ApiState, containing persistent and weak persistent handles,
from [Isolate] to [IsolateGroup], plus adds appropriate locking.
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: Ia8e1d8aa78750e8400864200f4825395a182c004
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/126646
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Also switch some CQ bots using blobs to ELF. Once all embedders have migrated, we will remove blobs
support entirely.
Change-Id: Ie5e8c1187ad6c1af362b5715daafd3641bc8cc0e
Cq-Include-Trybots:luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-bare-linux-release-simarm-try,vm-kernel-precomp-mac-debug-simarm_x64-try,vm-kernel-precomp-mac-release-simarm64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-precomp-android-release-arm-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/116620
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Currently the initial mapping for the executable mapping is read-only.
Once the first instruction object was allocated into an OS page we would
map that page as RX. Any further allocations of instructions objects
into the same page would just end up mapping it to RX again (even though
it is already that way).
To avoid those additional protection calls we can map the executable
mapping RX from the beginning (it will be filled with zeros after
allocation).
Issue https://github.com/dart-lang/sdk/issues/37739
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: Ib83f0be8ea8dacc86646c0a3c0335f4886516caa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112244
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Instead of implementing separate aligned and unaligned memory
allocation primitives for each OS, just change the unaligned allocator
into a wrapper around the aligned primitive.
While here, we can optimize the AllocateAligned logic slightly: if we
want an N-page-aligned allocation, we only need to increase the
allocation size by N-1 pages instead of N.
Notably, this means 1-page-aligned allocations don't require any extra
alignment pages, so the new logic behaves identically as before on
Android, Fuchsia, Linux, and macOS.
On Windows, it behaves slightly differently only in that unaligned
requests used to be handled as a single VirtualAlloc call with
MEM_RESERVE | MEM_COMMIT, but now they're handled as two separate
calls (reserve *then* commit). Naively, I don't expect this matters in
practice, but if it does, we can always add a fast path for
alignment==page_size_ without affecting the OS-independent API.
Change-Id: I42b2cf5dfc6e137546d8acfb6cc8939a01687948
Reviewed-on: https://dart-review.googlesource.com/c/91081
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
In W^X mode (i.e., FLAG_write_protect_code), the Dart VM allocates
code memory with is_executable==false and then later makes it
executable with Protect(kReadExecute). However, on Fuchsia, this will
require a VMO with ZX_RIGHT_EXECUTE (which soon will not be the
default).
This CL takes the approach of always adding ZX_RIGHT_EXECUTE when in
W^X mode. This is suboptimal because it means all VM allocated memory
can be changed to executable, but currently the OS-independent
VirtualMemory::Allocate API doesn't provide us a way to identify
memory that doesn't need to be executable now but will in the future.
(Note that ZX_RIGHT_EXECUTE only *allows* mapping the memory as
executable; the memory is still initially mapped by
VirtualMemory::Allocate as non-executable.)
Extending the VirtualMemory::Allocate API is tracked in FL-172.
Bug: SEC-42
Change-Id: I20555c546c5ab1798c4c36b7394f6221d3993c9e
Reviewed-on: https://dart-review.googlesource.com/c/90882
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
In the future, newly created VMOs on Fuchsia will not be mappable as
executable by default. In preparation for that, start using
zx_vmo_replace_as_executable to mark Fuchsia's VMOs as executable as
needed.
SEC-42
TEST=CQ
Change-Id: I9df86bbb33b02042260727d64e74b7146eb1d1a6
Reviewed-on: https://dart-review.googlesource.com/76304
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
These were left out of order by the mechanical changes that were part
of Fuchsia's Magenta->Zircon rename.
Change-Id: I41c81eb889c6076ffe82102018721e5abc74e7ac
Reviewed-on: https://dart-review.googlesource.com/6165
Reviewed-by: Zach Anderson <zra@google.com>
This CL assigns names to vmos formatted as "isolate space type" where
isolate is the name of the isolate, space is "oldspace" or "newspace",
and type is "code" or "data".
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2929203002 .
Like HOST_ARCH_*, HOST_OS_* describes the OS the VM is running on, which may be different from the OS the VM is generating code for during AOT compilation.
Currently we conflate the two when emitting AOT as assembly, and we get away with it because Flutter only uses assembly for targeting iOS and one can only target iOS from a Mac, but we expect to use assembly for Android as well so native tools can unwind Dart frames.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2750843003 .
Vyacheslav Egorov