diff options
author | Oliver Smith-Denny <osde@microsoft.com> | 2023-04-21 11:06:05 -0700 |
---|---|---|
committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2024-08-30 23:03:21 +0000 |
commit | 662272ef41fe848a6c0515de6b43e93d3dc5c672 (patch) | |
tree | 602b3dca451dbcdec93ba2b2a98d248f316ba149 /OvmfPkg | |
parent | 2069a63a8e4b190a6992b45060c0dd0d5a5f3c73 (diff) | |
download | edk2-662272ef41fe848a6c0515de6b43e93d3dc5c672.tar.gz edk2-662272ef41fe848a6c0515de6b43e93d3dc5c672.tar.bz2 edk2-662272ef41fe848a6c0515de6b43e93d3dc5c672.zip |
Sync AARCH64 GCD Capabilities with Page Table
On AARCH64 systems, the GCD is not fully synced with the page table. On
x86 systems, the GCD is synced by adding `EFI_MEMORY_RO`,
`EFI_MEMORY_RP`, and `EFI_MEMORY_XP` to the current capabilities of the
GCD, then the page table attributes are set on the GCD attributes.
However, on AARCH64, the GCD capabilities do not get updated, instead
only the attributes from the page table are masked by the existing GCD
capabilities, which means that any new page table attribute which are
already set are dropped and the GCD does not reflect the state of the
system. This has been seen to cause issues where memory in the page
table that was marked `EFI_MEMORY_XP` had an additional attribute set
using the GCD capabilities, which did not include `EFI_MEMORY_XP`, this
caused the page table to be updated to lose `EFI_MEMORY_XP`, which is a
potential security issue.
The existing behavior on AARCH64 systems is an implementation error, it
assumes one of two things:
- The page table attributes must be a subset of the GCD capabilities
- The GCD does not need to have its capabilities synced to what the page
table attributes are
The first is incorrect as important attributes such as `EFI_MEMORY_XP`
do not get applied to the GCD capabilities by default and therefore must
be synced back. This comment from ArmPkg's CpuDxe driver helps explain:
```c
// The GCD implementation maintains its own copy of the state of memory
// space attributes. GCD needs to know what the initial memory space
// attributes are. The CPU Arch. Protocol does not provide a
// GetMemoryAttributes function for GCD to get this so we must resort to
// calling GCD (as if we were a client) to update its copy of the
// attributes. This is bad architecture and should be replaced with a
// way for GCD to query the CPU Arch. driver of the existing memory
// space attributes instead.
```
However, this comment misses that updating the capabilities is critical
to updating the attributes.
The second is incorrect because significant pieces of core code
reference the GCD attributes instead of the page table attributes. For
example, NonDiscoverablePciDeviceDxe uses the GCD capabilities and
attributes when interacting with a non-discoverable PCI device. When the
GCD is not synced to the page table, we get the errors and security
concerns listed above.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Diffstat (limited to 'OvmfPkg')
0 files changed, 0 insertions, 0 deletions