diff options
author | Ard Biesheuvel <ardb@kernel.org> | 2021-09-22 18:12:20 +0200 |
---|---|---|
committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2022-02-01 23:09:01 +0000 |
commit | 017564d637e9c3051c2796d1d5b4d5df7179434c (patch) | |
tree | 6550f390a35ef7d8b3259740b40e4d1438796ef7 /DynamicTablesPkg/Library | |
parent | 5b3c682d91bd699a3144d36258565ccaa2036db7 (diff) | |
download | edk2-017564d637e9c3051c2796d1d5b4d5df7179434c.tar.gz edk2-017564d637e9c3051c2796d1d5b4d5df7179434c.tar.bz2 edk2-017564d637e9c3051c2796d1d5b4d5df7179434c.zip |
ArmPkg/ArmMmuLib AARCH64: avoid EL0 accessible mappings
We never run any code at EL0, and so it would seem that any access
permissions set for EL0 (via the AP[1] attribute in the page tables) are
irrelevant. We currently set EL0 and EL1 permissions to the same value
arbitrarily.
However, this causes problems on hardware like the Apple M1 running the
MacOS hypervisor framework, which enters EL1 with SCTLR_EL1.SPAN
enabled, causing the Privileged Access Never (PAN) feature to be enabled
on any exception taken to EL1, including the IRQ exceptions that handle
our timer interrupt. When PAN is enabled, EL1 has no access to any
mappings that are also accessible to EL0, causing the firmware to crash
if it attempts to access such a mapping.
Even though it is debatable whether or not SCTLR_EL1.SPAN should be
disabled at entry or whether the firmware should put all UNKNOWN bits in
all system registers in a consistent state (which it should), using EL0
permissions serves no purpose whatsoever so let's fix that regardless.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Alexander Graf <agraf@csgraf.de>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Diffstat (limited to 'DynamicTablesPkg/Library')
0 files changed, 0 insertions, 0 deletions