summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/AmdSev/AmdSevX64.dsc
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: clear PcdConOut{Row,Column}Gerd Hoffmann2022-04-221-0/+2
| | | | | | | | | ConSplitterDxe will pick the highest available resolution then, thereby making better use of the available display space. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Add CcProbeLib in *.dscMin Xu2022-04-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902 CcProbeLib is imported in BaseIoLibIntrinsicSev. OvmfPkg/Library/CcProbeLib is the OvmfPkg version which checks OvmfWorkArea to return the Cc guest type. It is included in OvmfPkgX64.dsc and IntelTdx/IntelTdxX64.dsc. Other .dsc include the MdePkg/Library/CcProbeLibNull because Cc guest is not supported in those projects. Cc: James Bottomley <jejb@linux.ibm.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Switch timer in build time for OvmfPkgMin Xu2022-04-021-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3711 Discussion in https://bugzilla.tianocore.org/show_bug.cgi?id=1496 shows that 8254TimerDxe was not written for OVMF. It was moved over from PcAtChipsetPkg to OvmfPkg in 2019. Probably because OVMF was the only user left. Most likely the reason OVMF used 8254TimerDxe initially was that it could just use the existing driver in PcAtChipsetPkg. And it simply hasn't been changed ever. CSM support was moved in 2019 too. (CSM support depends on 8254/8259 drivers). So 8254TimerDxe will be used when CSM_ENABLE=TRUE. There are 4 .dsc which include the 8254Timer. - OvmfPkg/AmdSev/AmdSevX64.dsc - OvmfPkg/OvmfPkgIa32.dsc - OvmfPkg/OvmfPkgIa32X64.dsc - OvmfPkg/OvmfPkgX64.dsc For the three OvmfPkg* configs using 8254TimerDxe with CSM_ENABLE=TRUE and LapicTimerDxe otherwise. For the AmdSev config it doesn't make sense to support a CSM. So use the lapic timer unconditionally. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Update IoMmuDxe to support TDXMin Xu2022-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 The IOMMU protocol driver provides capabilities to set a DMA access attribute and methods to allocate, free, map and unmap the DMA memory for the PCI Bus devices. The current IoMmuDxe driver supports DMA operations inside SEV guest. To support DMA operation in TDX guest, CC_GUEST_IS_XXX (PcdConfidentialComputingGuestAttr) is used to determine if it is SEV guest or TDX guest. Due to security reasons all DMA operations inside the SEV/TDX guest must be performed on shared pages. The IOMMU protocol driver for the SEV/TDX guest uses a bounce buffer to map guest DMA buffer to shared pages in order to provide the support for DMA operations inside SEV/TDX guest. The call of SEV or TDX specific function to set/clear EncMask/SharedBit is determined by CC_GUEST_IS_XXX (PcdConfidentialComputingGuestAttr). Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* MdeModulePkg: Add PcdTdxSharedBitMaskMin Xu2022-04-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Guest Physical Address (GPA) space in Td guest is divided into private and shared sub-spaces, determined by the SHARED bit of GPA. This PCD holds the shared bit mask. Its default value is 0 and it will be set in PlatformPei driver if it is of Td guest. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Update Sec to support TdxMin Xu2022-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 There are below major changes in this commit. 1. SecEntry.nasm In TDX BSP and APs goes to the same entry point in SecEntry.nasm. BSP initialize the temporary stack and then jumps to SecMain, just as legacy Ovmf does. APs spin in a modified mailbox loop using initial mailbox structure. Its structure defition is in OvmfPkg/Include/IndustryStandard/IntelTdx.h. APs wait for command to see if the command is for me. If so execute the command. 2. Sec/SecMain.c When host VMM create the Td guest, the system memory informations are stored in TdHob, which is a memory region described in Tdx metadata. The system memory region in TdHob should be accepted before it can be accessed. So the major task of this patch is to process the TdHobList to accept the memory. After that TDVF follow the standard OVMF flow and jump to PEI phase. PcdUse1GPageTable is set to FALSE by default in OvmfPkgX64.dsc. It gives no chance for Intel TDX to support 1G page table. To support 1G page table this PCD is set to TRUE in OvmfPkgX64.dsc. TDX_GUEST_SUPPORTED is defined in OvmfPkgX64.dsc. This macro wraps the Tdx specific code. TDX only works on X64, so the code is only valid in X64 arch. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Create initial version of PlatformInitLibMin Xu2022-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3863 There are 3 variants of PlatformPei in OvmfPkg: - OvmfPkg/PlatformPei - OvmfPkg/XenPlatformPei - OvmfPkg/Bhyve/PlatformPei/PlatformPei.inf These PlatformPeis can share many common codes, such as Cmos / Hob / Memory / Platform related functions. This commit (and its following several patches) are to create a PlatformInitLib which wraps the common code called in above PlatformPeis. In this initial version of PlatformInitLib, below Cmos related functions are introduced: - PlatformCmosRead8 - PlatformCmosWrite8 - PlatformDebugDumpCmos They correspond to the functions in OvmfPkg/PlatformPei: - CmosRead8 - CmosWrite8 - DebugDumpCmos Considering this PlatformInitLib will be used in SEC phase, global variables and dynamic PCDs are avoided. We use PlatformInfoHob to exchange information between functions. EFI_HOB_PLATFORM_INFO is the data struct which contains the platform information, such as HostBridgeDevId, BootMode, S3Supported, SmmSmramRequire, etc. After PlatformInitLib is created, OvmfPkg/PlatformPei is refactored with this library. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: add PcdVideoResolutionSourceGerd Hoffmann2022-01-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's a UINT8 (enum) PCD telling where the PcdVideoHorizontalResolution and PcdVideoVerticalResolution values are coming from. It can be: 0 (unset aka default from dsc file), or 1 (from PlatformConfig), or 2 (set by Video Driver). It will be used by video drivers to avoid overriding PlatformConfig values, or override each others values in case multiple display devices are present. The underlying problem this tries to solve is that the GOP protocol has no way to indicate the preferred video mode. On physical hardware this isn't much of a problem because using the highest resolution available works just fine as that is typically the native display resolution But in a virtual machine you don't want come up with a huge 4k window by default just because the virtual vga is able to handle that. Cutting down the video mode list isn't a great solution either as that would also remove the modes from the platform configuration so the user wouldn't be able to pick a resolution higher than the default any more. So with patch drivers can use use PcdVideoHorizontalResolution and PcdVideoVerticalResolution to indicate what the preferred display resolution is, without overwriting the user preferences from PlatformConfig if present. A possible alternative approach would be to extend the GOP protocol, but I'm not sure this is a good plan given this is mostly a problem for virtual machines and using PCDs allows to keep this local to OvmfPkg. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: change qemu default resolution to 1280x800Gerd Hoffmann2022-01-291-2/+2
| | | | | | | | | | | | | | ovmf default display resolution is 800x600. This is rather small for modern guests. qemu used 1024x768 as default for a long time and switched the to 1280x800 recently[1] for the upcoming 7.0 release. This patch brings ovmf in sync with the recent qemu update and likewise switches the default to 1280x800. [1] https://gitlab.com/qemu-project/qemu/-/commit/de72c4b7cdf6ec18bfe9fe714aa96e48db6fd895 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: move tcg configuration to dsc and fdf include filesGerd Hoffmann2021-12-151-74/+11
| | | | | | | | | | | With this in place the tpm configuration is not duplicated for each of our four ovmf config variants (ia32, ia32x64, x64, amdsev) and it is easier to keep them all in sync when updating the tpm configuration. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
* OvmfPkg-EmuVariableFvbRuntimeDxe: Support Access To Memory Above 4Glixianglai2021-12-111-0/+2
| | | | | | | | | | | | | | | | In FvbInitialize Function, PcdFlashNvStorageVariableBase64 PcdFlashNvStorageFtwWorkingBase PcdFlashNvStorageFtwSpareBase will not exceed 0x100000000, Due to truncation and variable type limitations. That leads to the NV variable cannot be saved to the memory above 4G. Modify as follows: 1.Remove the forced type conversion of UINT32. 2.Use UINT64 type variables. Signed-off-by: xianglai li <lixianglai@loongson.cn> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Generalize AcpiPlatformDxeSebastien Boeuf2021-12-111-1/+1
| | | | | | | | | | | | Don't make the package Qemu centric so that we can introduce some alternative support for other VMMs not using the fw_cfg mechanism. This patch is purely about renaming existing files with no functional change. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg: Remove unused print service driver (PrintDxe)Philippe Mathieu-Daude2021-12-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | PrintDxe produces gEfiPrint2ProtocolGuid and gEfiPrint2SProtocolGuid, and those are consumed by the following PrintLib instance: MdeModulePkg/Library/DxePrintLibPrint2Protocol/DxePrintLibPrint2Protocol.inf However, none of the OVMF DSC files contain such a PrintLib class resolution, so none of the OVMF platforms need PrintDxe. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3744 Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformPei: set PcdConfidentialComputingAttr when SEV is activeBrijesh Singh2021-12-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The MpInitLib uses the ConfidentialComputingAttr PCD to determine whether AMD SEV is active so that it can use the VMGEXITs defined in the GHCB specification to create APs. Cc: Michael Roth <michael.roth@amd.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/AmdSevDxe: do not use extended PCI config spaceBrijesh Singh via groups.io2021-12-091-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Commit 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803 added support to ensure that MMIO is only performed against the un-encrypted memory. If MMIO is performed against encrypted memory, a #GP is raised. The AmdSevDxe uses the functions provided by the MemEncryptSevLib to clear the memory encryption mask from the page table. If the MemEncryptSevLib is extended to include VmgExitLib then depedency chain will look like this: OvmfPkg/AmdSevDxe/AmdSevDxe.inf -----> MemEncryptSevLib class -----> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance -----> VmgExitLib class -----> "OvmfPkg/VmgExitLib" instance -----> LocalApicLib class -----> "UefiCpuPkg/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf" instance -----> TimerLib class -----> "OvmfPkg/AcpiTimerLib/DxeAcpiTimerLib.inf" instance -----> PciLib class -----> "OvmfPkg/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf" instance -----> PciExpressLib class -----> "MdePkg/BasePciExpressLib/BasePciExpressLib.inf" instance The LocalApicLib provides a constructor that gets called before the AmdSevDxe can clear the memory encryption mask from the MMIO regions. When running under the Q35 machine type, the call chain looks like this: AcpiTimerLibConstructor () [AcpiTimerLib] PciRead32 () [DxePciLibI440FxQ35] PciExpressRead32 () [PciExpressLib] The PciExpressRead32 () reads the MMIO region. The MMIO regions are not yet mapped un-encrypted, so the check introduced in the commit 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803 raises a #GP. The AmdSevDxe driver does not require the access to the extended PCI config space. Accessing a normal PCI config space, via IO port should be sufficent. Use the module-scope override to make the AmdSevDxe use the BasePciLib instead of BasePciExpressLib so that PciRead32 () uses the IO ports instead of the extended config space. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg: Reference new Tcg2PlatformPei in the build systemStefan Berger2021-09-301-0/+4
| | | | | | | | | | | | | | | | | | | Compile the Tcg2PlatformPei related code now to support TPM 2 platform hierachy disablement if the TPM state cannot be resumed upon S3 resume. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg: Reference new Tcg2PlatformDxe in the build system for compilationStefan Berger2021-09-301-0/+4
| | | | | | | | | | | | | | | | | | Compile the Tcg2PlatformDxe related code now. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/AmdSev: Enforce hash verification of kernel blobsDov Murik2021-07-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | In the AmdSevX64 build, use BlobVerifierLibSevHashes to enforce verification of hashes of the kernel/initrd/cmdline blobs fetched from firmware config. This allows for secure (measured) boot of SEV guests with QEMU's -kernel/-initrd/-append switches (with the corresponding QEMU support for injecting the hashes table into initial measured guest memory). Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ashish Kalra <ashish.kalra@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: add BlobVerifierLibNull to DSCDov Murik2021-07-291-1/+5
| | | | | | | | | | | | | | | | | | | This prepares the ground for calling VerifyBlob() in QemuKernelLoaderFsDxe. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ashish Kalra <ashish.kalra@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: PlatformBootManagerLibGrub: Allow executing kernel via fw_cfgJames Bottomley2021-07-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | Support QEMU's -kernel option. Create a QemuKernel.c for PlatformBootManagerLibGrub which is an exact copy of the file PlatformBootManagerLib/QemuKernel.c . Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ashish Kalra <ashish.kalra@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/AmdSev: use GenericQemuLoadImageLib in AmdSev buildsDov Murik2021-07-291-1/+1
| | | | | | | | | | | | | | | | | | | | | Newer kernels support efistub and therefore don't need all the legacy stuff in X86QemuLoadImageLib, which are harder to secure. Specifically the verification of kernel/initrd/cmdline blobs will be added only to the GenericQemuLoadImageLib implementation, so use that for SEV builds. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ashish Kalra <ashish.kalra@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: drop PcdPciDisableBusEnumeration from the AmdSev platformLaszlo Ersek2021-06-041-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | With the Xen-dependent PcdSetBoolS() call removed from OvmfPkg/PlatformPei, the "AmdSevX64.dsc" platform never writes "PcdPciDisableBusEnumeration". This means we don't need a dynamic default for the PCD in the DSC file; it could be declared Fixed-at-Build. However, because the PCD's default value in "MdeModulePkg.dec" is FALSE, remove the (same-value) platform default altogether. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-24-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: switch the AmdSev platform to the fw_cfg-only ACPI platform driverLaszlo Ersek2021-06-041-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | For consistency with the historical OvmfPkg* platforms, switch the remotely attested, QEMU/KVM-only, AmdSev platform from the AcpiPlatformDxe driver to the QemuFwCfgAcpiPlatformDxe driver. No module remains dependent on XenPlatformLib, so remove the XenPlatformLib class resolution too, from the DSC file. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg: remove the Xen drivers from the AmdSev platformLaszlo Ersek2021-06-041-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | For symmetry with the historical OvmfPkg* platforms, remove the three Xen drivers from the remotely attested, QEMU/KVM-only, AmdSev platform. Xen (HVM and PVH) guests are supported by the dedicated OvmfXen platform. No module remains dependent on XenHypercallLib, so remove the XenHypercallLib class resolution too, from the DSC file. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210526201446.12554-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/TpmMmioSevDecryptPei: Mark TPM MMIO range as unencrypted for SEV-ESLendacky, Thomas2021-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3345 During PEI, the MMIO range for the TPM is marked as encrypted when running as an SEV guest. While this isn't an issue for an SEV guest because of the way the nested page fault is handled, it does result in an SEV-ES guest terminating because of a mitigation check in the #VC handler to prevent MMIO to an encrypted address. For an SEV-ES guest, this range must be marked as unencrypted. Create a new x86 PEIM for TPM support that will map the TPM MMIO range as unencrypted when SEV-ES is active. The gOvmfTpmMmioAccessiblePpiGuid PPI will be unconditionally installed before exiting. The PEIM will exit with the EFI_ABORTED status so that the PEIM does not stay resident. This new PEIM will depend on the installation of the permanent PEI RAM, by PlatformPei, so that in case page table splitting is required during the clearing of the encryption bit, the new page table(s) will be allocated from permanent PEI RAM. Update all OVMF Ia32 and X64 build packages to include this new PEIM. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <42794cec1f9d5bc24cbfb9dcdbe5e281ef259ef5.1619716333.git.thomas.lendacky@amd.com> [lersek@redhat.com: refresh subject line] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add MicrocodeLib in DSC files.Ray Ni2021-04-091-0/+1
| | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3303 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Consume MdeLibs.dsc.inc for RegisterFilterLibDandan Bi2021-03-311-1/+4
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246 MdeLibs.dsc.inc was added for some basic/default library instances provided by MdePkg and RegisterFilterLibNull Library was also added into it as the first version of MdeLibs.dsc.inc. So update platform dsc to consume MdeLibs.dsc.inc for RegisterFilterLibNull which will be consumed by IoLib and BaseLib. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: strip build paths in release buildsRoss Burton2021-03-241-0/+1
| | | | | | | | | | | | GenFw will embed a NB10 section which contains the path to the input file, which means the output files have build paths embedded in them. To reduce information leakage and ensure reproducible builds, pass --zero in release builds to remove this information. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3256 Signed-off-by: Ross Burton <ross.burton@arm.com> Message-Id: <20210324115819.605436-1-ross.burton@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Introduce PciHostBridgeUtilityLib classJiahui Cen via groups.io2021-01-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | Introduce a new PciHostBridgeUtilityLib class to share duplicate code between OvmfPkg and ArmVirtPkg. Extract function PciHostBridgeUtilityResourceConflict from PciHostBridgeResourceConflict in OvmfPkg/PciHostBridgeLib. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3059 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210119011302.10908-2-cenjiahui@huawei.com>
* OvmfPkg: disable list length checks in NOOPT and DEBUG buildsLaszlo Ersek2021-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In NOOPT and DEBUG builds, if "PcdMaximumLinkedListLength" is nonzero, then several LIST_ENTRY *node* APIs in BaseLib compare the *full* list length against the PCD. This turns the time complexity of node-level APIs from constant to linear, and that of full-list manipulations from linear to quadratic. As an example, consider the EFI_SHELL_FILE_INFO list, which is a data structure that's widely used in the UEFI shell. I randomly extracted 5000 files from "/usr/include" on my laptop, spanning 1095 subdirectories out of 1538, and then ran "DIR -R" in the UEFI shell on this tree. These are the wall-clock times: PcdMaximumLinkedListLength PcdMaximumLinkedListLength =1,000,000 =0 -------------------------- --------------------------- FAT 4 min 31 s 18 s virtio-fs 5 min 13 s 1 min 33 s Checking list lengths against an arbitrary maximum (default: 1,000,000) seems useless even in NOOPT and DEBUG builds, while the cost is significant; so set the PCD to 0. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3152 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20210113085453.10168-10-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvfmPkg/VmgExitLib: Validate #VC MMIO is to un-encrypted memoryTom Lendacky2021-01-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 When SEV-ES is active, and MMIO operation will trigger a #VC and the VmgExitLib exception handler will process this MMIO operation. A malicious hypervisor could try to extract information from encrypted memory by setting a reserved bit in the guests nested page tables for a non-MMIO area. This can result in the encrypted data being copied into the GHCB shared buffer area and accessed by the hypervisor. Prevent this by ensuring that the MMIO source/destination is un-encrypted memory. For the APIC register space, access is allowed in general. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <0cf28470ad5e694af45f7f0b35296628f819567d.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Support nested #VCsTom Lendacky2021-01-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 In order to be able to issue messages or make interface calls that cause another #VC (e.g. GetLocalApicBaseAddress () issues RDMSR), add support for nested #VCs. In order to support nested #VCs, GHCB backup pages are required. If a #VC is received while currently processing a #VC, a backup of the current GHCB content is made. This allows the #VC handler to continue processing the new #VC. Upon completion of the new #VC, the GHCB is restored from the backup page. The #VC recursion level is tracked in the per-vCPU variable area. Support is added to handle up to one nested #VC (or two #VCs total). If a second nested #VC is encountered, an ASSERT will be issued and the vCPU will enter CpuDeadLoop (). For SEC, the GHCB backup pages are reserved in the OvmfPkgX64.fdf memory layout, with two new fixed PCDs to provide the address and size of the backup area. For PEI/DXE, the GHCB backup pages are allocated as boot services pages using the memory allocation library. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <ac2e8203fc41a351b43f60d68bdad6b57c4fb106.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/MemEncryptSevLib: Add an interface to retrieve the encryption maskTom Lendacky2021-01-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 To ensure that we always use a validated encryption mask for an SEV-ES guest, create a new interface in the MemEncryptSevLib library to return the encryption mask. This can be used in place of the multiple locations where CPUID is used to retrieve the value (which would require validation again) and allows the validated mask to be returned. The PEI phase will use the value from the SEV-ES work area. Since the SEV-ES work area isn't valid in the DXE phase, the DXE phase will use the PcdPteMemoryEncryptionAddressOrMask PCD which is set during PEI. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <e12044dc01b21e6fc2e9535760ddf3a38a142a71.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration tableJames Bottomley2020-12-141-0/+1
| | | | | | | | | | | | | | Now that the secret area is protected by a boot time HOB, extract its location details into a configuration table referenced by gSevLaunchSecretGuid so the boot loader or OS can locate it before a call to ExitBootServices(). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-7-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: fix indentation of InstallConfigurationTable() args]
* OvmfPkg/AmdSev: assign and reserve the Sev Secret areaJames Bottomley2020-12-141-0/+1
| | | | | | | | | | | | | Create a one page secret area in the MEMFD and reserve the area with a boot time HOB. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-6-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: s/protect/reserve/g in the commit message, at Ard's and James's suggestion]
* OvmfPkg/AmdSev: add Grub Firmware Volume PackageJames Bottomley2020-12-141-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-141-0/+833
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-18 13:54:45 +0000