From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web08.2725.1632327604598383778 for ; Wed, 22 Sep 2021 09:20:04 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YqhvWNV8; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id CC75C611CA; Wed, 22 Sep 2021 16:20:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632327604; bh=EX2qP/HXNIrKhPiYA9wlOCqA7u2EvykSN1PNknCAgIw=; h=From:To:Cc:Subject:Date:From; b=YqhvWNV8IuEdheW/UCgWQ4Jxn+Vb1X7KzCKunX1ipOe0eH4GCfqIoZYsKg0GZGjmU pvitzzCfJ0jKHN/2dwMsujDIQnpoVNMiEUl24KQ0/Jh4FZE0/AD0Yykd9hZWUzp3SK K3HTF9ttgC7NjiD82wmtG8Sx2tY8yMEpiGu/GeUiKyVrF5+pvESdK/hRoiaohcAg5C nxGoSP0TuFvTAYJvfwMLFKZTxKqKMrg9AuI9JB7gThvr4+VPQScCndvCHajNfsmRWH 1hwrNx05gPnWqjGUOyS3VLWgcdFU6J5M7IILkaJtpuOUsuPuL+2sTeQvq0DnkXzlpx jWgyadrN7Lsug== From: "Ard Biesheuvel" To: devel@edk2.groups.io Cc: leif@nuviainc.com, agraf@csgraf.de, peter.maydell@linaro.org, Ard Biesheuvel Subject: [PATCH] ArmPkg/ArmMmuLib AARCH64: avoid EL0 accessible mappings Date: Wed, 22 Sep 2021 18:19:54 +0200 Message-Id: <20210922161954.627616-1-ardb@kernel.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 hypervisor framework, which enters EL1 with SCTLR_EL1.SPAN enabled, which causes 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 --- ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c | 2 +- ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c b/ArmPkg/Drivers/CpuDxe/AA= rch64/Mmu.c index 838803aa9b44..56ce84f37e8a 100644 --- a/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c +++ b/ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c @@ -283,7 +283,7 @@ EfiAttributeToArmAttribute ( =0D // Determine protection attributes=0D if ((EfiAttributes & EFI_MEMORY_RO) !=3D 0) {=0D - ArmAttributes |=3D TT_AP_RO_RO;=0D + ArmAttributes |=3D TT_AP_NO_RO;=0D }=0D =0D // Process eXecute Never attribute=0D diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c b/ArmPkg/Libr= ary/ArmMmuLib/AArch64/ArmMmuLibCore.c index 8c736d25bb80..512801c88638 100644 --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c @@ -356,7 +356,7 @@ GcdAttributeToPageAttribute ( }=0D =0D if ((GcdAttributes & EFI_MEMORY_RO) !=3D 0) {=0D - PageAttributes |=3D TT_AP_RO_RO;=0D + PageAttributes |=3D TT_AP_NO_RO;=0D }=0D =0D return PageAttributes | TT_AF;=0D @@ -449,7 +449,7 @@ ArmSetMemoryRegionReadOnly ( return SetMemoryRegionAttribute (=0D BaseAddress,=0D Length,=0D - TT_AP_RO_RO,=0D + TT_AP_NO_RO,=0D ~TT_ADDRESS_MASK_BLOCK_ENTRY);=0D }=0D =0D @@ -462,7 +462,7 @@ ArmClearMemoryRegionReadOnly ( return SetMemoryRegionAttribute (=0D BaseAddress,=0D Length,=0D - TT_AP_RW_RW,=0D + TT_AP_NO_RW,=0D ~(TT_ADDRESS_MASK_BLOCK_ENTRY | TT_AP_MASK));=0D }=0D =0D --=20 2.30.2