summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/AmdSev: add Grub Firmware Volume PackageJames Bottomley2020-12-1412-10/+2144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is used to package up the grub bootloader into a firmware volume where it can be executed as a shell like the UEFI Shell. Grub itself is built as a minimal entity into a Fv and then added as a boot option. By default the UEFI shell isn't built but for debugging purposes it can be enabled and will then be presented as a boot option (This should never be allowed for secure boot in an external data centre but may be useful for local debugging). Finally all other boot options except grub and possibly the shell are stripped and the boot timeout forced to 0 so the system will not enter a setup menu and will only boot to grub. This is done by copying the Library/PlatformBootManagerLib into Library/PlatformBootManagerLibGrub and then customizing it. Boot failure is fatal to try to prevent secret theft. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-4-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: replace local variable initialization with assignment] Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: squash 'OvmfPkg: add "gGrubFileGuid=Grub" to GuidCheck.IgnoreDuplicates', reviewed stand-alone by Phil (msgid <e6eae551-8563-ccfb-5547-7a97da6d46e5@redhat.com>) and Ard (msgid <10aeda37-def6-d9a4-6e02-4c66c1492f57@arm.com>)]
* OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMFJames Bottomley2020-12-142-0/+1283
| | | | | | | | | | | | | | | This commit represents the file copied from OvmfPkgX64 with minor changes to change the build name. This package will form the basis for adding Sev specific features. Since everything must go into a single rom file for attestation, the separated build of code and variables is eliminated. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-3-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/ResetVector: convert SEV-ES Reset Block structure to be GUIDedJames Bottomley2020-12-141-11/+40
| | | | | | | | | | | | Convert the current ES reset block structure to an extensible guid based structure by appending a header and length, which allow for multiple guid based data packets to be inserted. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-2-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Disable EccCheck CI until EccCheck issues are fixedSean Brogan2020-12-141-1/+2
| | | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Message-Id: <20201210215640.1260-1-mikuback@linux.microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Bhyve: Fix various style issuesRebecca Cran2020-11-3015-53/+47
| | | | | | | | | | | | Fix ordering of includes, sources, libraries etc. Remove leading/trailing underscores from include guards. Change INF and DSC version numbers to be decimal. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-6-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Improve style and formatting in BhyveFwCtlLib.hRebecca Cran2020-11-301-12/+12
| | | | | | | | | | | There were some problems with the formatting and style that made the file difficult to read. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-5-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Fix style of BhyveFwCtlLib.infRebecca Cran2020-11-301-3/+2
| | | | | | | | | | Fix the order of libraries and update INF_VERSION to 1.29. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-4-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Improve code style/formatting in BhyveFwCtlLib.cRebecca Cran2020-11-301-67/+69
| | | | | | | | | | | | The code style in Library/BhyveFwCtlLib/BhyveFwCtlLib.c was very inconsistent. Fix it to pass the ECC tool checks by typedef'ing structs, and improve indentation. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-3-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Fix BhyveFwCtlLib build with VS2019Rebecca Cran2020-11-301-25/+25
| | | | | | | | | | | Update BhyveFwCtlLib.c to fix problems with UINT32/UINTN types that prevented Bhyve from building with VS2019. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201130053412.2-2-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/XenPvBlkDxe: add return value if allocting failWenyi Xie2020-11-271-0/+4
| | | | | | | | | | | | | return EFI_OUT_OF_RESOURCES if pool allocating fail. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com> Message-Id: <1606183592-81879-2-git-send-email-xiewenyi2@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Bhyve: Copy Real16ToFlat32.asm and enable cache in CR0Rebecca Cran2020-11-271-0/+143
| | | | | | | | | | | | | | | | | | | | | | Copy UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm to OvmfPkg/Bhyve/ResetVector/Ia16, with one change, as has also been made in XenResetVector: - SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0) With the CD bit set to 1, this has the downside on AMD systems of actually running with the cache disabled, which slows the entire system to a crawl. There's no need for this bit to be set in virtualized environments. This patch reapplies the change from the freebsd uefi-edk2 repo at https://github.com/freebsd/uefi-edk2/commit/08c00f4e8d9e3e469bdc2ce92d3aa839cae7cf17 Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201124005733.18107-4-rebecca@bsdio.com>
* OvmfPkg/Bhyve: Add support for the AMD host bridgeRebecca Cran2020-11-272-3/+6
| | | | | | | | | | | On bhyve, either an Intel or AMD host bridge can be specified, with the default being Intel. Both are identical, except the AMD one uses a PCI vendor ID of AMD. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201124005733.18107-3-rebecca@bsdio.com>
* OvmfPkg/Bhyve: Add VariablePolicy engine to BhyveRebecca Cran2020-11-271-1/+3
| | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2522 Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201124005733.18107-2-rebecca@bsdio.com>
* OvmfPkg/PlatformCI/.azurepiplines: Use stable release of QEMUMichael D Kinney2020-11-251-1/+1
| | | | | | | | | | | | | | | | | | Install the 2020.08.14 release of QEMU for Windows. The QEMU release from 2020.11.20 is installed into the incorrect directory and is causing EDK II CI failures in the run to shell step. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/BhyveX64.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-1/+4
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-12-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfXen.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-11-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkgX64.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-10-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkgIa32X64.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-9-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkgIa32.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-8-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add VariablePolicy engine to OvmfPkg platformBret Barkelew2020-11-174-0/+19
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2522 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Bret Barkelew <brbarkel@microsoft.com> Signed-off-by: Bret Barkelew <brbarkel@microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Bhyve: fix build breakage after SEV-ES changesRebecca Cran2020-11-132-2/+3
| | | | | | | | | | Consume the SEV-ES-independent reset vector restored in the previous patch. Use the Null instance of VmgExitLib. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201112053153.22038-3-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Bhyve: detach ResetVector from before the SEV-ES changesRebecca Cran2020-11-133-0/+255
| | | | | | | | | | | | Commits 6995a1b79bab, 8a2732186a53 and 30937f2f98c4 modified all four regular files under "OvmfPkg/ResetVector" with SEV-ES dependencies. These are not relevant for Bhyve. Detach the pre-SEV-ES version of ResetVector for Bhyve. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Message-Id: <20201112053153.22038-2-rebecca@bsdio.com> Acked-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* UefiCpuPkg, OvmfPkg: Disable interrupts when using the GHCBTom Lendacky2020-11-103-8/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The QemuFlashPtrWrite() flash services runtime uses the GHCB and VmgExit() directly to perform the flash write when running as an SEV-ES guest. If an interrupt arrives between VmgInit() and VmgExit(), the Dr7 read in the interrupt handler will generate a #VC, which can overwrite information in the GHCB that QemuFlashPtrWrite() has set. This has been seen with the timer interrupt firing and the CpuExceptionHandlerLib library code, UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ Xcode5ExceptionHandlerAsm.nasm and ExceptionHandlerAsm.nasm reading the Dr7 register while QemuFlashPtrWrite() is using the GHCB. In general, it is necessary to protect the GHCB whenever it is used, not just in QemuFlashPtrWrite(). Disable interrupts around the usage of the GHCB by modifying the VmgInit() and VmgDone() interfaces: - VmgInit() will take an extra parameter that is a pointer to a BOOLEAN that will hold the interrupt state at the time of invocation. VmgInit() will get and save this interrupt state before updating the GHCB. - VmgDone() will take an extra parameter that is used to indicate whether interrupts are to be (re)enabled. Before exiting, VmgDone() will enable interrupts if that is requested. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <c326a4fd78253f784b42eb317589176cf7d8592a.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Fix erase blocks for SEV-ESTom Lendacky2020-11-101-2/+2
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The original SEV-ES support missed updating the QemuFlashEraseBlock() function to successfully erase blocks. Update QemuFlashEraseBlock() to call the QemuFlashPtrWrite() to be able to successfully perform the commands under SEV-ES. Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <309c5317a3107bd0e650be20731842a2e1d4b59a.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Set the SwScratch valid bitTom Lendacky2020-11-101-0/+1
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bit for the scratch area field (SwScratch). Fixes: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <cc8c8449740d2be0b287e6c69d48bf6cb067c7d8.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Set the SwScratch valid bit for MMIO eventsTom Lendacky2020-11-101-0/+5
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bit for the scratch area field (SwScratch). Fixes: c45f678a1ea2080344e125dc55b14e4b9f98483d Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <45ccb63c2dadd834e2c47bf10c9e59c6766d7eb6.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Set the SwScratch valid bit for IOIO eventsTom Lendacky2020-11-101-0/+1
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bit for the scratch area field (SwScratch). Fixes: 0020157a9825e5f5784ff014044f11c0558c92fe Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <f817d034cea37fa78e00e86f61c3445f1208226d.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Set the SW exit fields when performing VMGEXITTom Lendacky2020-11-101-0/+4
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 All fields that are set in the GHCB should have their associated bit in the GHCB ValidBitmap field set. Add support to set the bits for the software exit information fields when performing a VMGEXIT (SwExitCode, SwExitInfo1, SwExitInfo2). Fixes: 61bacc0fa16fd6f595a2c4222425cb6286e19977 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <986e157c13bf33e529b1d16ab1b52e99a74a734f.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Implement new VmgExitLib interfacesTom Lendacky2020-11-102-87/+85
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008 The VmgExitLib library added two new interfaces, VmgSetOffsetValid() and VmgIsOffsetValid(), that must now be implemented in the OvmfPkg version of the library. Implement VmgSetOffsetValid() and VmgIsOffsetValid() and update existing code, that is directly accessing ValidBitmap, to use the new interfaces. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <939e9dc375e6085bc67942fe9a00ecd4c6b77ecf.1604685192.git.thomas.lendacky@amd.com>
* OvmfPkg: enable HttpDynamicCommandVladimir Olovyannikov2020-10-018-0/+20
| | | | | | | | | | | Enable HttpDynamicCommand (Shell command "http") for OvmfPkg platforms. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2857 Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Message-Id: <20200722205434.4348-3-vladimir.olovyannikov@broadcom.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: remove groups.io corruption from Author meta-datum]
* OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwardingLaszlo Ersek2020-09-221-9/+15
| | | | | | | | | | | | | | | | | | | | | | | In QEMU commit range 4abf70a661a5..69699f3055a5 (later fixed up in QEMU commit 4318432ccd3f), Phil implemented a QEMU facility for exposing the host-side TLS cipher suite configuration to OVMF. The purpose is to control the permitted ciphers in the guest's UEFI HTTPS boot. This complements the forwarding of the host-side crypto policy from the host to the guest -- the other facet was the set of CA certificates (for which p11-kit patches had been upstreamed, on the host side). Mention the new command line options in "OvmfPkg/README". Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200922091827.12617-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg: Add RngLib based on TimerLib for CryptoMatthew Carlson2020-09-185-0/+5
| | | | | | | | | | | | | | | | | | | | Updates the DSC's for Ovmf based platforms to add a RngLib that uses the TimerLib. This is due to a later change that adds TimerLib as a dependency for OpenSSL. The TimerLib based RngLib mimics the behavior of OpenSSL previously and it is recommended to switch to a better source of entropy than the system's performance counter. Ref: https://github.com/tianocore/edk2/pull/845 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
* OvmfPkg: drop redundant VendorID check in VirtioMmioDeviceLibLeif Lindholm2020-09-171-15/+0
| | | | | | | | | | | | | | | | | | | | | | There is a DEBUG warning printout in VirtioMmioDeviceLib if the current device's VendorID does not match the traditional 16-bit Red Hat PCIe vendor ID used with virtio-pci. The virtio-mmio vendor ID is 32-bit and has no connection to the PCIe registry. Most specifically, this causes a bunch of noise when booting an AArch64 QEMU platform, since QEMU's virtio-mmio implementation used 'QEMU' as the vendor ID: VirtioMmioInit: Warning: The VendorId (0x554D4551) does not match the VirtIo VendorId (0x1AF4). Drop the warning message. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just after SMI broadcastLaszlo Ersek2020-08-271-6/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick succession -- it means a series of "device_add" QEMU monitor commands, back-to-back. If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then: - the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the SMI pending for the new CPU -- at that time, the new CPU doesn't even exist yet, - OVMF will find the new CPU however (in the CPU hotplug register block), in QemuCpuhpCollectApicIds(). As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI), the new CPU instead boots straight into the post-RSM (normal mode) "pen", skipping its initial SMI handler. The CPU halts nicely in the pen, but its SMBASE is never relocated, and the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck in the following loop: // // Wait until the hot-added CPU is just about to execute RSM. // while (Context->AboutToLeaveSmm == 0) { CpuPause (); } because the new CPU's initial SMI handler never sets the flag to nonzero. Fix this by sending a directed SMI to the new CPU just before sending it the INIT-SIPI-SIPI. The various scenarios are documented in the code -- the cases affected by the patch are documented under point (2). Note that this is not considered a security patch, as for a malicious guest OS, the issue is not exploitable -- the symptom is a hang on the BSP, in the above-noted loop in SmbaseRelocate(). Instead, the patch fixes behavior for a benign guest OS. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: 51a6fb41181529e4b50ea13377425bda6bb69ba6 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200826222129.25798-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/CpuHotplugSmm: fix CPU hotplug race just before SMI broadcastLaszlo Ersek2020-08-271-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick succession -- it means a series of "device_add" QEMU monitor commands, back-to-back. If a "device_add" occurs *just before* ACPI raises the broadcast SMI, then: - OVMF processes the hot-added CPU well. - However, QEMU's post-SMI ACPI loop -- which clears the pending events for the hot-added CPUs that were collected before raising the SMI -- is unaware of the stray CPU. Thus, the pending event is not cleared for it. As a result of the stuck event, at the next hot-plug, OVMF tries to re-add (relocate for the 2nd time) the already-known CPU. At that time, the AP is already in the normal edk2 SMM busy-wait however, so it doesn't respond to the exchange that the BSP intends to do in SmbaseRelocate(). Thus the VM gets stuck in SMM. (Because of the above symptom, this is not considered a security patch; it doesn't seem exploitable by a malicious guest OS.) In CpuHotplugMmi(), skip the supposedly hot-added CPU if it's already known. The post-SMI ACPI loop will clear the pending event for it this time. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: bc498ac4ca7590479cfd91ad1bb8a36286b0dc21 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200826222129.25798-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/Bhyve: rename files to remove 'Pkg' infixRebecca Cran2020-08-243-2/+2
| | | | | | | | | | | | | | OvmfPkg is the package, so while there are files to build bhyve separately, they shouldn't have 'Pkg' in the name. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Peter Grehan <grehan@freebsd.org> Message-Id: <20200818021035.6479-1-rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/SmmControl2Dxe: negotiate ICH9_LPC_SMI_F_CPU_HOTPLUGLaszlo Ersek2020-08-242-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ICH9_LPC_SMI_F_BROADCAST and ICH9_LPC_SMI_F_CPU_HOTPLUG feature flags cause QEMU to behave as follows: BROADCAST CPU_HOTPLUG use case / behavior --------- ----------- ------------------------------------------------ clear clear OVMF built without SMM_REQUIRE; or very old OVMF (from before commit a316d7ac91d3 / 2017-02-07). QEMU permits CPU hotplug operations, and does not cause the OS to inject an SMI upon hotplug. Firmware is not expected to be aware of hotplug events. clear set Invalid feature set; QEMU rejects the feature negotiation. set clear OVMF after a316d7ac91d3 / 2017-02-07, built with SMM_REQUIRE, but no support for CPU hotplug. QEMU gracefully refuses hotplug operations. set set OVMF after a316d7ac91d3 / 2017-02-07, built with SMM_REQUIRE, and supporting CPU hotplug. QEMU permits CPU hotplug operations, and causes the OS to inject an SMI upon hotplug. Firmware is expected to deal with hotplug events. Negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG -- but only if SEV is disabled, as OvmfPkg/CpuHotplugSmm can't deal with SEV yet. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Liran Alon <liran.alon@oracle.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200714184305.9814-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: Fix spelling mistake for occurredMichael D Kinney2020-08-193-3/+3
| | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2361 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Guomin Jiang <guomin.jiang@intel.com>
* OvmfPkg/OvmfPkg.ci.yaml: Add configuration for Ecc checkShenglei Zhang2020-08-171-0/+12
| | | | | | | | | | | | Add configuration ExceptionList and IgnoreFiles for package config files. So users can rely on this to ignore some Ecc issues. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* OvmfPkg: Move the GHCB allocations into reserved memoryTom Lendacky2020-08-171-1/+3
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 After having transitioned from UEFI to the OS, the OS will need to boot the APs. For an SEV-ES guest, the APs will have been parked by UEFI using GHCB pages allocated by UEFI. The hypervisor will write to the GHCB SW_EXITINFO2 field of the GHCB when the AP is booted. As a result, the GHCB pages must be marked reserved so that the OS does not attempt to use them and experience memory corruption because of the hypervisor write. Change the GHCB allocation from the default boot services memory to reserved memory. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vectorTom Lendacky2020-08-172-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 A hypervisor is not allowed to update an SEV-ES guest's register state, so when booting an SEV-ES guest AP, the hypervisor is not allowed to set the RIP to the guest requested value. Instead an SEV-ES AP must be re-directed from within the guest to the actual requested staring location as specified in the INIT-SIPI-SIPI sequence. Use the SEV-ES work area for the reset vector code that contains support to jump to the desired RIP location after having been started. This is required for only the very first AP reset. This new OVMF source file, ResetVectorVtf0.asm, is used in place of the original file through the use of the include path order set in OvmfPkg/ResetVector/ResetVector.inf under "[BuildOptions]". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with SEV-ESTom Lendacky2020-08-175-3/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 The flash detection routine will attempt to determine how the flash device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and the flash device behaves as a ROM device (meaning it is marked read-only by the hypervisor), this check may result in an infinite nested page fault because of the attempted write. Since the instruction cannot be emulated when SEV-ES is enabled, the RIP is never advanced, resulting in repeated nested page faults. When SEV-ES is enabled, exit the flash detection early and assume that the FD behaves as Flash. This will result in QemuFlashWrite() being called to store EFI variables, which will also result in an infinite nested page fault when the write is performed. In this case, update QemuFlashWrite() to use the VMGEXIT MMIO write support to have the hypervisor perform the write without having to emulate the instruction. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Sec: Enable cache early to speed up bootingTom Lendacky2020-08-171-0/+7
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Currently, the OVMF code relies on the hypervisor to enable the cache support on the processor in order to improve the boot speed. However, with SEV-ES, the hypervisor is not allowed to change the CR0 register to enable caching. Update the OVMF Sec support to enable caching in order to improve the boot speed when running as an SEV-ES guest. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Sec: Add #VC exception handling for Sec phaseTom Lendacky2020-08-172-13/+173
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 An SEV-ES guest will generate a #VC exception when it encounters a non-automatic exit (NAE) event. It is expected that the #VC exception handler will communicate with the hypervisor using the GHCB to handle the NAE event. NAE events can occur during the Sec phase, so initialize exception handling early in the OVMF Sec support. Before establishing the exception handling, validate that the supported version of the SEV-ES protocol in OVMF is supported by the hypervisor. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/ResetVector: Add support for a 32-bit SEV checkTom Lendacky2020-08-173-3/+277
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 During BSP startup, the reset vector code will issue a CPUID instruction while in 32-bit mode. When running as an SEV-ES guest, this will trigger a #VC exception. Add exception handling support to the early reset vector code to catch these exceptions. Also, since the guest is in 32-bit mode at this point, writes to the GHCB will be encrypted and thus not able to be read by the hypervisor, so use the GHCB CPUID request/response protocol to obtain the requested CPUID function values and provide these to the guest. The exception handling support is active during the SEV check and uses the OVMF temporary RAM space for a stack. After the SEV check is complete, the exception handling support is removed and the stack pointer cleared. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformPei: Reserve SEV-ES work area if S3 is supportedTom Lendacky2020-08-172-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Protect the SEV-ES work area memory used by an SEV-ES guest. Regarding the lifecycle of the SEV-ES memory area: PcdSevEsWorkArea (a) when and how it is initialized after first boot of the VM If SEV-ES is enabled, the SEV-ES area is initialized during the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm]. (b) how it is protected from memory allocations during DXE If SEV-ES is enabled, then InitializeRamRegions() [OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with either an AcpiNVS (S3 enabled) or BootServicesData (S3 disabled) memory allocation HOB, in PEI. (c) how it is protected from the OS If S3 is enabled, then (b) reserves it from the OS too. If S3 is disabled, then the range needs no protection. (d) how it is accessed on the S3 resume path It is rewritten same as in (a), which is fine because (b) reserved it. (e) how it is accessed on the warm reset path It is rewritten same as in (a). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Reserve a page in memory for the SEV-ES usageTom Lendacky2020-08-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Reserve a fixed area of memory for SEV-ES use and set a fixed PCD, PcdSevEsWorkAreaBase, to this value. This area will be used by SEV-ES support for two purposes: 1. Communicating the SEV-ES status during BSP boot to SEC: Using a byte of memory from the page, the BSP reset vector code can communicate the SEV-ES status to SEC for use before exception handling can be enabled in SEC. After SEC, this field is no longer valid and the standard way of determine if SEV-ES is active should be used. 2. Establishing an area of memory for AP boot support: A hypervisor is not allowed to update an SEV-ES guest's register state, so when booting an SEV-ES guest AP, the hypervisor is not allowed to set the RIP to the guest requested value. Instead an SEV-ES AP must be re-directed from within the guest to the actual requested staring location as specified in the INIT-SIPI-SIPI sequence. Use this memory for reset vector code that can be programmed to have the AP jump to the desired RIP location after starting the AP. This is required for only the very first AP reset. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformPei: Move early GDT into ram when SEV-ES is enabledTom Lendacky2020-08-171-0/+18
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 The SEV support will clear the C-bit from non-RAM areas. The early GDT lives in a non-RAM area, so when an exception occurs (like a #VC) the GDT will be read as un-encrypted even though it is encrypted. This will result in a failure to be able to handle the exception. Move the GDT into RAM so it can be accessed without error when running as an SEV-ES guest. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Create GHCB pages for use during Pei and Dxe phaseTom Lendacky2020-08-175-1/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Allocate memory for the GHCB pages and the per-CPU variable pages during SEV initialization for use during Pei and Dxe phases. The GHCB page(s) must be shared pages, so clear the encryption mask from the current page table entries. Upon successful allocation, set the GHCB PCDs (PcdGhcbBase and PcdGhcbSize). The per-CPU variable page needs to be unique per AP. Using the page after the GHCB ensures that it is unique per AP. Only the GHCB page is marked as shared, keeping the per-CPU variable page encyrpted. The same logic is used in DXE using CreateIdentityMappingPageTables() before switching to the DXE pagetables. The GHCB pages (one per vCPU) will be used by the PEI and DXE #VC exception handlers. The #VC exception handler will fill in the necessary fields of the GHCB and exit to the hypervisor using the VMGEXIT instruction. The hypervisor then accesses the GHCB associated with the vCPU in order to perform the requested function. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformPei: Reserve GHCB-related areas if S3 is supportedTom Lendacky2020-08-172-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Protect the memory used by an SEV-ES guest when S3 is supported. This includes the page table used to break down the 2MB page that contains the GHCB so that it can be marked un-encrypted, as well as the GHCB area. Regarding the lifecycle of the GHCB-related memory areas: PcdOvmfSecGhcbPageTableBase PcdOvmfSecGhcbBase (a) when and how it is initialized after first boot of the VM If SEV-ES is enabled, the GHCB-related areas are initialized during the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm]. (b) how it is protected from memory allocations during DXE If S3 and SEV-ES are enabled, then InitializeRamRegions() [OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with an AcpiNVS memory allocation HOB, in PEI. If S3 is disabled, then these ranges are not protected. DXE's own page tables are first built while still in PEI (see HandOffToDxeCore() [MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c]). Those tables are located in permanent PEI memory. After CR3 is switched over to them (which occurs before jumping to the DXE core entry point), we don't have to preserve PcdOvmfSecGhcbPageTableBase. PEI switches to GHCB pages in permanent PEI memory and DXE will use these PEI GHCB pages, so we don't have to preserve PcdOvmfSecGhcbBase. (c) how it is protected from the OS If S3 is enabled, then (b) reserves it from the OS too. If S3 is disabled, then the range needs no protection. (d) how it is accessed on the S3 resume path It is rewritten same as in (a), which is fine because (b) reserved it. (e) how it is accessed on the warm reset path It is rewritten same as in (a). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-27 02:16:01 +0000