• Igor Sheludko's avatar
    Reland "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)" · 449ece38
    Igor Sheludko authored
    This is a reland of commit 9d31f866
    There were issues with --future flag implications on M1.
    
    Original change's description:
    > [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
    >
    > ... for V8 code space. The feature is currently disabled.
    >
    > In order to use fast W^X permission switching we must allocate
    > executable pages with readable writable executable permissions (RWX).
    > However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
    > permission changing of RWX memory pages. This means that the code page
    > headers must be allocated with RWX permissions too because otherwise
    > it wouldn't be possible to allocate a large code page over the freed
    > regular code page and vice versa.
    >
    > When enabled, the new machinery works as follows:
    >
    > 1) when memory region is reserved for allocating executable pages, the
    >    whole region is committed with RWX permissions and then decommitted,
    > 2) since reconfiguration of RWX page permissions is not allowed on
    >    MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
    >    to change them,
    > 3) the request to set RWX permissions in the executable page region
    >    just recommits the pages without changing permissions (see (1), they
    >    were already allocated as RWX and then discarded),
    > 4) in order to make executable pages inaccessible one must use
    >    OS::DiscardSystemPages() instead of OS::DecommitPages() or
    >    setting permissions to kNoAccess because the latter two are not
    >    allowed by the MacOS (see (2)).
    > 5) since code space page headers are allocated as RWX pages it's also
    >    necessary to switch between W^X modes when updating the data in the
    >    page headers (i.e. when marking, updating stats, wiring pages in
    >    lists, etc.). The new CodePageHeaderModificationScope class is used
    >    in the respective places. On unrelated configurations it's a no-op.
    >
    > The fast permission switching can't be used for V8 configuration with
    > enabled pointer compression and disabled external code space because
    > a) the pointer compression cage has to be reserved with MAP_JIT flag
    >    which is too expensive,
    > b) in case of shared pointer compression cage if the code range will
    >    be deleted while the cage is still alive then attempt to configure
    >    permissions of pages that were previously set to RWX will fail.
    >
    > This also CL extends the unmapper unit tests with permissions tracking
    > for discarded pages.
    >
    > Bug: v8:12797
    > Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
    > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
    > Reviewed-by: Clemens Backes <clemensb@chromium.org>
    > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
    > Commit-Queue: Igor Sheludko <ishell@chromium.org>
    > Cr-Commit-Position: refs/heads/main@{#80238}
    
    Bug: v8:12797
    Change-Id: I0fe86666f31bad37d7074e217555c95900d2afba
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610433Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
    Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
    Commit-Queue: Igor Sheludko <ishell@chromium.org>
    Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#80259}
    449ece38
marking-barrier.cc 8.86 KB