mirror of https://github.com/acidanthera/audk.git
58e681406f
At the moment, we have the following distribution of actions between the IOMMU protocol member functions: - AllocateBuffer() allocates pages and clears the memory encryption mask. - FreeBuffer() re-sets the memory encryption mask, and deallocates pages. - Map() does nothing at all when BusMasterCommonBuffer[64] is requested (and AllocateBuffer() was called previously). Otherwise, Map() allocates pages, and clears the memory encryption mask. - Unmap() does nothing when cleaning up a BusMasterCommonBuffer[64] operation. Otherwise, Unmap() clears the encryption mask, and frees the pages. This is wrong: the AllocateBuffer() protocol member is not expected to produce a buffer that is immediately usable, and client code is required to call Map() unconditionally, even if BusMasterCommonBuffer[64] is the desired operation. Implement the right distribution of actions as follows: - AllocateBuffer() allocates pages and does not touch the encryption mask. - FreeBuffer() deallocates pages and does not touch the encryption mask. - Map() does not allocate pages when BusMasterCommonBuffer[64] is requested, and it allocates pages (bounce buffer) otherwise. Regardless of the BusMaster operation, Map() (and Map() only) clears the memory encryption mask. - Unmap() restores the encryption mask unconditionally. If the operation was BusMasterCommonBuffer[64], then Unmap() does not release the pages. Otherwise, the pages (bounce buffer) are released. This approach also ensures that Unmap() can be called from ExitBootServices() event handlers, for cleaning up BusMasterCommonBuffer[64] operations. (More specifically, for restoring the SEV encryption mask on any in-flight buffers, after resetting any referring devices.) ExitBootServices() event handlers must not change the UEFI memory map, thus any memory allocation or freeing in Unmap() would disqualify Unmap() from being called in such a context. Map()-ing and Unmap()-ing memory for a BusMasterCommonBuffer[64] operation effectively means in-place decryption and encryption in a SEV context. As an additional hurdle, section "7.10.8 Encrypt-in-Place" of AMD publication Nr.24593 implies that we need a separate temporary buffer for decryption and encryption that will eventually land in-place. Allocating said temporary buffer in the straightforward way would violate the above allocation/freeing restrictions on Map()/Unmap(), therefore pre-allocate this "stash buffer" too in AllocateBuffer(), and free it in FreeBuffer(). To completely rid Unmap() of dynamic memory impact, for BusMasterCommonBuffer[64] operations, we're going to rework the lifecycle of the MAP_INFO structures in a later patch. (The MemEncryptSevSetPageEncMask() call in Unmap() could theoretically allocate memory internally for page splitting, however this won't happen in practice: in Unmap() we only restore the memory encryption mask, and don't genuinely set it. Any page splitting will have occurred in Map()'s MemEncryptSevClearPageEncMask() call first.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> |
||
|---|---|---|
| AppPkg | ||
| ArmPkg | ||
| ArmPlatformPkg | ||
| ArmVirtPkg | ||
| BaseTools | ||
| BeagleBoardPkg | ||
| Conf | ||
| CorebootModulePkg | ||
| CorebootPayloadPkg | ||
| CryptoPkg | ||
| DuetPkg | ||
| EdkCompatibilityPkg | ||
| EdkShellBinPkg | ||
| EdkShellPkg | ||
| EmbeddedPkg | ||
| EmulatorPkg | ||
| FatBinPkg | ||
| FatPkg | ||
| IntelFrameworkModulePkg | ||
| IntelFrameworkPkg | ||
| IntelFsp2Pkg | ||
| IntelFsp2WrapperPkg | ||
| IntelFspPkg | ||
| IntelFspWrapperPkg | ||
| IntelSiliconPkg | ||
| MdeModulePkg | ||
| MdePkg | ||
| NetworkPkg | ||
| Nt32Pkg | ||
| Omap35xxPkg | ||
| OptionRomPkg | ||
| OvmfPkg | ||
| PcAtChipsetPkg | ||
| PerformancePkg | ||
| QuarkPlatformPkg | ||
| QuarkSocPkg | ||
| SecurityPkg | ||
| ShellBinPkg | ||
| ShellPkg | ||
| SignedCapsulePkg | ||
| SourceLevelDebugPkg | ||
| StdLib | ||
| StdLibPrivateInternalFiles | ||
| UefiCpuPkg | ||
| UnixPkg | ||
| Vlv2DeviceRefCodePkg | ||
| Vlv2TbltDevicePkg | ||
| .gitignore | ||
| BuildNotes2.txt | ||
| Contributions.txt | ||
| Edk2Setup.bat | ||
| License.txt | ||
| Maintainers.txt | ||
| Readme.md | ||
| edksetup.bat | ||
| edksetup.sh | ||
Readme.md
EDK II Project
A modern, feature-rich, cross-platform firmware development environment for the UEFI and PI specifications from www.uefi.org.
Contributions to the EDK II open source project are covered by the TianoCore Contribution Agreement 1.1
The majority of the content in the EDK II open source project uses a BSD 2-Clause License. The EDK II open source project contains the following components that are covered by additional licenses:
- AppPkg/Applications/Python/Python-2.7.2/Tools/pybench
- AppPkg/Applications/Python/Python-2.7.2
- AppPkg/Applications/Python/Python-2.7.10
- BaseTools/Source/C/BrotliCompress
- MdeModulePkg/Library/BrotliCustomDecompressLib
- OvmfPkg
- CryptoPkg/Library/OpensslLib/openssl
The EDK II Project is composed of packages. The maintainers for each package are listed in Maintainers.txt.