* [PATCH 0/4] SEV Encrypted Boot for Ovmf
@ 2020-11-12 0:13 James Bottomley
2020-11-12 0:13 ` [PATCH 1/4] OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF James Bottomley
` (8 more replies)
0 siblings, 9 replies; 35+ messages in thread
From: James Bottomley @ 2020-11-12 0:13 UTC (permalink / raw)
To: devel
Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin,
david.kaplan, jon.grimm, thomas.lendacky, jejb, frankeh,
Dr . David Alan Gilbert
From: James Bottomley <James.Bottomley@HansenPartnership.com>
This patch series is modelled on the structure of the Bhyve patches
for Ovmf, since it does somewhat similar things. This patch series
creates a separate build for an AmdSev OVMF.fd that does nothing
except combine with grub and boot straight through the internal grub
to try to mount an encrypted volume.
Concept: SEV Secure Encrypted Images
====================================
The SEV patches in Linux and OVMF allow for the booting of SEV VMs in
an encrypted state, but don't really show how this could be done with
an encrypted image. Since the key used to decrypt the image must be
maintained within the SEV encryption envelope, encrypted QCOW is not
an option because the key would then have to be known to QEMU which is
outside the encryption envelope. The proposal here is that an
encrypted image should be a QCOW image consisting of two partitions,
the normal unencrypted EFI partition (Identifying it as an OVMF
bootable image) and a luks encrypted root partition. The kernel would
be inside the encrypted root in the /boot directory. The secret
injected securely through QEMU is extracted by OVMF and passed to grub
which uses it to mount the encrypted root and boot the kernel
normally. The creator of the secret bundle must be satisfied with the
SEV attestation before the secret is constructed. Unfortunately, the
SEV attestation can only be on the first QEMU firmware volume and
nothing else, so this patch series builds grub itself into a firmware
volume and places it inside OVMF so that the entire boot system can be
attested. In a normal OVMF KVM system, the variable store is on the
second flash volume (which is read/write). Unfortunately, this
mutable configuration provided by the variables is outside the
attestation envelope and can significantly alter the boot path,
possibly leading to secret leak, so encrypted image boot should only
be done with the OVMF.fd that combines both the code and variables.
the OVMF.fd is constructed so that it becomes impossible to interrupt
the boot sequence after attestation and the system will either boot
the image or fail. The boot sequence runs the grub.efi embedded in the
OVMF firmware volume so the encrypted image owner knows their own
version of grub is the only one that will boot before injecting the
secret. Note this boot path actually ignores the unencrypted EFI
partition. However, as part of this design, the encrypted image may be
booted by a standard OVMF KVM boot and in that case, the user will
have to type the encryption password. This standard boot will be
insecure but it might be used by the constructor of the encrypted
images on their own private laptop, for instance. The standard boot
path will use the unencrypted EFI partition.
Patches Required Outside of OVMF
================================
There is a patch set to grub which allows it to extract the SEV secret
area from the configuration table and use the secret as a password to
do a luks crypto mount of root (this is the sevsecret grub module).
There is also a patch to qemu which allows it to search through the
OVMF.fd and find the SEV secret area which is now described inside the
Reset Vector using the existing SEV_ES reset block. This area is the
place QEMU will inject the encrypted SEV secret bundle.
Security of the System
======================
Since Grub is now part of the attested OVMF.fd bundle, the VM owner
knows absolutely that it will proceed straight to partition decryption
inside the attested code and boot the kernel off the encrypted
partition. Even if a different QCOW image is substituted, the boot
will fail without revealing the secret because the system is designed
to fail hard in that case and because the secret is always contained
within the encrypted envelope it should be impossible for the cloud
operator to obtain it even if they can pause the boot and examine the
machine memory.
Putting it All Together
=======================
This is somewhat hard. You must first understand how to boot a QEMU
system so as to have the VM pause after firmware loading (-S option)
and use the qmp port to request an attestation. Only if the
attestation corresponds to the expected sha256sum of OVMF.fd should
the secret bundle be constructed and injected using qmp. The tools
for constructing the secret bundle are in
https://github.com/AMDESE/sev-tool/
James
---
James Bottomley (4):
OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF
OvmfPkg/AmdSev: add Grub Firmware Volume Package
OvmfPkg: create a SEV secret area in the AmdSev memfd
OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table
OvmfPkg/OvmfPkg.dec | 6 +
OvmfPkg/AmdSev/AmdSevX64.dsc | 1035 +++++++++++
OvmfPkg/AmdSev/AmdSevX64.fdf | 515 ++++++
OvmfPkg/AmdSev/Grub/Grub.inf | 37 +
.../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 +
.../SevLaunchSecret/SecretPei/SecretPei.inf | 46 +
.../PlatformBootManagerLibGrub.inf | 84 +
OvmfPkg/ResetVector/ResetVector.inf | 4 +
.../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++
.../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 +
.../SevLaunchSecret/SecretPei/SecretPei.c | 26 +
.../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++
.../PlatformBootManagerLibGrub/PlatformData.c | 213 +++
OvmfPkg/AmdSev/Grub/.gitignore | 1 +
OvmfPkg/AmdSev/Grub/grub.cfg | 35 +
OvmfPkg/AmdSev/Grub/grub.sh | 54 +
OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 +
OvmfPkg/ResetVector/ResetVector.nasmb | 2 +
18 files changed, 3846 insertions(+)
create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc
create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf
create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf
create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf
create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf
create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf
create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c
create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c
create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c
create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore
create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg
create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh
--
2.26.2
^ permalink raw reply [flat|nested] 35+ messages in thread* [PATCH 1/4] OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF 2020-11-12 0:13 [PATCH 0/4] SEV Encrypted Boot for Ovmf James Bottomley @ 2020-11-12 0:13 ` James Bottomley 2020-11-16 19:11 ` [edk2-devel] " Laszlo Ersek 2020-11-12 0:13 ` [PATCH 2/4] OvmfPkg/AmdSev: add Grub Firmware Volume Package James Bottomley ` (7 subsequent siblings) 8 siblings, 1 reply; 35+ messages in thread From: James Bottomley @ 2020-11-12 0:13 UTC (permalink / raw) To: devel Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, jejb, frankeh, Dr . David Alan Gilbert 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. Signed-off-by: James Bottomley <jejb@linux.ibm.com> --- OvmfPkg/AmdSev/AmdSevX64.dsc | 1024 ++++++++++++++++++++++++++++++++++ OvmfPkg/AmdSev/AmdSevX64.fdf | 506 +++++++++++++++++ 2 files changed, 1530 insertions(+) create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc new file mode 100644 index 0000000000..d1dfb8742f --- /dev/null +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc @@ -0,0 +1,1024 @@ +## @file +# EFI/Framework Open Virtual Machine Firmware (OVMF) platform for SEV +# +# Copyright (c) 2006 - 2020, Intel Corporation. All rights reserved.<BR> +# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR> +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +################################################################################ +# +# Defines Section - statements that will be processed to create a Makefile. +# +################################################################################ +[Defines] + PLATFORM_NAME = Ovmf + PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b + PLATFORM_VERSION = 0.1 + DSC_SPECIFICATION = 0x00010005 + OUTPUT_DIRECTORY = Build/AmdSev + SUPPORTED_ARCHITECTURES = X64 + BUILD_TARGETS = NOOPT|DEBUG|RELEASE + SKUID_IDENTIFIER = DEFAULT + FLASH_DEFINITION = OvmfPkg/AmdSev/AmdSevX64.fdf + + # + # Defines for default states. These can be changed on the command line. + # -D FLAG=VALUE + # + DEFINE SECURE_BOOT_ENABLE = FALSE + DEFINE SMM_REQUIRE = FALSE + DEFINE SOURCE_DEBUG_ENABLE = FALSE + DEFINE TPM_ENABLE = FALSE + DEFINE TPM_CONFIG_ENABLE = FALSE + + # + # Network definition + # + DEFINE NETWORK_TLS_ENABLE = FALSE + DEFINE NETWORK_IP6_ENABLE = FALSE + DEFINE NETWORK_HTTP_BOOT_ENABLE = FALSE + DEFINE NETWORK_ALLOW_HTTP_CONNECTIONS = TRUE + +!include NetworkPkg/NetworkDefines.dsc.inc + + # + # Device drivers + # + DEFINE PVSCSI_ENABLE = TRUE + DEFINE MPT_SCSI_ENABLE = TRUE + DEFINE LSI_SCSI_ENABLE = FALSE + + # + # Flash size selection. Setting FD_SIZE_IN_KB on the command line directly to + # one of the supported values, in place of any of the convenience macros, is + # permitted. + # +!ifdef $(FD_SIZE_1MB) + DEFINE FD_SIZE_IN_KB = 1024 +!else +!ifdef $(FD_SIZE_2MB) + DEFINE FD_SIZE_IN_KB = 2048 +!else +!ifdef $(FD_SIZE_4MB) + DEFINE FD_SIZE_IN_KB = 4096 +!else + DEFINE FD_SIZE_IN_KB = 4096 +!endif +!endif +!endif + +[BuildOptions] + GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG + INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG + MSFT:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG +!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(TOOL_CHAIN_TAG) != "CLANGPDB" + GCC:*_*_*_CC_FLAGS = -mno-mmx -mno-sse +!endif +!if $(SOURCE_DEBUG_ENABLE) == TRUE + MSFT:*_*_X64_GENFW_FLAGS = --keepexceptiontable + GCC:*_*_X64_GENFW_FLAGS = --keepexceptiontable + INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable +!endif + + # + # Disable deprecated APIs. + # + MSFT:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES + INTEL:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES + GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES + +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] + GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 + XCODE:*_*_*_DLINK_FLAGS = -seg1addr 0x1000 -segalign 0x1000 + XCODE:*_*_*_MTOC_FLAGS = -align 0x1000 + CLANGPDB:*_*_*_DLINK_FLAGS = /ALIGN:4096 + +# Force PE/COFF sections to be aligned at 4KB boundaries to support page level +# protection of DXE_SMM_DRIVER/SMM_CORE modules +[BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE] + GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 + XCODE:*_*_*_DLINK_FLAGS = -seg1addr 0x1000 -segalign 0x1000 + XCODE:*_*_*_MTOC_FLAGS = -align 0x1000 + CLANGPDB:*_*_*_DLINK_FLAGS = /ALIGN:4096 + +################################################################################ +# +# SKU Identification section - list of all SKU IDs supported by this Platform. +# +################################################################################ +[SkuIds] + 0|DEFAULT + +################################################################################ +# +# Library Class section - list of all Library Classes needed by this Platform. +# +################################################################################ +[LibraryClasses] + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf + TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf + ResetSystemLib|OvmfPkg/Library/ResetSystemLib/BaseResetSystemLib.inf + PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf + BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf + BaseLib|MdePkg/Library/BaseLib/BaseLib.inf + SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf + BmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf + SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf + CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf + PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf + PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf + CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf + UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf + UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf + HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf + SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf + UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf + BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf + FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf + CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf + DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf + DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf + PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf + PciCf8Lib|MdePkg/Library/BasePciCf8Lib/BasePciCf8Lib.inf + PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf + PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf + PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf + PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf + PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf + PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf + IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf + OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf + SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf + MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf + UefiLib|MdePkg/Library/UefiLib/UefiLib.inf + UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf + UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf + UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf + UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf + DevicePathLib|MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf + NvVarsFileLib|OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib.inf + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf + UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf + SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf + UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf + SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf + QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxeLib.inf + QemuFwCfgSimpleParserLib|OvmfPkg/Library/QemuFwCfgSimpleParserLib/QemuFwCfgSimpleParserLib.inf + VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf + LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf + MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf +!if $(SMM_REQUIRE) == FALSE + LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf +!endif + CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf + FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf + +!if $(SOURCE_DEBUG_ENABLE) == TRUE + PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf + DebugCommunicationLib|SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommunicationLibSerialPort.inf +!else + PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf + DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf +!endif + + LocalApicLib|UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf + DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf + + IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf +!if $(NETWORK_TLS_ENABLE) == TRUE + OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf +!else + OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf +!endif + RngLib|MdePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf + +!if $(SECURE_BOOT_ENABLE) == TRUE + PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf + AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf +!else + AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf +!endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf + + + # + # Network libraries + # +!include NetworkPkg/NetworkLibs.dsc.inc + +!if $(NETWORK_TLS_ENABLE) == TRUE + TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf +!endif + + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf + ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf + S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf + SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf + OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf + XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf + XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf + +!if $(TPM_ENABLE) == TRUE + Tpm12CommandLib|SecurityPkg/Library/Tpm12CommandLib/Tpm12CommandLib.inf + Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf + Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf + Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf + TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf +!else + Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf + TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf +!endif + +[LibraryClasses.common] + BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf + VmgExitLib|OvmfPkg/Library/VmgExitLib/VmgExitLib.inf + +[LibraryClasses.common.SEC] + TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf + QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf +!ifdef $(DEBUG_ON_SERIAL_PORT) + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf +!endif + ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf + ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf +!if $(SOURCE_DEBUG_ENABLE) == TRUE + DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf +!endif + HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf + PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf + PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf + MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf +!if $(TOOL_CHAIN_TAG) == "XCODE5" + CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf +!else + CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf +!endif + +[LibraryClasses.common.PEI_CORE] + HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf + PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf + PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf + MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf + PeiCoreEntryPoint|MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf + ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf + OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf + PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf +!ifdef $(DEBUG_ON_SERIAL_PORT) + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf +!endif + PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf + +[LibraryClasses.common.PEIM] + HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf + PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf + PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf + MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf + PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf + ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf + OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf + PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf +!ifdef $(DEBUG_ON_SERIAL_PORT) + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf +!endif + PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf + ResourcePublicationLib|MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.inf + ExtractGuidedSectionLib|MdePkg/Library/PeiExtractGuidedSectionLib/PeiExtractGuidedSectionLib.inf +!if $(SOURCE_DEBUG_ENABLE) == TRUE + DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf +!endif + CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf + MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf + QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf + PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf + QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf + +!if $(TPM_ENABLE) == TRUE + BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf + Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12DeviceLibDTpm.inf + Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf +!endif + +[LibraryClasses.common.DXE_CORE] + HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf + DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf + MemoryAllocationLib|MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf + ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf +!ifdef $(DEBUG_ON_SERIAL_PORT) + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf +!endif + ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf +!if $(SOURCE_DEBUG_ENABLE) == TRUE + DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf +!endif + CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf + PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf + +[LibraryClasses.common.DXE_RUNTIME_DRIVER] + PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf + TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf + ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.inf + HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf + DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf + MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf + ReportStatusCodeLib|MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf +!ifdef $(DEBUG_ON_SERIAL_PORT) + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf +!endif + UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf + BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf + PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf + QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf + +[LibraryClasses.common.UEFI_DRIVER] + PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf + TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf + ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.inf + HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf + DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf + MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf + ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf +!ifdef $(DEBUG_ON_SERIAL_PORT) + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf +!endif + UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf + PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf + +[LibraryClasses.common.DXE_DRIVER] + PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf + TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf + ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.inf + HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf + MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf + ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf + UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf +!ifdef $(DEBUG_ON_SERIAL_PORT) + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf +!endif + PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf + PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf + QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf + CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf +!if $(SMM_REQUIRE) == TRUE + LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf +!else + LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf +!endif +!if $(SOURCE_DEBUG_ENABLE) == TRUE + DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf +!endif + PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf + MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf + QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf + QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf +!if $(TPM_ENABLE) == TRUE + Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibTcg/Tpm12DeviceLibTcg.inf + Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf +!endif + +[LibraryClasses.common.UEFI_APPLICATION] + PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf + TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf + ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.inf + HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf + MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf + ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf +!ifdef $(DEBUG_ON_SERIAL_PORT) + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf +!endif + PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf + +[LibraryClasses.common.DXE_SMM_DRIVER] + PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf + TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf + ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.inf + MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf + ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf + HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf + SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf + MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf + SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf +!ifdef $(DEBUG_ON_SERIAL_PORT) + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf +!endif + CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf +!if $(SOURCE_DEBUG_ENABLE) == TRUE + DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf +!endif + BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf + PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf + +[LibraryClasses.common.SMM_CORE] + PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf + TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf + ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.inf + SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf + MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf + ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf + HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf + SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf + SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf +!ifdef $(DEBUG_ON_SERIAL_PORT) + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf +!endif + PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf + +################################################################################ +# +# Pcd Section - list of all EDK II PCD Entries defined by this Platform. +# +################################################################################ +[PcdsFeatureFlag] + gEfiMdeModulePkgTokenSpaceGuid.PcdHiiOsRuntimeSupport|FALSE + gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSupportUefiDecompress|FALSE + gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE + gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE + gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE + gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE +!ifdef $(CSM_ENABLE) + gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE +!endif +!if $(SMM_REQUIRE) == TRUE + gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE + gUefiCpuPkgTokenSpaceGuid.PcdCpuHotPlugSupport|TRUE + gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache|FALSE +!endif + +[PcdsFixedAtBuild] + gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1 +!if $(SMM_REQUIRE) == FALSE + gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE +!endif + gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x10 +!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048) + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000 + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800 +!if $(NETWORK_TLS_ENABLE) == FALSE + # match PcdFlashNvStorageVariableSize purely for convenience + gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000 +!endif +!endif +!if $(FD_SIZE_IN_KB) == 4096 + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400 + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400 +!if $(NETWORK_TLS_ENABLE) == FALSE + # match PcdFlashNvStorageVariableSize purely for convenience + gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x40000 +!endif +!endif +!if $(NETWORK_TLS_ENABLE) == TRUE + gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x80000 + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVolatileVariableSize|0x40000 +!endif + + gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0 + gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE + gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|TRUE + + gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07 + + # DEBUG_INIT 0x00000001 // Initialization + # DEBUG_WARN 0x00000002 // Warnings + # DEBUG_LOAD 0x00000004 // Load events + # DEBUG_FS 0x00000008 // EFI File system + # DEBUG_POOL 0x00000010 // Alloc & Free (pool) + # DEBUG_PAGE 0x00000020 // Alloc & Free (page) + # DEBUG_INFO 0x00000040 // Informational debug messages + # DEBUG_DISPATCH 0x00000080 // PEI/DXE/SMM Dispatchers + # DEBUG_VARIABLE 0x00000100 // Variable + # DEBUG_BM 0x00000400 // Boot Manager + # DEBUG_BLKIO 0x00001000 // BlkIo Driver + # DEBUG_NET 0x00004000 // SNP Driver + # DEBUG_UNDI 0x00010000 // UNDI Driver + # DEBUG_LOADFILE 0x00020000 // LoadFile + # DEBUG_EVENT 0x00080000 // Event messages + # DEBUG_GCD 0x00100000 // Global Coherency Database changes + # DEBUG_CACHE 0x00200000 // Memory range cachability changes + # DEBUG_VERBOSE 0x00400000 // Detailed debug messages that may + # // significantly impact boot performance + # DEBUG_ERROR 0x80000000 // Error + gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8000004F + +!if $(SOURCE_DEBUG_ENABLE) == TRUE + gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x17 +!else + gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F +!endif + + # This PCD is used to set the base address of the PCI express hierarchy. It + # is only consulted when OVMF runs on Q35. In that case it is programmed into + # the PCIEXBAR register. + # + # On Q35 machine types that QEMU intends to support in the long term, QEMU + # never lets the RAM below 4 GB exceed 2816 MB. + gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xB0000000 + +!if $(SOURCE_DEBUG_ENABLE) == TRUE + gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2 +!endif + + # + # The NumberOfPages values below are ad-hoc. They are updated sporadically at + # best (please refer to git-blame for past updates). The values capture a set + # of BIN hints that made sense at a particular time, for some (now likely + # unknown) workloads / boot paths. + # + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100 + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100 + + # + # Network Pcds + # +!include NetworkPkg/NetworkPcds.dsc.inc + +!if $(SMM_REQUIRE) == TRUE + gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000 +!endif + + # IRQs 5, 9, 10, 11 are level-triggered + gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20 + + # Point to the MdeModulePkg/Application/UiApp/UiApp.inf + gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 } + +################################################################################ +# +# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform +# +################################################################################ + +[PcdsDynamicDefault] + # only set when + # ($(SMM_REQUIRE) == FALSE) + gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0 + +!if $(SMM_REQUIRE) == FALSE + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0 + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0 + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0 +!endif + gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE + gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800 + gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600 + gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable|FALSE + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId|0 + gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase|0x0 + gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize|0x0 + gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0 + gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0 + gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0 +!ifdef $(CSM_ENABLE) + gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x0 +!else + gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x800000000 +!endif + + gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0 + + # Set video resolution for text setup. + gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution|640 + gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution|480 + + gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0208 + gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0 + gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE + + # Noexec settings for DXE. + gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE + + # UefiCpuPkg PCDs related to initial AP bringup and general AP management. + gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64 + gUefiCpuPkgTokenSpaceGuid.PcdCpuBootLogicalProcessorNumber|0 + + # Set memory encryption mask + gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0 + + # Set SEV-ES defaults + gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase|0 + gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize|0 + gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0 + +!if $(SMM_REQUIRE) == TRUE + gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8 + gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase|FALSE + gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01 + gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000 +!endif + + gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00 + +!if $(TPM_ENABLE) == TRUE + gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00} +!endif + + # IPv4 and IPv6 PXE Boot support. + gEfiNetworkPkgTokenSpaceGuid.PcdIPv4PXESupport|0x01 + gEfiNetworkPkgTokenSpaceGuid.PcdIPv6PXESupport|0x01 + +[PcdsDynamicHii] +!if $(TPM_ENABLE) == TRUE && $(TPM_CONFIG_ENABLE) == TRUE + gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer|L"TCG2_VERSION"|gTcg2ConfigFormSetGuid|0x0|"1.3"|NV,BS + gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev|L"TCG2_VERSION"|gTcg2ConfigFormSetGuid|0x8|3|NV,BS +!endif + +################################################################################ +# +# Components Section - list of all EDK II Modules needed by this Platform. +# +################################################################################ +[Components] + OvmfPkg/ResetVector/ResetVector.inf + + # + # SEC Phase modules + # + OvmfPkg/Sec/SecMain.inf { + <LibraryClasses> + NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf + } + + # + # PEI Phase modules + # + MdeModulePkg/Core/Pei/PeiMain.inf + MdeModulePkg/Universal/PCD/Pei/Pcd.inf { + <LibraryClasses> + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf + } + MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf { + <LibraryClasses> + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf + } + MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf { + <LibraryClasses> + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf + } + MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf + + OvmfPkg/PlatformPei/PlatformPei.inf + UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf { + <LibraryClasses> +!if $(SMM_REQUIRE) == TRUE + LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf +!endif + } +!if $(SMM_REQUIRE) == TRUE + MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf + MdeModulePkg/Universal/Variable/Pei/VariablePei.inf + OvmfPkg/SmmAccess/SmmAccessPei.inf +!endif + UefiCpuPkg/CpuMpPei/CpuMpPei.inf + +!if $(TPM_ENABLE) == TRUE + OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf + SecurityPkg/Tcg/TcgPei/TcgPei.inf + SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf { + <LibraryClasses> + HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf + NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf + NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf + NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf + NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf + NULL|SecurityPkg/Library/HashInstanceLibSm3/HashInstanceLibSm3.inf + } +!endif + + # + # DXE Phase modules + # + MdeModulePkg/Core/Dxe/DxeMain.inf { + <LibraryClasses> + NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf + DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf + } + + MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf + MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf + MdeModulePkg/Universal/PCD/Dxe/Pcd.inf { + <LibraryClasses> + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf + } + + MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf + + MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf { + <LibraryClasses> +!if $(SECURE_BOOT_ENABLE) == TRUE + NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf +!endif +!if $(TPM_ENABLE) == TRUE + NULL|SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.inf + NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf +!endif + } + + MdeModulePkg/Universal/EbcDxe/EbcDxe.inf + OvmfPkg/8259InterruptControllerDxe/8259.inf + UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf + UefiCpuPkg/CpuDxe/CpuDxe.inf + OvmfPkg/8254TimerDxe/8254Timer.inf + OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf + OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf + MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf { + <LibraryClasses> + PciHostBridgeLib|OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf + NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf + } + MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf { + <LibraryClasses> + PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf + } + MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf + MdeModulePkg/Universal/Metronome/Metronome.inf + PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf + MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf + MdeModulePkg/Universal/BdsDxe/BdsDxe.inf { + <LibraryClasses> +!ifdef $(CSM_ENABLE) + NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf + NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf +!endif + } + MdeModulePkg/Logo/LogoDxe.inf + MdeModulePkg/Application/UiApp/UiApp.inf { + <LibraryClasses> + NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf + NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf + NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf +!ifdef $(CSM_ENABLE) + NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf + NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf +!endif + } + OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf + OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf + OvmfPkg/Virtio10Dxe/Virtio10.inf + OvmfPkg/VirtioBlkDxe/VirtioBlk.inf + OvmfPkg/VirtioScsiDxe/VirtioScsi.inf + OvmfPkg/VirtioRngDxe/VirtioRng.inf + OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf + OvmfPkg/XenBusDxe/XenBusDxe.inf + OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf +!if $(PVSCSI_ENABLE) == TRUE + OvmfPkg/PvScsiDxe/PvScsiDxe.inf +!endif +!if $(MPT_SCSI_ENABLE) == TRUE + OvmfPkg/MptScsiDxe/MptScsiDxe.inf +!endif +!if $(LSI_SCSI_ENABLE) == TRUE + OvmfPkg/LsiScsiDxe/LsiScsiDxe.inf +!endif + MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf + MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf + MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf + MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf + MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf + MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf { + <LibraryClasses> + PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf + } + MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf + MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf { + <LibraryClasses> + DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf + PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf + } + MdeModulePkg/Universal/PrintDxe/PrintDxe.inf + MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf + MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf + MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf + MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf + FatPkg/EnhancedFatDxe/Fat.inf + MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf + MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf + MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf + OvmfPkg/SataControllerDxe/SataControllerDxe.inf + MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf + MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf + MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf + MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf + MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf + MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf + MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf + +!ifndef $(CSM_ENABLE) + OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf +!endif + OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf + OvmfPkg/VirtioGpuDxe/VirtioGpu.inf + + # + # ISA Support + # + OvmfPkg/SioBusDxe/SioBusDxe.inf + MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf + MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf + + # + # SMBIOS Support + # + MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf { + <LibraryClasses> + NULL|OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf + } + OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf + + # + # ACPI Support + # + MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf + OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf + OvmfPkg/AcpiTables/AcpiTables.inf + MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf + MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf + MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf + + # + # Network Support + # +!include NetworkPkg/NetworkComponents.dsc.inc + + NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf { + <LibraryClasses> + NULL|OvmfPkg/Library/PxeBcPcdProducerLib/PxeBcPcdProducerLib.inf + } + +!if $(NETWORK_TLS_ENABLE) == TRUE + NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf { + <LibraryClasses> + NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf + } +!endif + OvmfPkg/VirtioNetDxe/VirtioNet.inf + + # + # Usb Support + # + MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf + MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf + MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf + MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf + MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf + MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf + +!ifdef $(CSM_ENABLE) + OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf { + <LibraryClasses> + PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf + } + OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf + OvmfPkg/Csm/Csm16/Csm16.inf +!endif + +!if $(TOOL_CHAIN_TAG) != "XCODE5" + ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf { + <PcdsFixedAtBuild> + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE + } + ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf { + <PcdsFixedAtBuild> + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE + } + OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf { + <PcdsFixedAtBuild> + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE + } +!endif + ShellPkg/Application/Shell/Shell.inf { + <LibraryClasses> + ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf + NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf + NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf + NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf + NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf + NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf + NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf + NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf +!if $(NETWORK_IP6_ENABLE) == TRUE + NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf +!endif + HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf + PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf + BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf + + <PcdsFixedAtBuild> + gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF + gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE + gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000 + } + +!if $(SECURE_BOOT_ENABLE) == TRUE + SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf + OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf +!endif + + OvmfPkg/PlatformDxe/Platform.inf + OvmfPkg/AmdSevDxe/AmdSevDxe.inf + OvmfPkg/IoMmuDxe/IoMmuDxe.inf + +!if $(SMM_REQUIRE) == TRUE + OvmfPkg/SmmAccess/SmmAccess2Dxe.inf + OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf + OvmfPkg/CpuS3DataDxe/CpuS3DataDxe.inf + + # + # SMM Initial Program Load (a DXE_RUNTIME_DRIVER) + # + MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf + + # + # SMM_CORE + # + MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf + + # + # Privileged drivers (DXE_SMM_DRIVER modules) + # + OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf + UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf + MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf { + <LibraryClasses> + LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf + } + UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf { + <LibraryClasses> + SmmCpuPlatformHookLib|OvmfPkg/Library/SmmCpuPlatformHookLibQemu/SmmCpuPlatformHookLibQemu.inf + SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf + } + + # + # Variable driver stack (SMM) + # + OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf + MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf + MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf { + <LibraryClasses> + NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf + } + MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf + +!else + + # + # Variable driver stack (non-SMM) + # + OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf + OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf { + <LibraryClasses> + PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf + } + MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf + MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf { + <LibraryClasses> + NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf + } +!endif + + # + # TPM support + # +!if $(TPM_ENABLE) == TRUE + SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf { + <LibraryClasses> + Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf + NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf + HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf + NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf + NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf + NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf + NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf + NULL|SecurityPkg/Library/HashInstanceLibSm3/HashInstanceLibSm3.inf + } +!if $(TPM_CONFIG_ENABLE) == TRUE + SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf +!endif + SecurityPkg/Tcg/TcgDxe/TcgDxe.inf { + <LibraryClasses> + Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12DeviceLibDTpm.inf + } +!endif diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf new file mode 100644 index 0000000000..e874629a4e --- /dev/null +++ b/OvmfPkg/AmdSev/AmdSevX64.fdf @@ -0,0 +1,506 @@ +## @file +# Open Virtual Machine Firmware: FDF +# +# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR> +# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR> +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +################################################################################ + +[Defines] +!include OvmfPkg/OvmfPkgDefines.fdf.inc + +# +# Build the variable store and the firmware code as one unified flash device +# image. +# +[FD.OVMF] +BaseAddress = $(FW_BASE_ADDRESS) +Size = $(FW_SIZE) +ErasePolarity = 1 +BlockSize = $(BLOCK_SIZE) +NumBlocks = $(FW_BLOCKS) + +!include OvmfPkg/VarStore.fdf.inc + +$(VARS_SIZE)|$(FVMAIN_SIZE) +FV = FVMAIN_COMPACT + +$(SECFV_OFFSET)|$(SECFV_SIZE) +FV = SECFV + +################################################################################ + +[FD.MEMFD] +BaseAddress = $(MEMFD_BASE_ADDRESS) +Size = 0xD00000 +ErasePolarity = 1 +BlockSize = 0x10000 +NumBlocks = 0xD0 + +0x000000|0x006000 +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize + +0x006000|0x001000 +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize + +0x007000|0x001000 +gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize + +0x008000|0x001000 +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize + +0x009000|0x002000 +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize + +0x00B000|0x001000 +gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize + +0x010000|0x010000 +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize + +0x020000|0x0E0000 +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize +FV = PEIFV + +0x100000|0xC00000 +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize +FV = DXEFV + +################################################################################ + +[FV.SECFV] +FvNameGuid = 763BED0D-DE9F-48F5-81F1-3E90E1B1A015 +BlockSize = 0x1000 +FvAlignment = 16 +ERASE_POLARITY = 1 +MEMORY_MAPPED = TRUE +STICKY_WRITE = TRUE +LOCK_CAP = TRUE +LOCK_STATUS = TRUE +WRITE_DISABLED_CAP = TRUE +WRITE_ENABLED_CAP = TRUE +WRITE_STATUS = TRUE +WRITE_LOCK_CAP = TRUE +WRITE_LOCK_STATUS = TRUE +READ_DISABLED_CAP = TRUE +READ_ENABLED_CAP = TRUE +READ_STATUS = TRUE +READ_LOCK_CAP = TRUE +READ_LOCK_STATUS = TRUE + +# +# SEC Phase modules +# +# The code in this FV handles the initial firmware startup, and +# decompresses the PEI and DXE FVs which handles the rest of the boot sequence. +# +INF OvmfPkg/Sec/SecMain.inf + +INF RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf + +################################################################################ +[FV.PEIFV] +FvNameGuid = 6938079B-B503-4E3D-9D24-B28337A25806 +BlockSize = 0x10000 +FvAlignment = 16 +ERASE_POLARITY = 1 +MEMORY_MAPPED = TRUE +STICKY_WRITE = TRUE +LOCK_CAP = TRUE +LOCK_STATUS = TRUE +WRITE_DISABLED_CAP = TRUE +WRITE_ENABLED_CAP = TRUE +WRITE_STATUS = TRUE +WRITE_LOCK_CAP = TRUE +WRITE_LOCK_STATUS = TRUE +READ_DISABLED_CAP = TRUE +READ_ENABLED_CAP = TRUE +READ_STATUS = TRUE +READ_LOCK_CAP = TRUE +READ_LOCK_STATUS = TRUE + +APRIORI PEI { + INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf +} + +# +# PEI Phase modules +# +INF MdeModulePkg/Core/Pei/PeiMain.inf +INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf +INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf +INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf +INF OvmfPkg/PlatformPei/PlatformPei.inf +INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf +INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf +!if $(SMM_REQUIRE) == TRUE +INF MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf +INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf +INF OvmfPkg/SmmAccess/SmmAccessPei.inf +!endif +INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf + +!if $(TPM_ENABLE) == TRUE +INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf +INF SecurityPkg/Tcg/TcgPei/TcgPei.inf +INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf +!endif + +################################################################################ + +[FV.DXEFV] +FvForceRebase = FALSE +FvNameGuid = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1 +BlockSize = 0x10000 +FvAlignment = 16 +ERASE_POLARITY = 1 +MEMORY_MAPPED = TRUE +STICKY_WRITE = TRUE +LOCK_CAP = TRUE +LOCK_STATUS = TRUE +WRITE_DISABLED_CAP = TRUE +WRITE_ENABLED_CAP = TRUE +WRITE_STATUS = TRUE +WRITE_LOCK_CAP = TRUE +WRITE_LOCK_STATUS = TRUE +READ_DISABLED_CAP = TRUE +READ_ENABLED_CAP = TRUE +READ_STATUS = TRUE +READ_LOCK_CAP = TRUE +READ_LOCK_STATUS = TRUE + +APRIORI DXE { + INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf + INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf + INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf +!if $(SMM_REQUIRE) == FALSE + INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf +!endif +} + +# +# DXE Phase modules +# +INF MdeModulePkg/Core/Dxe/DxeMain.inf + +INF MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf +INF MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf +INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf + +INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf +INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf +INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf +INF OvmfPkg/8259InterruptControllerDxe/8259.inf +INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf +INF UefiCpuPkg/CpuDxe/CpuDxe.inf +INF OvmfPkg/8254TimerDxe/8254Timer.inf +INF OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf +INF OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf +INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf +INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf +INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf +INF MdeModulePkg/Universal/Metronome/Metronome.inf +INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf + +INF OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf +INF OvmfPkg/Virtio10Dxe/Virtio10.inf +INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf +INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf +INF OvmfPkg/VirtioRngDxe/VirtioRng.inf +INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf +INF OvmfPkg/XenBusDxe/XenBusDxe.inf +INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf +!if $(PVSCSI_ENABLE) == TRUE +INF OvmfPkg/PvScsiDxe/PvScsiDxe.inf +!endif +!if $(MPT_SCSI_ENABLE) == TRUE +INF OvmfPkg/MptScsiDxe/MptScsiDxe.inf +!endif +!if $(LSI_SCSI_ENABLE) == TRUE +INF OvmfPkg/LsiScsiDxe/LsiScsiDxe.inf +!endif + +!if $(SECURE_BOOT_ENABLE) == TRUE + INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf +!endif + +INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf +INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf +INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf +INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf +INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf +INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf +INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf +INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf +INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf +INF MdeModulePkg/Application/UiApp/UiApp.inf +INF OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf +INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf +INF MdeModulePkg/Universal/PrintDxe/PrintDxe.inf +INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf +INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf +INF MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf +INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf +INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf +INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf +INF OvmfPkg/SataControllerDxe/SataControllerDxe.inf +INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf +INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf +INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf +INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf +INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf +INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf +INF MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf + +INF OvmfPkg/SioBusDxe/SioBusDxe.inf +!if $(SOURCE_DEBUG_ENABLE) == FALSE +INF MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf +!endif +INF MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf + +INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf +INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf + +INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf +INF OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf +INF RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf +INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf +INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf +INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf + +INF FatPkg/EnhancedFatDxe/Fat.inf +INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf + +!if $(TOOL_CHAIN_TAG) != "XCODE5" +INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf +INF ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf +INF OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf +!endif +INF ShellPkg/Application/Shell/Shell.inf + +INF MdeModulePkg/Logo/LogoDxe.inf + +# +# Network modules +# +!if $(E1000_ENABLE) + FILE DRIVER = 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 { + SECTION PE32 = Intel3.5/EFIX64/E3522X2.EFI + } +!endif +!include NetworkPkg/Network.fdf.inc + INF OvmfPkg/VirtioNetDxe/VirtioNet.inf + +# +# Usb Support +# +INF MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf +INF MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf +INF MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf +INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf +INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf +INF MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf + +!ifdef $(CSM_ENABLE) +INF OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf +INF OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf +INF RuleOverride=CSM OvmfPkg/Csm/Csm16/Csm16.inf +!else +INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf +!endif + +INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf +INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf +INF OvmfPkg/PlatformDxe/Platform.inf +INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf +INF OvmfPkg/IoMmuDxe/IoMmuDxe.inf + +!if $(SMM_REQUIRE) == TRUE +INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf +INF OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf +INF OvmfPkg/CpuS3DataDxe/CpuS3DataDxe.inf +INF MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf +INF MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf +INF OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf +INF UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf +INF MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf +INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf + +# +# Variable driver stack (SMM) +# +INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf +INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf +INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf +INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf + +!else + +# +# Variable driver stack (non-SMM) +# +INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf +INF OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf +INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf +INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf +!endif + +# +# TPM support +# +!if $(TPM_ENABLE) == TRUE +INF SecurityPkg/Tcg/TcgDxe/TcgDxe.inf +INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf +!if $(TPM_CONFIG_ENABLE) == TRUE +INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf +!endif +!endif + +################################################################################ + +[FV.FVMAIN_COMPACT] +FvNameGuid = 48DB5E17-707C-472D-91CD-1613E7EF51B0 +FvAlignment = 16 +ERASE_POLARITY = 1 +MEMORY_MAPPED = TRUE +STICKY_WRITE = TRUE +LOCK_CAP = TRUE +LOCK_STATUS = TRUE +WRITE_DISABLED_CAP = TRUE +WRITE_ENABLED_CAP = TRUE +WRITE_STATUS = TRUE +WRITE_LOCK_CAP = TRUE +WRITE_LOCK_STATUS = TRUE +READ_DISABLED_CAP = TRUE +READ_ENABLED_CAP = TRUE +READ_STATUS = TRUE +READ_LOCK_CAP = TRUE +READ_LOCK_STATUS = TRUE + +FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 { + SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED = TRUE { + # + # These firmware volumes will have files placed in them uncompressed, + # and then both firmware volumes will be compressed in a single + # compression operation in order to achieve better overall compression. + # + SECTION FV_IMAGE = PEIFV + SECTION FV_IMAGE = DXEFV + } + } + +!include OvmfPkg/FvmainCompactScratchEnd.fdf.inc + +################################################################################ + +[Rule.Common.SEC] + FILE SEC = $(NAMED_GUID) { + PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi + UI STRING ="$(MODULE_NAME)" Optional + VERSION STRING ="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } + +[Rule.Common.PEI_CORE] + FILE PEI_CORE = $(NAMED_GUID) { + PE32 PE32 Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi + UI STRING ="$(MODULE_NAME)" Optional + VERSION STRING ="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } + +[Rule.Common.PEIM] + FILE PEIM = $(NAMED_GUID) { + PEI_DEPEX PEI_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex + PE32 PE32 Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi + UI STRING="$(MODULE_NAME)" Optional + VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } + +[Rule.Common.DXE_CORE] + FILE DXE_CORE = $(NAMED_GUID) { + PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi + UI STRING="$(MODULE_NAME)" Optional + VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } + +[Rule.Common.DXE_DRIVER] + FILE DRIVER = $(NAMED_GUID) { + DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex + PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi + UI STRING="$(MODULE_NAME)" Optional + VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + RAW ACPI Optional |.acpi + RAW ASL Optional |.aml + } + +[Rule.Common.DXE_RUNTIME_DRIVER] + FILE DRIVER = $(NAMED_GUID) { + DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex + PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi + UI STRING="$(MODULE_NAME)" Optional + VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } + +[Rule.Common.UEFI_DRIVER] + FILE DRIVER = $(NAMED_GUID) { + DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex + PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi + UI STRING="$(MODULE_NAME)" Optional + VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } + +[Rule.Common.UEFI_DRIVER.BINARY] + FILE DRIVER = $(NAMED_GUID) { + DXE_DEPEX DXE_DEPEX Optional |.depex + PE32 PE32 |.efi + UI STRING="$(MODULE_NAME)" Optional + VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } + +[Rule.Common.UEFI_APPLICATION] + FILE APPLICATION = $(NAMED_GUID) { + PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi + UI STRING="$(MODULE_NAME)" Optional + VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } + +[Rule.Common.UEFI_APPLICATION.BINARY] + FILE APPLICATION = $(NAMED_GUID) { + PE32 PE32 |.efi + UI STRING="$(MODULE_NAME)" Optional + VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } + +[Rule.Common.USER_DEFINED.ACPITABLE] + FILE FREEFORM = $(NAMED_GUID) { + RAW ACPI |.acpi + RAW ASL |.aml + } + +[Rule.Common.USER_DEFINED.CSM] + FILE FREEFORM = $(NAMED_GUID) { + RAW BIN |.bin + } + +[Rule.Common.SEC.RESET_VECTOR] + FILE RAW = $(NAMED_GUID) { + RAW BIN Align = 16 |.bin + } + +[Rule.Common.SMM_CORE] + FILE SMM_CORE = $(NAMED_GUID) { + PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi + UI STRING="$(MODULE_NAME)" Optional + VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } + +[Rule.Common.DXE_SMM_DRIVER] + FILE SMM = $(NAMED_GUID) { + SMM_DEPEX SMM_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex + PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi + UI STRING="$(MODULE_NAME)" Optional + VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) + } -- 2.26.2 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 1/4] OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF 2020-11-12 0:13 ` [PATCH 1/4] OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF James Bottomley @ 2020-11-16 19:11 ` Laszlo Ersek 2020-11-16 20:00 ` James Bottomley 0 siblings, 1 reply; 35+ messages in thread From: Laszlo Ersek @ 2020-11-16 19:11 UTC (permalink / raw) To: devel, jejb Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/12/20 01:13, James Bottomley wrote: > 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. > > Signed-off-by: James Bottomley <jejb@linux.ibm.com> > --- > OvmfPkg/AmdSev/AmdSevX64.dsc | 1024 ++++++++++++++++++++++++++++++++++ > OvmfPkg/AmdSev/AmdSevX64.fdf | 506 +++++++++++++++++ > 2 files changed, 1530 insertions(+) > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf > > diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc > new file mode 100644 > index 0000000000..d1dfb8742f > --- /dev/null > +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc > @@ -0,0 +1,1024 @@ > +## @file > +# EFI/Framework Open Virtual Machine Firmware (OVMF) platform for SEV (1) I suggest / request that we put "remote attestation" somewhere in the above file-top comment. > +# > +# Copyright (c) 2006 - 2020, Intel Corporation. All rights reserved.<BR> > +# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR> > +# > +# SPDX-License-Identifier: BSD-2-Clause-Patent > +# > +## (2) In every new file created in this series, please prepend an IBM Copyright Notice, to the original (C) notices (if any). > + > +################################################################################ > +# > +# Defines Section - statements that will be processed to create a Makefile. > +# > +################################################################################ > +[Defines] > + PLATFORM_NAME = Ovmf > + PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b (3) Please generate a new PLATFORM_GUID for this new platform with "uuidgen". > + PLATFORM_VERSION = 0.1 > + DSC_SPECIFICATION = 0x00010005 > + OUTPUT_DIRECTORY = Build/AmdSev > + SUPPORTED_ARCHITECTURES = X64 > + BUILD_TARGETS = NOOPT|DEBUG|RELEASE > + SKUID_IDENTIFIER = DEFAULT > + FLASH_DEFINITION = OvmfPkg/AmdSev/AmdSevX64.fdf > + > + # > + # Defines for default states. These can be changed on the command line. > + # -D FLAG=VALUE > + # > + DEFINE SECURE_BOOT_ENABLE = FALSE > + DEFINE SMM_REQUIRE = FALSE (4) SEV-ES doesn't support (to my knowledge) SMM, so we should strip everything dependent on SMM_REQUIRE being TRUE (DSC and FDF files both). (5) Given that SMM cannot protect Secure Boot, SECURE_BOOT_ENABLE too should be assumed FALSE, and stuff dependent on SECURE_BOOT_ENABLE being TRUE should be stripped. > + DEFINE SOURCE_DEBUG_ENABLE = FALSE > + DEFINE TPM_ENABLE = FALSE > + DEFINE TPM_CONFIG_ENABLE = FALSE > + > + # > + # Network definition > + # > + DEFINE NETWORK_TLS_ENABLE = FALSE > + DEFINE NETWORK_IP6_ENABLE = FALSE > + DEFINE NETWORK_HTTP_BOOT_ENABLE = FALSE > + DEFINE NETWORK_ALLOW_HTTP_CONNECTIONS = TRUE (6) My understanding is that netboot with this platform is never desired. If that's the case, then please remove: - all the NETWORK_* flags, - the dependent DSC/FDF snippets, - the gEfiNetworkPkgTokenSpaceGuid.* PCD defaults, - and (in particular) all !include directives that refer to NetworkPkg/* My goal with the above trimming is two-fold: - avoid an implication for platform builders that they can meaningfully tweak the -D flags for this platform, - cut down on the size of the new DSC/FDF files (given that the above fruits seem to hang low). Thanks Laszlo ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 1/4] OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF 2020-11-16 19:11 ` [edk2-devel] " Laszlo Ersek @ 2020-11-16 20:00 ` James Bottomley 0 siblings, 0 replies; 35+ messages in thread From: James Bottomley @ 2020-11-16 20:00 UTC (permalink / raw) To: devel, lersek Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On Mon, 2020-11-16 at 20:11 +0100, Laszlo Ersek wrote: > On 11/12/20 01:13, James Bottomley wrote: > > 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. > > > > Signed-off-by: James Bottomley <jejb@linux.ibm.com> > > --- > > OvmfPkg/AmdSev/AmdSevX64.dsc | 1024 > > ++++++++++++++++++++++++++++++++++ > > OvmfPkg/AmdSev/AmdSevX64.fdf | 506 +++++++++++++++++ > > 2 files changed, 1530 insertions(+) > > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc > > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf > > > > diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc > > b/OvmfPkg/AmdSev/AmdSevX64.dsc > > new file mode 100644 > > index 0000000000..d1dfb8742f > > --- /dev/null > > +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc > > @@ -0,0 +1,1024 @@ > > +## @file > > +# EFI/Framework Open Virtual Machine Firmware (OVMF) platform for > > SEV > > (1) I suggest / request that we put "remote attestation" somewhere in > the above file-top comment. OK, will add > > +# > > +# Copyright (c) 2006 - 2020, Intel Corporation. All rights > > reserved.<BR> > > +# (C) Copyright 2016 Hewlett Packard Enterprise Development > > LP<BR> > > +# > > +# SPDX-License-Identifier: BSD-2-Clause-Patent > > +# > > +## > > (2) In every new file created in this series, please prepend an IBM > Copyright Notice, to the original (C) notices (if any). OK, I can add one. > > + > > +################################################################## > > ############## > > +# > > +# Defines Section - statements that will be processed to create a > > Makefile. > > +# > > +################################################################## > > ############## > > +[Defines] > > + PLATFORM_NAME = Ovmf > > + PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad- > > 69eaa7b1539b > > (3) Please generate a new PLATFORM_GUID for this new platform with > "uuidgen". Sure ... I did do that the last time, I just forgot this time around. > > + PLATFORM_VERSION = 0.1 > > + DSC_SPECIFICATION = 0x00010005 > > + OUTPUT_DIRECTORY = Build/AmdSev > > + SUPPORTED_ARCHITECTURES = X64 > > + BUILD_TARGETS = NOOPT|DEBUG|RELEASE > > + SKUID_IDENTIFIER = DEFAULT > > + FLASH_DEFINITION = OvmfPkg/AmdSev/AmdSevX64.fdf > > + > > + # > > + # Defines for default states. These can be changed on the > > command line. > > + # -D FLAG=VALUE > > + # > > + DEFINE SECURE_BOOT_ENABLE = FALSE > > + DEFINE SMM_REQUIRE = FALSE > > (4) SEV-ES doesn't support (to my knowledge) SMM, so we should strip > everything dependent on SMM_REQUIRE being TRUE (DSC and FDF files > both). > > (5) Given that SMM cannot protect Secure Boot, SECURE_BOOT_ENABLE too > should be assumed FALSE, and stuff dependent on SECURE_BOOT_ENABLE > being > TRUE should be stripped. Yes, I believe neither of these is required. > > + DEFINE SOURCE_DEBUG_ENABLE = FALSE > > + DEFINE TPM_ENABLE = FALSE > > + DEFINE TPM_CONFIG_ENABLE = FALSE > > + > > + # > > + # Network definition > > + # > > + DEFINE NETWORK_TLS_ENABLE = FALSE > > + DEFINE NETWORK_IP6_ENABLE = FALSE > > + DEFINE NETWORK_HTTP_BOOT_ENABLE = FALSE > > + DEFINE NETWORK_ALLOW_HTTP_CONNECTIONS = TRUE > > (6) My understanding is that netboot with this platform is never > desired. If that's the case, then please remove: > - all the NETWORK_* flags, > - the dependent DSC/FDF snippets, > - the gEfiNetworkPkgTokenSpaceGuid.* PCD defaults, > - and (in particular) all !include directives that refer to > NetworkPkg/* I don't think we'll ever have a network dependency, no. > My goal with the above trimming is two-fold: > > - avoid an implication for platform builders that they can > meaningfully > tweak the -D flags for this platform, > > - cut down on the size of the new DSC/FDF files (given that the above > fruits seem to hang low). Will do. Regards, James ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 2/4] OvmfPkg/AmdSev: add Grub Firmware Volume Package 2020-11-12 0:13 [PATCH 0/4] SEV Encrypted Boot for Ovmf James Bottomley 2020-11-12 0:13 ` [PATCH 1/4] OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF James Bottomley @ 2020-11-12 0:13 ` James Bottomley 2020-11-16 20:42 ` [edk2-devel] " Laszlo Ersek 2020-11-12 0:13 ` [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd James Bottomley ` (6 subsequent siblings) 8 siblings, 1 reply; 35+ messages in thread From: James Bottomley @ 2020-11-12 0:13 UTC (permalink / raw) To: devel Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, jejb, frankeh, Dr . David Alan Gilbert 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 preven secret theft. Signed-off-by: James Bottomley <jejb@linux.ibm.com> --- OvmfPkg/OvmfPkg.dec | 1 + OvmfPkg/AmdSev/AmdSevX64.dsc | 14 +- OvmfPkg/AmdSev/AmdSevX64.fdf | 5 +- OvmfPkg/AmdSev/Grub/Grub.inf | 37 + .../PlatformBootManagerLibGrub.inf | 84 + .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++ .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++ .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++ OvmfPkg/AmdSev/Grub/.gitignore | 1 + OvmfPkg/AmdSev/Grub/grub.cfg | 35 + OvmfPkg/AmdSev/Grub/grub.sh | 54 + 11 files changed, 2157 insertions(+), 4 deletions(-) create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec index 6abde4fd93..3fbf7a0ee1 100644 --- a/OvmfPkg/OvmfPkg.dec +++ b/OvmfPkg/OvmfPkg.dec @@ -116,6 +116,7 @@ gEfiLegacyDevOrderVariableGuid = {0xa56074db, 0x65fe, 0x45f7, {0xbd, 0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96, 0x52}} gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}} gQemuKernelLoaderFsMediaGuid = {0x1428f772, 0xb64a, 0x441e, {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}} + gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}} [Ppis] # PPI whose presence in the PPI database signals that the TPM base address diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc index d1dfb8742f..7d3663150e 100644 --- a/OvmfPkg/AmdSev/AmdSevX64.dsc +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc @@ -23,6 +23,7 @@ BUILD_TARGETS = NOOPT|DEBUG|RELEASE SKUID_IDENTIFIER = DEFAULT FLASH_DEFINITION = OvmfPkg/AmdSev/AmdSevX64.fdf + PREBUILD = sh OvmfPkg/AmdSev/Grub/grub.sh # # Defines for default states. These can be changed on the command line. @@ -33,6 +34,7 @@ DEFINE SOURCE_DEBUG_ENABLE = FALSE DEFINE TPM_ENABLE = FALSE DEFINE TPM_CONFIG_ENABLE = FALSE + DEFINE BUILD_SHELL = FALSE # # Network definition @@ -159,7 +161,6 @@ UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf DevicePathLib|MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf - NvVarsFileLib|OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib.inf FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf @@ -213,8 +214,11 @@ TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf !endif +!if $(BUILD_SHELL) == TRUE ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf +!endif + S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf @@ -371,7 +375,7 @@ !else DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf !endif - PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf + PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf @@ -566,6 +570,7 @@ # Point to the MdeModulePkg/Application/UiApp/UiApp.inf gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 } + gEfiMdeModulePkgTokenSpaceGuid.PcdConInConnectOnDemand|TRUE ################################################################################ # # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform @@ -895,7 +900,7 @@ OvmfPkg/Csm/Csm16/Csm16.inf !endif -!if $(TOOL_CHAIN_TAG) != "XCODE5" +!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf { <PcdsFixedAtBuild> gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE @@ -909,6 +914,8 @@ gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE } !endif + OvmfPkg/AmdSev/Grub/Grub.inf +!if $(BUILD_SHELL) == TRUE ShellPkg/Application/Shell/Shell.inf { <LibraryClasses> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf @@ -931,6 +938,7 @@ gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000 } +!endif !if $(SECURE_BOOT_ENABLE) == TRUE SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf index e874629a4e..689386612d 100644 --- a/OvmfPkg/AmdSev/AmdSevX64.fdf +++ b/OvmfPkg/AmdSev/AmdSevX64.fdf @@ -275,12 +275,15 @@ INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour INF FatPkg/EnhancedFatDxe/Fat.inf INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf -!if $(TOOL_CHAIN_TAG) != "XCODE5" +!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(BUILD_SHELL) == TRUE INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf INF ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf INF OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf !endif +INF OvmfPkg/AmdSev/Grub/Grub.inf +!if $(BUILD_SHELL) == TRUE INF ShellPkg/Application/Shell/Shell.inf +!endif INF MdeModulePkg/Logo/LogoDxe.inf diff --git a/OvmfPkg/AmdSev/Grub/Grub.inf b/OvmfPkg/AmdSev/Grub/Grub.inf new file mode 100644 index 0000000000..a12428668b --- /dev/null +++ b/OvmfPkg/AmdSev/Grub/Grub.inf @@ -0,0 +1,37 @@ +## @file +# Create a Firmware Volume based Grub Bootloaded +# +# Copyright (C) 2020 James Bottomley, IBM Corporation. +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +[Defines] + INF_VERSION = 0x00010006 + BASE_NAME = Grub + # This is gGrubFileGuid + FILE_GUID = b5ae312c-bc8a-43b1-9c62-ebb826dd5d07 + MODULE_TYPE = UEFI_APPLICATION + VERSION_STRING = 1.0 + ENTRY_POINT = UefiMain + +[Packages] + OvmfPkg/OvmfPkg.dec + +# +# The following information is for reference only and not required by +# the build tools. +# +# VALID_ARCHITECTURES = IA32 X64 EBC +# + +## +# Note: The version of grub.efi this picks up can be generated by +# grub.sh which must be specified as a PREBUILD in the .dsc file or +# you can simply move a precompiled grub into here and not do the +# PREBUILD) +## +[Binaries] + PE32|grub.efi|* + diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf new file mode 100644 index 0000000000..62707b0bdd --- /dev/null +++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf @@ -0,0 +1,84 @@ +## @file +# Platform BDS customizations library. +# +# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.<BR> +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +[Defines] + INF_VERSION = 0x00010005 + BASE_NAME = PlatformBootManagerLibGrub + FILE_GUID = 3a8f8431-f0c9-4c95-8a1d-04445c582d4e + MODULE_TYPE = DXE_DRIVER + VERSION_STRING = 1.0 + LIBRARY_CLASS = PlatformBootManagerLib|DXE_DRIVER + +# +# The following information is for reference only and not required by the build tools. +# +# VALID_ARCHITECTURES = IA32 X64 EBC +# + +[Sources] + BdsPlatform.c + PlatformData.c + BdsPlatform.h + +[Packages] + MdePkg/MdePkg.dec + MdeModulePkg/MdeModulePkg.dec + SourceLevelDebugPkg/SourceLevelDebugPkg.dec + OvmfPkg/OvmfPkg.dec + SecurityPkg/SecurityPkg.dec + ShellPkg/ShellPkg.dec + +[LibraryClasses] + BaseLib + MemoryAllocationLib + UefiBootServicesTableLib + UefiRuntimeServicesTableLib + BaseMemoryLib + DebugLib + PcdLib + UefiBootManagerLib + BootLogoLib + DevicePathLib + PciLib + QemuFwCfgLib + QemuFwCfgS3Lib + QemuLoadImageLib + QemuBootOrderLib + ReportStatusCodeLib + UefiLib + PlatformBmPrintScLib + Tcg2PhysicalPresenceLib + XenPlatformLib + +[Pcd] + gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId + gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity ## CONSUMES + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES + +[Pcd.IA32, Pcd.X64] + gEfiMdePkgTokenSpaceGuid.PcdFSBClock + +[Protocols] + gEfiDecompressProtocolGuid + gEfiPciRootBridgeIoProtocolGuid + gEfiS3SaveStateProtocolGuid # PROTOCOL SOMETIMES_CONSUMED + gEfiDxeSmmReadyToLockProtocolGuid # PROTOCOL SOMETIMES_PRODUCED + gEfiLoadedImageProtocolGuid # PROTOCOL SOMETIMES_PRODUCED + gEfiFirmwareVolume2ProtocolGuid # PROTOCOL SOMETIMES_CONSUMED + +[Guids] + gEfiEndOfDxeEventGroupGuid + gEfiGlobalVariableGuid + gRootBridgesConnectedEventGroupGuid + gUefiShellFileGuid + gGrubFileGuid diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h new file mode 100644 index 0000000000..c6ccf9e52e --- /dev/null +++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h @@ -0,0 +1,179 @@ +/** @file + Platform BDS customizations include file. + + Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR> + SPDX-License-Identifier: BSD-2-Clause-Patent + +Module Name: + + BdsPlatform.h + +Abstract: + + Head file for BDS Platform specific code + +**/ + +#ifndef _PLATFORM_SPECIFIC_BDS_PLATFORM_H_ +#define _PLATFORM_SPECIFIC_BDS_PLATFORM_H_ + + +#include <PiDxe.h> + +#include <IndustryStandard/Pci.h> +#include <IndustryStandard/Acpi.h> +#include <IndustryStandard/SmBios.h> +#include <IndustryStandard/PeImage.h> +#include <IndustryStandard/Virtio095.h> + +#include <Library/DebugLib.h> +#include <Library/BaseMemoryLib.h> +#include <Library/UefiBootServicesTableLib.h> +#include <Library/UefiRuntimeServicesTableLib.h> +#include <Library/MemoryAllocationLib.h> +#include <Library/BaseLib.h> +#include <Library/PcdLib.h> +#include <Library/PciLib.h> +#include <Library/UefiBootManagerLib.h> +#include <Library/BootLogoLib.h> +#include <Library/HobLib.h> +#include <Library/UefiLib.h> +#include <Library/DxeServicesTableLib.h> +#include <Library/DevicePathLib.h> +#include <Library/IoLib.h> +#include <Library/NvVarsFileLib.h> +#include <Library/QemuFwCfgLib.h> +#include <Library/QemuFwCfgS3Lib.h> +#include <Library/QemuBootOrderLib.h> + +#include <Protocol/Decompress.h> +#include <Protocol/PciIo.h> +#include <Protocol/FirmwareVolume2.h> +#include <Protocol/SimpleFileSystem.h> +#include <Protocol/PciRootBridgeIo.h> +#include <Protocol/S3SaveState.h> +#include <Protocol/DxeSmmReadyToLock.h> +#include <Protocol/LoadedImage.h> + +#include <Guid/Acpi.h> +#include <Guid/SmBios.h> +#include <Guid/HobList.h> +#include <Guid/GlobalVariable.h> +#include <Guid/EventGroup.h> +#include <Guid/DebugAgentGuid.h> + +#include <OvmfPlatforms.h> + +extern EFI_DEVICE_PATH_PROTOCOL *gPlatformConnectSequence[]; +extern ACPI_HID_DEVICE_PATH gPnpPs2KeyboardDeviceNode; +extern ACPI_HID_DEVICE_PATH gPnp16550ComPortDeviceNode; +extern UART_DEVICE_PATH gUartDeviceNode; +extern VENDOR_DEVICE_PATH gTerminalTypeDeviceNode; + +#define PCI_DEVICE_PATH_NODE(Func, Dev) \ + { \ + { \ + HARDWARE_DEVICE_PATH, \ + HW_PCI_DP, \ + { \ + (UINT8) (sizeof (PCI_DEVICE_PATH)), \ + (UINT8) ((sizeof (PCI_DEVICE_PATH)) >> 8) \ + } \ + }, \ + (Func), \ + (Dev) \ + } + +#define PNPID_DEVICE_PATH_NODE(PnpId) \ + { \ + { \ + ACPI_DEVICE_PATH, \ + ACPI_DP, \ + { \ + (UINT8) (sizeof (ACPI_HID_DEVICE_PATH)), \ + (UINT8) ((sizeof (ACPI_HID_DEVICE_PATH)) >> 8) \ + }, \ + }, \ + EISA_PNP_ID((PnpId)), \ + 0 \ + } + +#define gPciIsaBridge \ + PCI_DEVICE_PATH_NODE(0, 0x1f) + +#define gP2PBridge \ + PCI_DEVICE_PATH_NODE(0, 0x1e) + +#define gPnpPs2Keyboard \ + PNPID_DEVICE_PATH_NODE(0x0303) + +#define gPnp16550ComPort \ + PNPID_DEVICE_PATH_NODE(0x0501) + +#define gUart \ + { \ + { \ + MESSAGING_DEVICE_PATH, \ + MSG_UART_DP, \ + { \ + (UINT8) (sizeof (UART_DEVICE_PATH)), \ + (UINT8) ((sizeof (UART_DEVICE_PATH)) >> 8) \ + } \ + }, \ + 0, \ + 115200, \ + 8, \ + 1, \ + 1 \ + } + +#define gPcAnsiTerminal \ + { \ + { \ + MESSAGING_DEVICE_PATH, \ + MSG_VENDOR_DP, \ + { \ + (UINT8) (sizeof (VENDOR_DEVICE_PATH)), \ + (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8) \ + } \ + }, \ + DEVICE_PATH_MESSAGING_PC_ANSI \ + } + +#define gEndEntire \ + { \ + END_DEVICE_PATH_TYPE, \ + END_ENTIRE_DEVICE_PATH_SUBTYPE, \ + { \ + END_DEVICE_PATH_LENGTH, \ + 0 \ + } \ + } + +#define PCI_CLASS_SCC 0x07 +#define PCI_SUBCLASS_SERIAL 0x00 +#define PCI_IF_16550 0x02 +#define IS_PCI_16550SERIAL(_p) IS_CLASS3 (_p, PCI_CLASS_SCC, PCI_SUBCLASS_SERIAL, PCI_IF_16550) +#define IS_PCI_ISA_PDECODE(_p) IS_CLASS3 (_p, PCI_CLASS_BRIDGE, PCI_CLASS_BRIDGE_ISA_PDECODE, 0) + +typedef struct { + EFI_DEVICE_PATH_PROTOCOL *DevicePath; + UINTN ConnectType; +} PLATFORM_CONSOLE_CONNECT_ENTRY; + +#define CONSOLE_OUT BIT0 +#define CONSOLE_IN BIT1 +#define STD_ERROR BIT2 +extern PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[]; +extern PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[]; + +// +// Platform BDS Functions +// + +VOID +PlatformInitializeConsole ( + IN PLATFORM_CONSOLE_CONNECT_ENTRY *PlatformConsole + ); + +#endif // _PLATFORM_SPECIFIC_BDS_PLATFORM_H_ diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c new file mode 100644 index 0000000000..24c37068a2 --- /dev/null +++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c @@ -0,0 +1,1538 @@ +/** @file + Platform BDS customizations. + + Copyright (c) 2004 - 2019, Intel Corporation. All rights reserved.<BR> + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#include "BdsPlatform.h" +#include <Guid/RootBridgesConnectedEventGroup.h> +#include <Protocol/FirmwareVolume2.h> +#include <Library/PlatformBmPrintScLib.h> +#include <Library/Tcg2PhysicalPresenceLib.h> +#include <Library/XenPlatformLib.h> + + +// +// Global data +// + +VOID *mEfiDevPathNotifyReg; +EFI_EVENT mEfiDevPathEvent; +UINT16 mHostBridgeDevId; + +// +// Table of host IRQs matching PCI IRQs A-D +// (for configuring PCI Interrupt Line register) +// +CONST UINT8 PciHostIrqs[] = { + 0x0a, 0x0a, 0x0b, 0x0b +}; + +// +// Type definitions +// + +typedef +EFI_STATUS +(EFIAPI *PROTOCOL_INSTANCE_CALLBACK)( + IN EFI_HANDLE Handle, + IN VOID *Instance, + IN VOID *Context + ); + +/** + @param[in] Handle - Handle of PCI device instance + @param[in] PciIo - PCI IO protocol instance + @param[in] Pci - PCI Header register block +**/ +typedef +EFI_STATUS +(EFIAPI *VISIT_PCI_INSTANCE_CALLBACK)( + IN EFI_HANDLE Handle, + IN EFI_PCI_IO_PROTOCOL *PciIo, + IN PCI_TYPE00 *Pci + ); + + +// +// Function prototypes +// + +EFI_STATUS +VisitAllInstancesOfProtocol ( + IN EFI_GUID *Id, + IN PROTOCOL_INSTANCE_CALLBACK CallBackFunction, + IN VOID *Context + ); + +EFI_STATUS +VisitAllPciInstancesOfProtocol ( + IN VISIT_PCI_INSTANCE_CALLBACK CallBackFunction + ); + +VOID +InstallDevicePathCallback ( + VOID + ); + +VOID +PlatformRegisterFvBootOption ( + EFI_GUID *FileGuid, + CHAR16 *Description, + UINT32 Attributes + ) +{ + EFI_STATUS Status; + INTN OptionIndex; + EFI_BOOT_MANAGER_LOAD_OPTION NewOption; + EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions; + UINTN BootOptionCount; + MEDIA_FW_VOL_FILEPATH_DEVICE_PATH FileNode; + EFI_LOADED_IMAGE_PROTOCOL *LoadedImage; + EFI_DEVICE_PATH_PROTOCOL *DevicePath; + + Status = gBS->HandleProtocol ( + gImageHandle, + &gEfiLoadedImageProtocolGuid, + (VOID **) &LoadedImage + ); + ASSERT_EFI_ERROR (Status); + + EfiInitializeFwVolDevicepathNode (&FileNode, FileGuid); + DevicePath = DevicePathFromHandle (LoadedImage->DeviceHandle); + ASSERT (DevicePath != NULL); + DevicePath = AppendDevicePathNode ( + DevicePath, + (EFI_DEVICE_PATH_PROTOCOL *) &FileNode + ); + ASSERT (DevicePath != NULL); + + Status = EfiBootManagerInitializeLoadOption ( + &NewOption, + LoadOptionNumberUnassigned, + LoadOptionTypeBoot, + Attributes, + Description, + DevicePath, + NULL, + 0 + ); + ASSERT_EFI_ERROR (Status); + FreePool (DevicePath); + + BootOptions = EfiBootManagerGetLoadOptions ( + &BootOptionCount, LoadOptionTypeBoot + ); + + OptionIndex = EfiBootManagerFindLoadOption ( + &NewOption, BootOptions, BootOptionCount + ); + + if (OptionIndex == -1) { + Status = EfiBootManagerAddLoadOptionVariable (&NewOption, MAX_UINTN); + ASSERT_EFI_ERROR (Status); + } + EfiBootManagerFreeLoadOption (&NewOption); + EfiBootManagerFreeLoadOptions (BootOptions, BootOptionCount); +} + +/** + Remove all MemoryMapped(...)/FvFile(...) and Fv(...)/FvFile(...) boot options + whose device paths do not resolve exactly to an FvFile in the system. + + Also strip out every boot option that is not an FvFile, meaning the system + can only boot either the Grub or (if built) the shell. + + This removes any boot options that point to binaries built into the firmware + and have become stale due to any of the following: + - DXEFV's base address or size changed (historical), + - DXEFV's FvNameGuid changed, + - the FILE_GUID of the pointed-to binary changed, + - the referenced binary is no longer built into the firmware. + + EfiBootManagerFindLoadOption() used in PlatformRegisterFvBootOption() only + avoids exact duplicates. +**/ +VOID +RemoveStaleFvFileOptions ( + VOID + ) +{ + EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions; + UINTN BootOptionCount; + UINTN Index; + + BootOptions = EfiBootManagerGetLoadOptions (&BootOptionCount, + LoadOptionTypeBoot); + + for (Index = 0; Index < BootOptionCount; ++Index) { + EFI_DEVICE_PATH_PROTOCOL *Node1, *Node2, *SearchNode; + EFI_STATUS Status; + EFI_HANDLE FvHandle; + + // + // If the device path starts with neither MemoryMapped(...) nor Fv(...), + // then delete the boot option. + // + Node1 = BootOptions[Index].FilePath; + if (!(DevicePathType (Node1) == HARDWARE_DEVICE_PATH && + DevicePathSubType (Node1) == HW_MEMMAP_DP) && + !(DevicePathType (Node1) == MEDIA_DEVICE_PATH && + DevicePathSubType (Node1) == MEDIA_PIWG_FW_VOL_DP)) { + EfiBootManagerDeleteLoadOptionVariable ( + BootOptions[Index].OptionNumber, LoadOptionTypeBoot); + continue; + } + + // + // If the second device path node is not FvFile(...), then delete the boot + // option. + // + Node2 = NextDevicePathNode (Node1); + if (DevicePathType (Node2) != MEDIA_DEVICE_PATH || + DevicePathSubType (Node2) != MEDIA_PIWG_FW_FILE_DP) { + EfiBootManagerDeleteLoadOptionVariable ( + BootOptions[Index].OptionNumber, LoadOptionTypeBoot); + continue; + } + + // + // Locate the Firmware Volume2 protocol instance that is denoted by the + // boot option. If this lookup fails (i.e., the boot option references a + // firmware volume that doesn't exist), then we'll proceed to delete the + // boot option. + // + SearchNode = Node1; + Status = gBS->LocateDevicePath (&gEfiFirmwareVolume2ProtocolGuid, + &SearchNode, &FvHandle); + + if (!EFI_ERROR (Status)) { + // + // The firmware volume was found; now let's see if it contains the FvFile + // identified by GUID. + // + EFI_FIRMWARE_VOLUME2_PROTOCOL *FvProtocol; + MEDIA_FW_VOL_FILEPATH_DEVICE_PATH *FvFileNode; + UINTN BufferSize; + EFI_FV_FILETYPE FoundType; + EFI_FV_FILE_ATTRIBUTES FileAttributes; + UINT32 AuthenticationStatus; + + Status = gBS->HandleProtocol (FvHandle, &gEfiFirmwareVolume2ProtocolGuid, + (VOID **)&FvProtocol); + ASSERT_EFI_ERROR (Status); + + FvFileNode = (MEDIA_FW_VOL_FILEPATH_DEVICE_PATH *)Node2; + // + // Buffer==NULL means we request metadata only: BufferSize, FoundType, + // FileAttributes. + // + Status = FvProtocol->ReadFile ( + FvProtocol, + &FvFileNode->FvFileName, // NameGuid + NULL, // Buffer + &BufferSize, + &FoundType, + &FileAttributes, + &AuthenticationStatus + ); + if (!EFI_ERROR (Status)) { + // + // The FvFile was found. Keep the boot option. + // + continue; + } + } + + // + // Delete the boot option. + // + Status = EfiBootManagerDeleteLoadOptionVariable ( + BootOptions[Index].OptionNumber, LoadOptionTypeBoot); + DEBUG_CODE ( + CHAR16 *DevicePathString; + + DevicePathString = ConvertDevicePathToText(BootOptions[Index].FilePath, + FALSE, FALSE); + DEBUG (( + EFI_ERROR (Status) ? DEBUG_WARN : DEBUG_VERBOSE, + "%a: removing stale Boot#%04x %s: %r\n", + __FUNCTION__, + (UINT32)BootOptions[Index].OptionNumber, + DevicePathString == NULL ? L"<unavailable>" : DevicePathString, + Status + )); + if (DevicePathString != NULL) { + FreePool (DevicePathString); + } + ); + } + + EfiBootManagerFreeLoadOptions (BootOptions, BootOptionCount); +} + +EFI_STATUS +EFIAPI +ConnectRootBridge ( + IN EFI_HANDLE RootBridgeHandle, + IN VOID *Instance, + IN VOID *Context + ); + +STATIC +EFI_STATUS +EFIAPI +ConnectVirtioPciRng ( + IN EFI_HANDLE Handle, + IN VOID *Instance, + IN VOID *Context + ); + +STATIC +VOID +SaveS3BootScript ( + VOID + ); + +// +// BDS Platform Functions +// +/** + Do the platform init, can be customized by OEM/IBV + + Possible things that can be done in PlatformBootManagerBeforeConsole: + + > Update console variable: 1. include hot-plug devices; + > 2. Clear ConIn and add SOL for AMT + > Register new Driver#### or Boot#### + > Register new Key####: e.g.: F12 + > Signal ReadyToLock event + > Authentication action: 1. connect Auth devices; + > 2. Identify auto logon user. +**/ +VOID +EFIAPI +PlatformBootManagerBeforeConsole ( + VOID + ) +{ + EFI_HANDLE Handle; + EFI_STATUS Status; + + DEBUG ((DEBUG_INFO, "PlatformBootManagerBeforeConsole\n")); + InstallDevicePathCallback (); + + VisitAllInstancesOfProtocol (&gEfiPciRootBridgeIoProtocolGuid, + ConnectRootBridge, NULL); + + // + // Signal the ACPI platform driver that it can download QEMU ACPI tables. + // + EfiEventGroupSignal (&gRootBridgesConnectedEventGroupGuid); + + // + // We can't signal End-of-Dxe earlier than this. Namely, End-of-Dxe triggers + // the preparation of S3 system information. That logic has a hard dependency + // on the presence of the FACS ACPI table. Since our ACPI tables are only + // installed after PCI enumeration completes, we must not trigger the S3 save + // earlier, hence we can't signal End-of-Dxe earlier. + // + EfiEventGroupSignal (&gEfiEndOfDxeEventGroupGuid); + + if (QemuFwCfgS3Enabled ()) { + // + // Save the boot script too. Note that this will require us to emit the + // DxeSmmReadyToLock event just below, which in turn locks down SMM. + // + SaveS3BootScript (); + } + + // + // Prevent further changes to LockBoxes or SMRAM. + // + Handle = NULL; + Status = gBS->InstallProtocolInterface (&Handle, + &gEfiDxeSmmReadyToLockProtocolGuid, EFI_NATIVE_INTERFACE, + NULL); + ASSERT_EFI_ERROR (Status); + + // + // Dispatch deferred images after EndOfDxe event and ReadyToLock + // installation. + // + EfiBootManagerDispatchDeferredImages (); + + PlatformInitializeConsole ( + XenDetected() ? gXenPlatformConsole : gPlatformConsole); + + // + // Install both VIRTIO_DEVICE_PROTOCOL and (dependent) EFI_RNG_PROTOCOL + // instances on Virtio PCI RNG devices. + // + VisitAllInstancesOfProtocol (&gEfiPciIoProtocolGuid, ConnectVirtioPciRng, + NULL); +} + + +EFI_STATUS +EFIAPI +ConnectRootBridge ( + IN EFI_HANDLE RootBridgeHandle, + IN VOID *Instance, + IN VOID *Context + ) +{ + EFI_STATUS Status; + + // + // Make the PCI bus driver connect the root bridge, non-recursively. This + // will produce a number of child handles with PciIo on them. + // + Status = gBS->ConnectController ( + RootBridgeHandle, // ControllerHandle + NULL, // DriverImageHandle + NULL, // RemainingDevicePath -- produce all + // children + FALSE // Recursive + ); + return Status; +} + + +STATIC +EFI_STATUS +EFIAPI +ConnectVirtioPciRng ( + IN EFI_HANDLE Handle, + IN VOID *Instance, + IN VOID *Context + ) +{ + EFI_PCI_IO_PROTOCOL *PciIo; + EFI_STATUS Status; + UINT16 VendorId; + UINT16 DeviceId; + UINT8 RevisionId; + BOOLEAN Virtio10; + UINT16 SubsystemId; + + PciIo = Instance; + + // + // Read and check VendorId. + // + Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_VENDOR_ID_OFFSET, + 1, &VendorId); + if (EFI_ERROR (Status)) { + goto Error; + } + if (VendorId != VIRTIO_VENDOR_ID) { + return EFI_SUCCESS; + } + + // + // Read DeviceId and RevisionId. + // + Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, PCI_DEVICE_ID_OFFSET, + 1, &DeviceId); + if (EFI_ERROR (Status)) { + goto Error; + } + Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint8, PCI_REVISION_ID_OFFSET, + 1, &RevisionId); + if (EFI_ERROR (Status)) { + goto Error; + } + + // + // From DeviceId and RevisionId, determine whether the device is a + // modern-only Virtio 1.0 device. In case of Virtio 1.0, DeviceId can + // immediately be restricted to VIRTIO_SUBSYSTEM_ENTROPY_SOURCE, and + // SubsystemId will only play a sanity-check role. Otherwise, DeviceId can + // only be sanity-checked, and SubsystemId will decide. + // + if (DeviceId == 0x1040 + VIRTIO_SUBSYSTEM_ENTROPY_SOURCE && + RevisionId >= 0x01) { + Virtio10 = TRUE; + } else if (DeviceId >= 0x1000 && DeviceId <= 0x103F && RevisionId == 0x00) { + Virtio10 = FALSE; + } else { + return EFI_SUCCESS; + } + + // + // Read and check SubsystemId as dictated by Virtio10. + // + Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint16, + PCI_SUBSYSTEM_ID_OFFSET, 1, &SubsystemId); + if (EFI_ERROR (Status)) { + goto Error; + } + if ((Virtio10 && SubsystemId >= 0x40) || + (!Virtio10 && SubsystemId == VIRTIO_SUBSYSTEM_ENTROPY_SOURCE)) { + Status = gBS->ConnectController ( + Handle, // ControllerHandle + NULL, // DriverImageHandle -- connect all drivers + NULL, // RemainingDevicePath -- produce all child handles + FALSE // Recursive -- don't follow child handles + ); + if (EFI_ERROR (Status)) { + goto Error; + } + } + return EFI_SUCCESS; + +Error: + DEBUG ((DEBUG_ERROR, "%a: %r\n", __FUNCTION__, Status)); + return Status; +} + + +/** + Add IsaKeyboard to ConIn; add IsaSerial to ConOut, ConIn, ErrOut. + + @param[in] DeviceHandle Handle of the LPC Bridge device. + + @retval EFI_SUCCESS Console devices on the LPC bridge have been added to + ConOut, ConIn, and ErrOut. + + @return Error codes, due to EFI_DEVICE_PATH_PROTOCOL missing + from DeviceHandle. +**/ +EFI_STATUS +PrepareLpcBridgeDevicePath ( + IN EFI_HANDLE DeviceHandle + ) +{ + EFI_STATUS Status; + EFI_DEVICE_PATH_PROTOCOL *DevicePath; + EFI_DEVICE_PATH_PROTOCOL *TempDevicePath; + CHAR16 *DevPathStr; + + DevicePath = NULL; + Status = gBS->HandleProtocol ( + DeviceHandle, + &gEfiDevicePathProtocolGuid, + (VOID*)&DevicePath + ); + if (EFI_ERROR (Status)) { + return Status; + } + TempDevicePath = DevicePath; + + // + // Register Keyboard + // + DevicePath = AppendDevicePathNode (DevicePath, + (EFI_DEVICE_PATH_PROTOCOL *)&gPnpPs2KeyboardDeviceNode); + + EfiBootManagerUpdateConsoleVariable (ConIn, DevicePath, NULL); + + // + // Register COM1 + // + DevicePath = TempDevicePath; + gPnp16550ComPortDeviceNode.UID = 0; + + DevicePath = AppendDevicePathNode (DevicePath, + (EFI_DEVICE_PATH_PROTOCOL *)&gPnp16550ComPortDeviceNode); + DevicePath = AppendDevicePathNode (DevicePath, + (EFI_DEVICE_PATH_PROTOCOL *)&gUartDeviceNode); + DevicePath = AppendDevicePathNode (DevicePath, + (EFI_DEVICE_PATH_PROTOCOL *)&gTerminalTypeDeviceNode); + + // + // Print Device Path + // + DevPathStr = ConvertDevicePathToText (DevicePath, FALSE, FALSE); + if (DevPathStr != NULL) { + DEBUG(( + DEBUG_INFO, + "BdsPlatform.c+%d: COM%d DevPath: %s\n", + __LINE__, + gPnp16550ComPortDeviceNode.UID + 1, + DevPathStr + )); + FreePool(DevPathStr); + } + + EfiBootManagerUpdateConsoleVariable (ConOut, DevicePath, NULL); + EfiBootManagerUpdateConsoleVariable (ConIn, DevicePath, NULL); + EfiBootManagerUpdateConsoleVariable (ErrOut, DevicePath, NULL); + + // + // Register COM2 + // + DevicePath = TempDevicePath; + gPnp16550ComPortDeviceNode.UID = 1; + + DevicePath = AppendDevicePathNode (DevicePath, + (EFI_DEVICE_PATH_PROTOCOL *)&gPnp16550ComPortDeviceNode); + DevicePath = AppendDevicePathNode (DevicePath, + (EFI_DEVICE_PATH_PROTOCOL *)&gUartDeviceNode); + DevicePath = AppendDevicePathNode (DevicePath, + (EFI_DEVICE_PATH_PROTOCOL *)&gTerminalTypeDeviceNode); + + // + // Print Device Path + // + DevPathStr = ConvertDevicePathToText (DevicePath, FALSE, FALSE); + if (DevPathStr != NULL) { + DEBUG(( + DEBUG_INFO, + "BdsPlatform.c+%d: COM%d DevPath: %s\n", + __LINE__, + gPnp16550ComPortDeviceNode.UID + 1, + DevPathStr + )); + FreePool(DevPathStr); + } + + EfiBootManagerUpdateConsoleVariable (ConOut, DevicePath, NULL); + EfiBootManagerUpdateConsoleVariable (ConIn, DevicePath, NULL); + EfiBootManagerUpdateConsoleVariable (ErrOut, DevicePath, NULL); + + return EFI_SUCCESS; +} + +EFI_STATUS +GetGopDevicePath ( + IN EFI_DEVICE_PATH_PROTOCOL *PciDevicePath, + OUT EFI_DEVICE_PATH_PROTOCOL **GopDevicePath + ) +{ + UINTN Index; + EFI_STATUS Status; + EFI_HANDLE PciDeviceHandle; + EFI_DEVICE_PATH_PROTOCOL *TempDevicePath; + EFI_DEVICE_PATH_PROTOCOL *TempPciDevicePath; + UINTN GopHandleCount; + EFI_HANDLE *GopHandleBuffer; + + if (PciDevicePath == NULL || GopDevicePath == NULL) { + return EFI_INVALID_PARAMETER; + } + + // + // Initialize the GopDevicePath to be PciDevicePath + // + *GopDevicePath = PciDevicePath; + TempPciDevicePath = PciDevicePath; + + Status = gBS->LocateDevicePath ( + &gEfiDevicePathProtocolGuid, + &TempPciDevicePath, + &PciDeviceHandle + ); + if (EFI_ERROR (Status)) { + return Status; + } + + // + // Try to connect this handle, so that GOP driver could start on this + // device and create child handles with GraphicsOutput Protocol installed + // on them, then we get device paths of these child handles and select + // them as possible console device. + // + gBS->ConnectController (PciDeviceHandle, NULL, NULL, FALSE); + + Status = gBS->LocateHandleBuffer ( + ByProtocol, + &gEfiGraphicsOutputProtocolGuid, + NULL, + &GopHandleCount, + &GopHandleBuffer + ); + if (!EFI_ERROR (Status)) { + // + // Add all the child handles as possible Console Device + // + for (Index = 0; Index < GopHandleCount; Index++) { + Status = gBS->HandleProtocol (GopHandleBuffer[Index], + &gEfiDevicePathProtocolGuid, (VOID*)&TempDevicePath); + if (EFI_ERROR (Status)) { + continue; + } + if (CompareMem ( + PciDevicePath, + TempDevicePath, + GetDevicePathSize (PciDevicePath) - END_DEVICE_PATH_LENGTH + ) == 0) { + // + // In current implementation, we only enable one of the child handles + // as console device, i.e. sotre one of the child handle's device + // path to variable "ConOut" + // In future, we could select all child handles to be console device + // + + *GopDevicePath = TempDevicePath; + + // + // Delete the PCI device's path that added by + // GetPlugInPciVgaDevicePath(). Add the integrity GOP device path. + // + EfiBootManagerUpdateConsoleVariable (ConOutDev, NULL, PciDevicePath); + EfiBootManagerUpdateConsoleVariable (ConOutDev, TempDevicePath, NULL); + } + } + gBS->FreePool (GopHandleBuffer); + } + + return EFI_SUCCESS; +} + +/** + Add PCI display to ConOut. + + @param[in] DeviceHandle Handle of the PCI display device. + + @retval EFI_SUCCESS The PCI display device has been added to ConOut. + + @return Error codes, due to EFI_DEVICE_PATH_PROTOCOL missing + from DeviceHandle. +**/ +EFI_STATUS +PreparePciDisplayDevicePath ( + IN EFI_HANDLE DeviceHandle + ) +{ + EFI_STATUS Status; + EFI_DEVICE_PATH_PROTOCOL *DevicePath; + EFI_DEVICE_PATH_PROTOCOL *GopDevicePath; + + DevicePath = NULL; + GopDevicePath = NULL; + Status = gBS->HandleProtocol ( + DeviceHandle, + &gEfiDevicePathProtocolGuid, + (VOID*)&DevicePath + ); + if (EFI_ERROR (Status)) { + return Status; + } + + GetGopDevicePath (DevicePath, &GopDevicePath); + DevicePath = GopDevicePath; + + EfiBootManagerUpdateConsoleVariable (ConOut, DevicePath, NULL); + + return EFI_SUCCESS; +} + +/** + Add PCI Serial to ConOut, ConIn, ErrOut. + + @param[in] DeviceHandle Handle of the PCI serial device. + + @retval EFI_SUCCESS The PCI serial device has been added to ConOut, ConIn, + ErrOut. + + @return Error codes, due to EFI_DEVICE_PATH_PROTOCOL missing + from DeviceHandle. +**/ +EFI_STATUS +PreparePciSerialDevicePath ( + IN EFI_HANDLE DeviceHandle + ) +{ + EFI_STATUS Status; + EFI_DEVICE_PATH_PROTOCOL *DevicePath; + + DevicePath = NULL; + Status = gBS->HandleProtocol ( + DeviceHandle, + &gEfiDevicePathProtocolGuid, + (VOID*)&DevicePath + ); + if (EFI_ERROR (Status)) { + return Status; + } + + DevicePath = AppendDevicePathNode (DevicePath, + (EFI_DEVICE_PATH_PROTOCOL *)&gUartDeviceNode); + DevicePath = AppendDevicePathNode (DevicePath, + (EFI_DEVICE_PATH_PROTOCOL *)&gTerminalTypeDeviceNode); + + EfiBootManagerUpdateConsoleVariable (ConOut, DevicePath, NULL); + EfiBootManagerUpdateConsoleVariable (ConIn, DevicePath, NULL); + EfiBootManagerUpdateConsoleVariable (ErrOut, DevicePath, NULL); + + return EFI_SUCCESS; +} + +EFI_STATUS +VisitAllInstancesOfProtocol ( + IN EFI_GUID *Id, + IN PROTOCOL_INSTANCE_CALLBACK CallBackFunction, + IN VOID *Context + ) +{ + EFI_STATUS Status; + UINTN HandleCount; + EFI_HANDLE *HandleBuffer; + UINTN Index; + VOID *Instance; + + // + // Start to check all the PciIo to find all possible device + // + HandleCount = 0; + HandleBuffer = NULL; + Status = gBS->LocateHandleBuffer ( + ByProtocol, + Id, + NULL, + &HandleCount, + &HandleBuffer + ); + if (EFI_ERROR (Status)) { + return Status; + } + + for (Index = 0; Index < HandleCount; Index++) { + Status = gBS->HandleProtocol (HandleBuffer[Index], Id, &Instance); + if (EFI_ERROR (Status)) { + continue; + } + + Status = (*CallBackFunction) ( + HandleBuffer[Index], + Instance, + Context + ); + } + + gBS->FreePool (HandleBuffer); + + return EFI_SUCCESS; +} + + +EFI_STATUS +EFIAPI +VisitingAPciInstance ( + IN EFI_HANDLE Handle, + IN VOID *Instance, + IN VOID *Context + ) +{ + EFI_STATUS Status; + EFI_PCI_IO_PROTOCOL *PciIo; + PCI_TYPE00 Pci; + + PciIo = (EFI_PCI_IO_PROTOCOL*) Instance; + + // + // Check for all PCI device + // + Status = PciIo->Pci.Read ( + PciIo, + EfiPciIoWidthUint32, + 0, + sizeof (Pci) / sizeof (UINT32), + &Pci + ); + if (EFI_ERROR (Status)) { + return Status; + } + + return (*(VISIT_PCI_INSTANCE_CALLBACK)(UINTN) Context) ( + Handle, + PciIo, + &Pci + ); + +} + + + +EFI_STATUS +VisitAllPciInstances ( + IN VISIT_PCI_INSTANCE_CALLBACK CallBackFunction + ) +{ + return VisitAllInstancesOfProtocol ( + &gEfiPciIoProtocolGuid, + VisitingAPciInstance, + (VOID*)(UINTN) CallBackFunction + ); +} + + +/** + Do platform specific PCI Device check and add them to + ConOut, ConIn, ErrOut. + + @param[in] Handle - Handle of PCI device instance + @param[in] PciIo - PCI IO protocol instance + @param[in] Pci - PCI Header register block + + @retval EFI_SUCCESS - PCI Device check and Console variable update + successfully. + @retval EFI_STATUS - PCI Device check or Console variable update fail. + +**/ +EFI_STATUS +EFIAPI +DetectAndPreparePlatformPciDevicePath ( + IN EFI_HANDLE Handle, + IN EFI_PCI_IO_PROTOCOL *PciIo, + IN PCI_TYPE00 *Pci + ) +{ + EFI_STATUS Status; + + Status = PciIo->Attributes ( + PciIo, + EfiPciIoAttributeOperationEnable, + EFI_PCI_DEVICE_ENABLE, + NULL + ); + ASSERT_EFI_ERROR (Status); + + // + // Here we decide whether it is LPC Bridge + // + if ((IS_PCI_LPC (Pci)) || + ((IS_PCI_ISA_PDECODE (Pci)) && + (Pci->Hdr.VendorId == 0x8086) && + (Pci->Hdr.DeviceId == 0x7000) + ) + ) { + // + // Add IsaKeyboard to ConIn, + // add IsaSerial to ConOut, ConIn, ErrOut + // + DEBUG ((DEBUG_INFO, "Found LPC Bridge device\n")); + PrepareLpcBridgeDevicePath (Handle); + return EFI_SUCCESS; + } + // + // Here we decide which Serial device to enable in PCI bus + // + if (IS_PCI_16550SERIAL (Pci)) { + // + // Add them to ConOut, ConIn, ErrOut. + // + DEBUG ((DEBUG_INFO, "Found PCI 16550 SERIAL device\n")); + PreparePciSerialDevicePath (Handle); + return EFI_SUCCESS; + } + + // + // Here we decide which display device to enable in PCI bus + // + if (IS_PCI_DISPLAY (Pci)) { + // + // Add them to ConOut. + // + DEBUG ((DEBUG_INFO, "Found PCI display device\n")); + PreparePciDisplayDevicePath (Handle); + return EFI_SUCCESS; + } + + return Status; +} + + +/** + Connect the predefined platform default console device. + + Always try to find and enable PCI display devices. + + @param[in] PlatformConsole Predefined platform default console device array. +**/ +VOID +PlatformInitializeConsole ( + IN PLATFORM_CONSOLE_CONNECT_ENTRY *PlatformConsole + ) +{ + UINTN Index; + + // + // Do platform specific PCI Device check and add them to ConOut, ConIn, + // ErrOut + // + VisitAllPciInstances (DetectAndPreparePlatformPciDevicePath); + + // + // Have chance to connect the platform default console, + // the platform default console is the minimum device group + // the platform should support + // + for (Index = 0; PlatformConsole[Index].DevicePath != NULL; ++Index) { + // + // Update the console variable with the connect type + // + if ((PlatformConsole[Index].ConnectType & CONSOLE_IN) == CONSOLE_IN) { + EfiBootManagerUpdateConsoleVariable (ConIn, + PlatformConsole[Index].DevicePath, NULL); + } + if ((PlatformConsole[Index].ConnectType & CONSOLE_OUT) == CONSOLE_OUT) { + EfiBootManagerUpdateConsoleVariable (ConOut, + PlatformConsole[Index].DevicePath, NULL); + } + if ((PlatformConsole[Index].ConnectType & STD_ERROR) == STD_ERROR) { + EfiBootManagerUpdateConsoleVariable (ErrOut, + PlatformConsole[Index].DevicePath, NULL); + } + } +} + + +/** + Configure PCI Interrupt Line register for applicable devices + Ported from SeaBIOS, src/fw/pciinit.c, *_pci_slot_get_irq() + + @param[in] Handle - Handle of PCI device instance + @param[in] PciIo - PCI IO protocol instance + @param[in] PciHdr - PCI Header register block + + @retval EFI_SUCCESS - PCI Interrupt Line register configured successfully. + +**/ +EFI_STATUS +EFIAPI +SetPciIntLine ( + IN EFI_HANDLE Handle, + IN EFI_PCI_IO_PROTOCOL *PciIo, + IN PCI_TYPE00 *PciHdr + ) +{ + EFI_DEVICE_PATH_PROTOCOL *DevPathNode; + EFI_DEVICE_PATH_PROTOCOL *DevPath; + UINTN RootSlot; + UINTN Idx; + UINT8 IrqLine; + EFI_STATUS Status; + UINT32 RootBusNumber; + + Status = EFI_SUCCESS; + + if (PciHdr->Device.InterruptPin != 0) { + + DevPathNode = DevicePathFromHandle (Handle); + ASSERT (DevPathNode != NULL); + DevPath = DevPathNode; + + RootBusNumber = 0; + if (DevicePathType (DevPathNode) == ACPI_DEVICE_PATH && + DevicePathSubType (DevPathNode) == ACPI_DP && + ((ACPI_HID_DEVICE_PATH *)DevPathNode)->HID == EISA_PNP_ID(0x0A03)) { + RootBusNumber = ((ACPI_HID_DEVICE_PATH *)DevPathNode)->UID; + } + + // + // Compute index into PciHostIrqs[] table by walking + // the device path and adding up all device numbers + // + Status = EFI_NOT_FOUND; + RootSlot = 0; + Idx = PciHdr->Device.InterruptPin - 1; + while (!IsDevicePathEnd (DevPathNode)) { + if (DevicePathType (DevPathNode) == HARDWARE_DEVICE_PATH && + DevicePathSubType (DevPathNode) == HW_PCI_DP) { + + Idx += ((PCI_DEVICE_PATH *)DevPathNode)->Device; + + // + // Unlike SeaBIOS, which starts climbing from the leaf device + // up toward the root, we traverse the device path starting at + // the root moving toward the leaf node. + // The slot number of the top-level parent bridge is needed for + // Q35 cases with more than 24 slots on the root bus. + // + if (Status != EFI_SUCCESS) { + Status = EFI_SUCCESS; + RootSlot = ((PCI_DEVICE_PATH *)DevPathNode)->Device; + } + } + + DevPathNode = NextDevicePathNode (DevPathNode); + } + if (EFI_ERROR (Status)) { + return Status; + } + if (RootBusNumber == 0 && RootSlot == 0) { + DEBUG(( + DEBUG_ERROR, + "%a: PCI host bridge (00:00.0) should have no interrupts!\n", + __FUNCTION__ + )); + ASSERT (FALSE); + } + + // + // Final PciHostIrqs[] index calculation depends on the platform + // and should match SeaBIOS src/fw/pciinit.c *_pci_slot_get_irq() + // + switch (mHostBridgeDevId) { + case INTEL_82441_DEVICE_ID: + Idx -= 1; + break; + case INTEL_Q35_MCH_DEVICE_ID: + // + // SeaBIOS contains the following comment: + // "Slots 0-24 rotate slot:pin mapping similar to piix above, but + // with a different starting index - see q35-acpi-dsdt.dsl. + // + // Slots 25-31 all use LNKA mapping (or LNKE, but A:D = E:H)" + // + if (RootSlot > 24) { + // + // in this case, subtract back out RootSlot from Idx + // (SeaBIOS never adds it to begin with, but that would make our + // device path traversal loop above too awkward) + // + Idx -= RootSlot; + } + break; + default: + ASSERT (FALSE); // should never get here + } + Idx %= ARRAY_SIZE (PciHostIrqs); + IrqLine = PciHostIrqs[Idx]; + + DEBUG_CODE_BEGIN (); + { + CHAR16 *DevPathString; + STATIC CHAR16 Fallback[] = L"<failed to convert>"; + UINTN Segment, Bus, Device, Function; + + DevPathString = ConvertDevicePathToText (DevPath, FALSE, FALSE); + if (DevPathString == NULL) { + DevPathString = Fallback; + } + Status = PciIo->GetLocation (PciIo, &Segment, &Bus, &Device, &Function); + ASSERT_EFI_ERROR (Status); + + DEBUG ((DEBUG_VERBOSE, "%a: [%02x:%02x.%x] %s -> 0x%02x\n", __FUNCTION__, + (UINT32)Bus, (UINT32)Device, (UINT32)Function, DevPathString, + IrqLine)); + + if (DevPathString != Fallback) { + FreePool (DevPathString); + } + } + DEBUG_CODE_END (); + + // + // Set PCI Interrupt Line register for this device to PciHostIrqs[Idx] + // + Status = PciIo->Pci.Write ( + PciIo, + EfiPciIoWidthUint8, + PCI_INT_LINE_OFFSET, + 1, + &IrqLine + ); + } + + return Status; +} + + +VOID +PciAcpiInitialization ( + ) +{ + UINTN Pmba; + + // + // Query Host Bridge DID to determine platform type + // + mHostBridgeDevId = PcdGet16 (PcdOvmfHostBridgePciDevId); + switch (mHostBridgeDevId) { + case INTEL_82441_DEVICE_ID: + Pmba = POWER_MGMT_REGISTER_PIIX4 (PIIX4_PMBA); + // + // 00:01.0 ISA Bridge (PIIX4) LNK routing targets + // + PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x60), 0x0b); // A + PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x61), 0x0b); // B + PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x62), 0x0a); // C + PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x63), 0x0a); // D + break; + case INTEL_Q35_MCH_DEVICE_ID: + Pmba = POWER_MGMT_REGISTER_Q35 (ICH9_PMBASE); + // + // 00:1f.0 LPC Bridge (Q35) LNK routing targets + // + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x60), 0x0a); // A + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x61), 0x0a); // B + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x62), 0x0b); // C + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x63), 0x0b); // D + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x68), 0x0a); // E + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x69), 0x0a); // F + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // G + PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H + break; + default: + if (XenDetected ()) { + // + // There is no PCI bus in this case. + // + return; + } + DEBUG ((DEBUG_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n", + __FUNCTION__, mHostBridgeDevId)); + ASSERT (FALSE); + return; + } + + // + // Initialize PCI_INTERRUPT_LINE for applicable present PCI devices + // + VisitAllPciInstances (SetPciIntLine); + + // + // Set ACPI SCI_EN bit in PMCNTRL + // + IoOr16 ((PciRead32 (Pmba) & ~BIT0) + 4, BIT0); +} + +EFI_STATUS +EFIAPI +ConnectRecursivelyIfPciMassStorage ( + IN EFI_HANDLE Handle, + IN EFI_PCI_IO_PROTOCOL *Instance, + IN PCI_TYPE00 *PciHeader + ) +{ + EFI_STATUS Status; + EFI_DEVICE_PATH_PROTOCOL *DevicePath; + CHAR16 *DevPathStr; + + // + // Recognize PCI Mass Storage, and Xen PCI devices + // + if (IS_CLASS1 (PciHeader, PCI_CLASS_MASS_STORAGE) || + (XenDetected() && IS_CLASS2 (PciHeader, 0xFF, 0x80))) { + DevicePath = NULL; + Status = gBS->HandleProtocol ( + Handle, + &gEfiDevicePathProtocolGuid, + (VOID*)&DevicePath + ); + if (EFI_ERROR (Status)) { + return Status; + } + + // + // Print Device Path + // + DevPathStr = ConvertDevicePathToText (DevicePath, FALSE, FALSE); + if (DevPathStr != NULL) { + DEBUG(( + DEBUG_INFO, + "Found %s device: %s\n", + (IS_CLASS1 (PciHeader, PCI_CLASS_MASS_STORAGE) ? + L"Mass Storage" : + L"Xen" + ), + DevPathStr + )); + FreePool(DevPathStr); + } + + Status = gBS->ConnectController (Handle, NULL, NULL, TRUE); + if (EFI_ERROR (Status)) { + return Status; + } + + } + + return EFI_SUCCESS; +} + + +/** + Connect with predefined platform connect sequence. + + The OEM/IBV can customize with their own connect sequence. +**/ +VOID +PlatformBdsConnectSequence ( + VOID + ) +{ + UINTN Index; + RETURN_STATUS Status; + + DEBUG ((DEBUG_INFO, "PlatformBdsConnectSequence\n")); + + Index = 0; + + // + // Here we can get the customized platform connect sequence + // Notes: we can connect with new variable which record the + // last time boots connect device path sequence + // + while (gPlatformConnectSequence[Index] != NULL) { + // + // Build the platform boot option + // + EfiBootManagerConnectDevicePath (gPlatformConnectSequence[Index], NULL); + Index++; + } + + Status = ConnectDevicesFromQemu (); + if (RETURN_ERROR (Status)) { + // + // Just use the simple policy to connect all devices + // + DEBUG ((DEBUG_INFO, "EfiBootManagerConnectAll\n")); + EfiBootManagerConnectAll (); + } +} + +/** + Save the S3 boot script. + + Note that DxeSmmReadyToLock must be signaled after this function returns; + otherwise the script wouldn't be saved actually. +**/ +STATIC +VOID +SaveS3BootScript ( + VOID + ) +{ + EFI_STATUS Status; + EFI_S3_SAVE_STATE_PROTOCOL *BootScript; + STATIC CONST UINT8 Info[] = { 0xDE, 0xAD, 0xBE, 0xEF }; + + Status = gBS->LocateProtocol (&gEfiS3SaveStateProtocolGuid, NULL, + (VOID **) &BootScript); + ASSERT_EFI_ERROR (Status); + + // + // Despite the opcode documentation in the PI spec, the protocol + // implementation embeds a deep copy of the info in the boot script, rather + // than storing just a pointer to runtime or NVS storage. + // + Status = BootScript->Write(BootScript, EFI_BOOT_SCRIPT_INFORMATION_OPCODE, + (UINT32) sizeof Info, + (EFI_PHYSICAL_ADDRESS)(UINTN) &Info); + ASSERT_EFI_ERROR (Status); +} + + +/** + Do the platform specific action after the console is ready + + Possible things that can be done in PlatformBootManagerAfterConsole: + + > Console post action: + > Dynamically switch output mode from 100x31 to 80x25 for certain senarino + > Signal console ready platform customized event + > Run diagnostics like memory testing + > Connect certain devices + > Dispatch aditional option roms + > Special boot: e.g.: USB boot, enter UI +**/ +VOID +EFIAPI +PlatformBootManagerAfterConsole ( + VOID + ) +{ + EFI_BOOT_MODE BootMode; + + DEBUG ((DEBUG_INFO, "PlatformBootManagerAfterConsole\n")); + + // + // Get current Boot Mode + // + BootMode = GetBootModeHob (); + DEBUG ((DEBUG_INFO, "Boot Mode:%x\n", BootMode)); + + // + // Go the different platform policy with different boot mode + // Notes: this part code can be change with the table policy + // + ASSERT (BootMode == BOOT_WITH_FULL_CONFIGURATION); + + // + // Logo show + // + BootLogoEnableLogo (); + + // + // Set PCI Interrupt Line registers and ACPI SCI_EN + // + PciAcpiInitialization (); + + // + // Process TPM PPI request + // + Tcg2PhysicalPresenceLibProcessRequest (NULL); + + // + // Perform some platform specific connect sequence + // + PlatformBdsConnectSequence (); + + EfiBootManagerRefreshAllBootOption (); + + // + // Register UEFI Shell (Will be removed if the Shell isn't built + // which is the default) + // + PlatformRegisterFvBootOption ( + &gUefiShellFileGuid, L"EFI Internal Shell", LOAD_OPTION_ACTIVE + ); + + // + // Register Grub + // + PlatformRegisterFvBootOption ( + &gGrubFileGuid, L"Grub Bootloader", LOAD_OPTION_ACTIVE + ); + + RemoveStaleFvFileOptions (); + + PlatformBmPrintScRegisterHandler (); +} + +/** + This notification function is invoked when an instance of the + EFI_DEVICE_PATH_PROTOCOL is produced. + + @param Event The event that occurred + @param Context For EFI compatibility. Not used. + +**/ +VOID +EFIAPI +NotifyDevPath ( + IN EFI_EVENT Event, + IN VOID *Context + ) +{ + EFI_HANDLE Handle; + EFI_STATUS Status; + UINTN BufferSize; + EFI_DEVICE_PATH_PROTOCOL *DevPathNode; + ATAPI_DEVICE_PATH *Atapi; + + // + // Examine all new handles + // + for (;;) { + // + // Get the next handle + // + BufferSize = sizeof (Handle); + Status = gBS->LocateHandle ( + ByRegisterNotify, + NULL, + mEfiDevPathNotifyReg, + &BufferSize, + &Handle + ); + + // + // If not found, we're done + // + if (EFI_NOT_FOUND == Status) { + break; + } + + if (EFI_ERROR (Status)) { + continue; + } + + // + // Get the DevicePath protocol on that handle + // + Status = gBS->HandleProtocol (Handle, &gEfiDevicePathProtocolGuid, + (VOID **)&DevPathNode); + ASSERT_EFI_ERROR (Status); + + while (!IsDevicePathEnd (DevPathNode)) { + // + // Find the handler to dump this device path node + // + if ( + (DevicePathType(DevPathNode) == MESSAGING_DEVICE_PATH) && + (DevicePathSubType(DevPathNode) == MSG_ATAPI_DP) + ) { + Atapi = (ATAPI_DEVICE_PATH*) DevPathNode; + PciOr16 ( + PCI_LIB_ADDRESS ( + 0, + 1, + 1, + (Atapi->PrimarySecondary == 1) ? 0x42: 0x40 + ), + BIT15 + ); + } + + // + // Next device path node + // + DevPathNode = NextDevicePathNode (DevPathNode); + } + } + + return; +} + + +VOID +InstallDevicePathCallback ( + VOID + ) +{ + DEBUG ((DEBUG_INFO, "Registered NotifyDevPath Event\n")); + mEfiDevPathEvent = EfiCreateProtocolNotifyEvent ( + &gEfiDevicePathProtocolGuid, + TPL_CALLBACK, + NotifyDevPath, + NULL, + &mEfiDevPathNotifyReg + ); +} + +/** + This function is called each second during the boot manager waits the + timeout. + + @param TimeoutRemain The remaining timeout. +**/ +VOID +EFIAPI +PlatformBootManagerWaitCallback ( + UINT16 TimeoutRemain + ) +{ + // + // Since the timeout should be forced to zero we should never + // Get here + // + ASSERT (FALSE); +} + +/** + The function is called when no boot option could be launched, + including platform recovery options and options pointing to applications + built into firmware volumes. + + If this function returns, BDS attempts to enter an infinite loop. +**/ +VOID +EFIAPI +PlatformBootManagerUnableToBoot ( + VOID + ) +{ + // + // If we get here something failed about the grub boot but since + // We're privy to the secret we must panic and not retry or loop + // + ASSERT (FALSE); +} diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c new file mode 100644 index 0000000000..2858c3dfd5 --- /dev/null +++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c @@ -0,0 +1,213 @@ +/** @file + Defined the platform specific device path which will be used by + platform Bbd to perform the platform policy connect. + + Copyright (c) 2004 - 2017, Intel Corporation. All rights reserved.<BR> + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#include "BdsPlatform.h" +#include <Guid/QemuRamfb.h> +#include <Guid/SerialPortLibVendor.h> + +// +// Vendor UART Device Path structure +// +#pragma pack (1) +typedef struct { + VENDOR_DEVICE_PATH VendorHardware; + UART_DEVICE_PATH Uart; + VENDOR_DEVICE_PATH TerminalType; + EFI_DEVICE_PATH_PROTOCOL End; +} VENDOR_UART_DEVICE_PATH; +#pragma pack () + +// +// USB Keyboard Device Path structure +// +#pragma pack (1) +typedef struct { + USB_CLASS_DEVICE_PATH Keyboard; + EFI_DEVICE_PATH_PROTOCOL End; +} USB_KEYBOARD_DEVICE_PATH; +#pragma pack () + +// +// QemuRamfb Device Path structure +// +#pragma pack (1) +typedef struct { + VENDOR_DEVICE_PATH Vendor; + ACPI_ADR_DEVICE_PATH AcpiAdr; + EFI_DEVICE_PATH_PROTOCOL End; +} VENDOR_RAMFB_DEVICE_PATH; +#pragma pack () + +ACPI_HID_DEVICE_PATH gPnpPs2KeyboardDeviceNode = gPnpPs2Keyboard; +ACPI_HID_DEVICE_PATH gPnp16550ComPortDeviceNode = gPnp16550ComPort; +UART_DEVICE_PATH gUartDeviceNode = gUart; +VENDOR_DEVICE_PATH gTerminalTypeDeviceNode = gPcAnsiTerminal; + +// +// Platform specific keyboard device path +// + + +// +// Debug Agent UART Device Path +// +VENDOR_UART_DEVICE_PATH gDebugAgentUartDevicePath = { + { + { + HARDWARE_DEVICE_PATH, + HW_VENDOR_DP, + { + (UINT8) (sizeof (VENDOR_DEVICE_PATH)), + (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8) + } + }, + EFI_DEBUG_AGENT_GUID, + }, + { + { + MESSAGING_DEVICE_PATH, + MSG_UART_DP, + { + (UINT8) (sizeof (UART_DEVICE_PATH)), + (UINT8) ((sizeof (UART_DEVICE_PATH)) >> 8) + } + }, + 0, // Reserved + 0, // BaudRate - Default + 0, // DataBits - Default + 0, // Parity - Default + 0, // StopBits - Default + }, + gPcAnsiTerminal, + gEndEntire +}; + +STATIC USB_KEYBOARD_DEVICE_PATH gUsbKeyboardDevicePath = { + { + { + MESSAGING_DEVICE_PATH, + MSG_USB_CLASS_DP, + { + (UINT8)sizeof (USB_CLASS_DEVICE_PATH), + (UINT8)(sizeof (USB_CLASS_DEVICE_PATH) >> 8) + } + }, + 0xFFFF, // VendorId: any + 0xFFFF, // ProductId: any + 3, // DeviceClass: HID + 1, // DeviceSubClass: boot + 1 // DeviceProtocol: keyboard + }, + gEndEntire +}; + +STATIC VENDOR_RAMFB_DEVICE_PATH gQemuRamfbDevicePath = { + { + { + HARDWARE_DEVICE_PATH, + HW_VENDOR_DP, + { + (UINT8) (sizeof (VENDOR_DEVICE_PATH)), + (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8) + } + }, + QEMU_RAMFB_GUID, + }, + { + { + ACPI_DEVICE_PATH, + ACPI_ADR_DP, + { + (UINT8) (sizeof (ACPI_ADR_DEVICE_PATH)), + (UINT8) ((sizeof (ACPI_ADR_DEVICE_PATH)) >> 8) + } + }, + ACPI_DISPLAY_ADR ( + 1, // DeviceIdScheme + 0, // HeadId + 0, // NonVgaOutput + 1, // BiosCanDetect + 0, // VendorInfo + ACPI_ADR_DISPLAY_TYPE_EXTERNAL_DIGITAL, // Type + 0, // Port + 0 // Index + ), + }, + gEndEntire +}; + +STATIC VENDOR_UART_DEVICE_PATH gXenConsoleDevicePath = { + { + { + HARDWARE_DEVICE_PATH, + HW_VENDOR_DP, + { + (UINT8) (sizeof (VENDOR_DEVICE_PATH)), + (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8) + } + }, + EDKII_SERIAL_PORT_LIB_VENDOR_GUID + }, + { + { + MESSAGING_DEVICE_PATH, + MSG_UART_DP, + { + (UINT8) (sizeof (UART_DEVICE_PATH)), + (UINT8) ((sizeof (UART_DEVICE_PATH)) >> 8) + } + }, + 0, + FixedPcdGet64 (PcdUartDefaultBaudRate), + FixedPcdGet8 (PcdUartDefaultDataBits), + FixedPcdGet8 (PcdUartDefaultParity), + FixedPcdGet8 (PcdUartDefaultStopBits), + }, + gPcAnsiTerminal, + gEndEntire +}; + +// +// Predefined platform default console device path +// +PLATFORM_CONSOLE_CONNECT_ENTRY gPlatformConsole[] = { + { + (EFI_DEVICE_PATH_PROTOCOL *) &gDebugAgentUartDevicePath, + (CONSOLE_OUT | CONSOLE_IN | STD_ERROR) + }, + { + (EFI_DEVICE_PATH_PROTOCOL *)&gUsbKeyboardDevicePath, + CONSOLE_IN + }, + { + (EFI_DEVICE_PATH_PROTOCOL *)&gQemuRamfbDevicePath, + CONSOLE_OUT + }, + { + NULL, + 0 + } +}; + +PLATFORM_CONSOLE_CONNECT_ENTRY gXenPlatformConsole[] = { + { + (EFI_DEVICE_PATH_PROTOCOL *)&gXenConsoleDevicePath, + (CONSOLE_OUT | CONSOLE_IN | STD_ERROR) + }, + { + NULL, + 0 + } +}; + +// +// Predefined platform connect sequence +// +EFI_DEVICE_PATH_PROTOCOL *gPlatformConnectSequence[] = { NULL }; + diff --git a/OvmfPkg/AmdSev/Grub/.gitignore b/OvmfPkg/AmdSev/Grub/.gitignore new file mode 100644 index 0000000000..7e3b30951f --- /dev/null +++ b/OvmfPkg/AmdSev/Grub/.gitignore @@ -0,0 +1 @@ +grub.efi diff --git a/OvmfPkg/AmdSev/Grub/grub.cfg b/OvmfPkg/AmdSev/Grub/grub.cfg new file mode 100644 index 0000000000..5c8fd1e547 --- /dev/null +++ b/OvmfPkg/AmdSev/Grub/grub.cfg @@ -0,0 +1,35 @@ +echo "Entering grub config" +sevsecret +if [ $? -ne 0 ]; then + echo "Failed to locate anything in the SEV secret area, prompting for password" + cryptomount -a +else + cryptomount -s + if [ $? -ne 0 ]; then + echo "Failed to mount root securely, retrying with password prompt" + cryptomount -a + fi +fi +set root= +for f in (crypto*); do + if [ -e $f/boot/grub/grub.cfg ]; then + set root=$f + set prefix=($root)/boot/grub + break; + fi +done +if [ x$root = x ]; then + echo "Failed to find any grub configuration on the encrypted volume" + sleep 5 + reboot +fi +# rest of modules to get boot to work +set modules=" + boot + loadenv + " +for f in $modules; do + insmod $f +done +echo "Transferring to ${prefix}/grub.cfg" +source $prefix/grub.cfg diff --git a/OvmfPkg/AmdSev/Grub/grub.sh b/OvmfPkg/AmdSev/Grub/grub.sh new file mode 100644 index 0000000000..91fac11ac9 --- /dev/null +++ b/OvmfPkg/AmdSev/Grub/grub.sh @@ -0,0 +1,54 @@ +GRUB_MODULES=" + part_msdos + part_gpt + cryptodisk + luks + gcry_rijndael + gcry_sha256 + ext2 + btrfs + xfs + fat + configfile + memdisk + sleep + normal + echo + test + regexp + linux + linuxefi + reboot + sevsecret + " +basedir=`dirname $0` +## +# different distributions have different names for grub-mkimage, so +# search all the known ones +## +for b in grub2-mkimage grub-mkimage; do + if which $b > /dev/null 2>&1; then + mkimage=$b + fi +done +if [ -z "$mkimage" ]; then + echo "Can't find grub mkimage" + exit 1 +fi + +# GRUB's rescue parser doesn't understand 'if'. +echo 'normal (memdisk)/grub.cfg' >"${basedir}/grub-bootstrap.cfg" + +# Now build a memdisk with the correct grub.cfg +rm -f ${basedir}/disk.fat +mkfs.msdos -C ${basedir}/disk.fat 64 || exit 1 +mcopy -i ${basedir}/disk.fat ${basedir}/grub.cfg ::grub.cfg || exit 1 + + +${mkimage} -O x86_64-efi -p '(crypto0)' -c ${basedir}/grub-bootstrap.cfg -m ${basedir}/disk.fat -o ${basedir}/grub.efi ${GRUB_MODULES} || exit 1 + +# remove the intermediates +for f in disk.fat grub-bootstrap.cfg; do + rm -f ${basedir}/$f +done +echo "grub.efi generated in ${basedir}" -- 2.26.2 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 2/4] OvmfPkg/AmdSev: add Grub Firmware Volume Package 2020-11-12 0:13 ` [PATCH 2/4] OvmfPkg/AmdSev: add Grub Firmware Volume Package James Bottomley @ 2020-11-16 20:42 ` Laszlo Ersek 2020-11-17 0:05 ` Laszlo Ersek 2020-11-18 23:00 ` James Bottomley 0 siblings, 2 replies; 35+ messages in thread From: Laszlo Ersek @ 2020-11-16 20:42 UTC (permalink / raw) To: devel, jejb Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/12/20 01:13, James Bottomley wrote: > 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 preven secret theft. > > Signed-off-by: James Bottomley <jejb@linux.ibm.com> > --- > OvmfPkg/OvmfPkg.dec | 1 + > OvmfPkg/AmdSev/AmdSevX64.dsc | 14 +- > OvmfPkg/AmdSev/AmdSevX64.fdf | 5 +- > OvmfPkg/AmdSev/Grub/Grub.inf | 37 + > .../PlatformBootManagerLibGrub.inf | 84 + > .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++ > .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++ > .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++ > OvmfPkg/AmdSev/Grub/.gitignore | 1 + > OvmfPkg/AmdSev/Grub/grub.cfg | 35 + > OvmfPkg/AmdSev/Grub/grub.sh | 54 + > 11 files changed, 2157 insertions(+), 4 deletions(-) > create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c > create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore > create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg > create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh > diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc > index d1dfb8742f..7d3663150e 100644 > --- a/OvmfPkg/AmdSev/AmdSevX64.dsc > +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc > @@ -23,6 +23,7 @@ > BUILD_TARGETS = NOOPT|DEBUG|RELEASE > SKUID_IDENTIFIER = DEFAULT > FLASH_DEFINITION = OvmfPkg/AmdSev/AmdSevX64.fdf > + PREBUILD = sh OvmfPkg/AmdSev/Grub/grub.sh > > # > # Defines for default states. These can be changed on the command line. > @@ -33,6 +34,7 @@ > DEFINE SOURCE_DEBUG_ENABLE = FALSE > DEFINE TPM_ENABLE = FALSE > DEFINE TPM_CONFIG_ENABLE = FALSE > + DEFINE BUILD_SHELL = FALSE (1) Please add a comment that this is strictly for debugging (not production). > diff --git a/OvmfPkg/AmdSev/Grub/Grub.inf b/OvmfPkg/AmdSev/Grub/Grub.inf > new file mode 100644 > index 0000000000..a12428668b > --- /dev/null > +++ b/OvmfPkg/AmdSev/Grub/Grub.inf > @@ -0,0 +1,37 @@ > +## @file > +# Create a Firmware Volume based Grub Bootloaded > +# > +# Copyright (C) 2020 James Bottomley, IBM Corporation. > +# > +# SPDX-License-Identifier: BSD-2-Clause-Patent > +# > +## > + > +[Defines] > + INF_VERSION = 0x00010006 > + BASE_NAME = Grub > + # This is gGrubFileGuid > + FILE_GUID = b5ae312c-bc8a-43b1-9c62-ebb826dd5d07 > + MODULE_TYPE = UEFI_APPLICATION > + VERSION_STRING = 1.0 > + ENTRY_POINT = UefiMain > + > +[Packages] > + OvmfPkg/OvmfPkg.dec > + > +# > +# The following information is for reference only and not required by > +# the build tools. > +# > +# VALID_ARCHITECTURES = IA32 X64 EBC (2) We can likely restrict this comment to X64 only. > +# > + > +## > +# Note: The version of grub.efi this picks up can be generated by > +# grub.sh which must be specified as a PREBUILD in the .dsc file or > +# you can simply move a precompiled grub into here and not do the > +# PREBUILD) (3) Can you elaborate how to skip PREBUILD? > diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf > new file mode 100644 > index 0000000000..62707b0bdd > --- /dev/null > +++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf > @@ -0,0 +1,84 @@ > +## @file > +# Platform BDS customizations library. > +# > +# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.<BR> > +# SPDX-License-Identifier: BSD-2-Clause-Patent > +# > +## > + > +[Defines] > + INF_VERSION = 0x00010005 > + BASE_NAME = PlatformBootManagerLibGrub > + FILE_GUID = 3a8f8431-f0c9-4c95-8a1d-04445c582d4e > + MODULE_TYPE = DXE_DRIVER > + VERSION_STRING = 1.0 > + LIBRARY_CLASS = PlatformBootManagerLib|DXE_DRIVER > + > +# > +# The following information is for reference only and not required by the build tools. > +# > +# VALID_ARCHITECTURES = IA32 X64 EBC > +# > + > +[Sources] > + BdsPlatform.c > + PlatformData.c > + BdsPlatform.h > + > +[Packages] > + MdePkg/MdePkg.dec > + MdeModulePkg/MdeModulePkg.dec > + SourceLevelDebugPkg/SourceLevelDebugPkg.dec > + OvmfPkg/OvmfPkg.dec > + SecurityPkg/SecurityPkg.dec > + ShellPkg/ShellPkg.dec > + > +[LibraryClasses] > + BaseLib > + MemoryAllocationLib > + UefiBootServicesTableLib > + UefiRuntimeServicesTableLib > + BaseMemoryLib > + DebugLib > + PcdLib > + UefiBootManagerLib > + BootLogoLib > + DevicePathLib > + PciLib > + QemuFwCfgLib > + QemuFwCfgS3Lib > + QemuLoadImageLib > + QemuBootOrderLib > + ReportStatusCodeLib > + UefiLib > + PlatformBmPrintScLib > + Tcg2PhysicalPresenceLib > + XenPlatformLib (4) I recommend removing the following lib classes: - QemuFwCfgLib - QemuFwCfgS3Lib - QemuLoadImageLib - QemuBootOrderLib - XenPlatformLib The parallel #include <Library/...> directives should be removed from the "OvmfPkg/Library/PlatformBootManagerLibGrub/" source code. This will cause a bunch of compilation errors. The code should then be simplified by either just removing function calls, or assuming suitable constant return values from those function calls. > + > +[Pcd] > + gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent (5) This PCD not needed. In general, please remove *everything* from this INF file that is not strictly necessary for the desired semantics. While I *am* a neat freak, eliminating dependencies on hypervisor information channels at this granularity helps reasoning about security, in this particular case (in my opinion). If there is build breakage that's not obvious to fix, I'm happy to advise to the best of my knowledge. > diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c > new file mode 100644 > index 0000000000..24c37068a2 > --- /dev/null > +++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c > +/** > + Remove all MemoryMapped(...)/FvFile(...) and Fv(...)/FvFile(...) boot options > + whose device paths do not resolve exactly to an FvFile in the system. > + > + Also strip out every boot option that is not an FvFile, meaning the system > + can only boot either the Grub or (if built) the shell. > + > + This removes any boot options that point to binaries built into the firmware > + and have become stale due to any of the following: > + - DXEFV's base address or size changed (historical), > + - DXEFV's FvNameGuid changed, > + - the FILE_GUID of the pointed-to binary changed, > + - the referenced binary is no longer built into the firmware. > + > + EfiBootManagerFindLoadOption() used in PlatformRegisterFvBootOption() only > + avoids exact duplicates. > +**/ > +VOID > +RemoveStaleFvFileOptions ( > + VOID > + ) (6) Do we need this function at all? My understanding is: - platform reboot is not supported, - the original platform boot occurs with the varstore having been verified by the remote guest owner That seems to imply that we don't need to dynamically prune the boot variables. I don't insist of course, just looking for further simplifications. If you think keeping this function (with the updates) is necessary or just prudent, I'm OK with that. ... Ah wait, I see that the shell is added and *then* removed (optionally). OK. > +/** > + The function is called when no boot option could be launched, > + including platform recovery options and options pointing to applications > + built into firmware volumes. > + > + If this function returns, BDS attempts to enter an infinite loop. > +**/ > +VOID > +EFIAPI > +PlatformBootManagerUnableToBoot ( > + VOID > + ) > +{ > + // > + // If we get here something failed about the grub boot but since > + // We're privy to the secret we must panic and not retry or loop > + // > + ASSERT (FALSE); > +} (7) I suggest adding an explicit CpuDeadLoop() here -- RELEASE builds do not include ASSERT()s. > diff --git a/OvmfPkg/AmdSev/Grub/grub.cfg b/OvmfPkg/AmdSev/Grub/grub.cfg > new file mode 100644 > index 0000000000..5c8fd1e547 > --- /dev/null > +++ b/OvmfPkg/AmdSev/Grub/grub.cfg > @@ -0,0 +1,35 @@ (8) This file lacks a (C) Notice and an SPDX-License-Identifier. > +echo "Entering grub config" > +sevsecret > +if [ $? -ne 0 ]; then > + echo "Failed to locate anything in the SEV secret area, prompting for password" > + cryptomount -a > +else > + cryptomount -s > + if [ $? -ne 0 ]; then > + echo "Failed to mount root securely, retrying with password prompt" > + cryptomount -a > + fi > +fi > +set root= > +for f in (crypto*); do > + if [ -e $f/boot/grub/grub.cfg ]; then > + set root=$f > + set prefix=($root)/boot/grub > + break; > + fi > +done > +if [ x$root = x ]; then > + echo "Failed to find any grub configuration on the encrypted volume" > + sleep 5 > + reboot > +fi > +# rest of modules to get boot to work > +set modules=" > + boot > + loadenv > + " > +for f in $modules; do > + insmod $f > +done > +echo "Transferring to ${prefix}/grub.cfg" > +source $prefix/grub.cfg I'm not familiar with the grub config file syntax, so I'm not going to comment on the (potential) lack of quoting. > diff --git a/OvmfPkg/AmdSev/Grub/grub.sh b/OvmfPkg/AmdSev/Grub/grub.sh > new file mode 100644 > index 0000000000..91fac11ac9 > --- /dev/null > +++ b/OvmfPkg/AmdSev/Grub/grub.sh > @@ -0,0 +1,54 @@ (9) This file lacks a (C) Notice and an SPDX-License-Identifier. > +GRUB_MODULES=" > + part_msdos > + part_gpt > + cryptodisk > + luks > + gcry_rijndael > + gcry_sha256 > + ext2 > + btrfs > + xfs > + fat > + configfile > + memdisk > + sleep > + normal > + echo > + test > + regexp > + linux > + linuxefi > + reboot > + sevsecret > + " > +basedir=`dirname $0` (10) I'm going to put on my "pedant hat" for this. Given that this script runs every time (or "almost every time") the platform is built, I'd like the script to be more robust. I suggest: basedir=$(dirname -- "$0") > +## > +# different distributions have different names for grub-mkimage, so > +# search all the known ones > +## > +for b in grub2-mkimage grub-mkimage; do > + if which $b > /dev/null 2>&1; then (11) s/which/command -v/ > + mkimage=$b (12) add a break here? > + fi > +done > +if [ -z "$mkimage" ]; then > + echo "Can't find grub mkimage" (13) Please write this to stderr: >&2 (14) Please store "" (the empty string) to "mkimage" before the loop. > + exit 1 > +fi > + > +# GRUB's rescue parser doesn't understand 'if'. > +echo 'normal (memdisk)/grub.cfg' >"${basedir}/grub-bootstrap.cfg" > + > +# Now build a memdisk with the correct grub.cfg > +rm -f ${basedir}/disk.fat (15) rm -f -- "${basedir}/disk.fat" > +mkfs.msdos -C ${basedir}/disk.fat 64 || exit 1 (16) Please quote ${basedir}/disk.fat, and (if mkfs.msdos doesn't choke on it) please place a -- separator after "-C". (17) Please remove the explicit '|| exit 1' commands from the script, and instead add "set -e" at the top. (18) Please consider adding an EXIT trap. The EXIT trap should call a function. The function should remove (a) all temporaries, (b) the final output. Step (b) -- removal of the final output -- should depend on a global variable. If we are about to exit successfully, this global variable should be set accordingly, so that the subsequent EXIT handler omit step (b). If you think this is overkill, that's OK; I don't insist. > +mcopy -i ${basedir}/disk.fat ${basedir}/grub.cfg ::grub.cfg || exit 1 (19) Please improve quoting, operand-from-option separation, and exit-on-error (see above). > + > + > +${mkimage} -O x86_64-efi -p '(crypto0)' -c ${basedir}/grub-bootstrap.cfg -m ${basedir}/disk.fat -o ${basedir}/grub.efi ${GRUB_MODULES} || exit 1 > + (20) Same as (19). (21) Please keep the line length under 80 characters; something like: ${mkimage} -O x86_64-efi \ -p '(crypto0)' \ -c ${basedir}/grub-bootstrap.cfg \ ... > +# remove the intermediates > +for f in disk.fat grub-bootstrap.cfg; do > + rm -f ${basedir}/$f > +done > +echo "grub.efi generated in ${basedir}" > (22) I'd prefer improving this as described in (18). --*-- The general idea of my review is that I'll let you do what you need to do security-wise -- at best I can suggest high-level ideas regarding that, such as point (5) --, whereas on the build front and the look-and-feel front, I'd like this to be reasonably polished and consistent with the edk2 style. (So if my review feels superficial, it's not random.) ... Which reminds me: please check if the patch series passes the "ECC" (Edk2 C Checker) part of the edk2 build CI. For that, please just push your topic branch that you're about to post to the list to your personal github repo, and submit a pull request against the main edk2 repo (master branch). Your merge request will be auto-rejected in the end (actual merging is only available to maintainers), but if there's a problem with CI, you'll learn about it. Now, "ECC" is by no means bug-free, so in some cases workarounds (or even error suppressions) are necessary. Either way, we'll have to be ECC-clean in the end, so it's best if you check that as well (I'd run into the same problems with the real merge anyway). CI can be run locally too, but setting it up is not trivial. If you prefer not submitting ad-hoc PRs just for kicking of CI, then please see this thread: [edk2-devel] running CI locally https://edk2.groups.io/g/devel/message/64428 https://www.redhat.com/archives/edk2-devel-archive/2020-August/msg00823.html Thanks! Laszlo ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 2/4] OvmfPkg/AmdSev: add Grub Firmware Volume Package 2020-11-16 20:42 ` [edk2-devel] " Laszlo Ersek @ 2020-11-17 0:05 ` Laszlo Ersek 2020-11-18 23:00 ` James Bottomley 1 sibling, 0 replies; 35+ messages in thread From: Laszlo Ersek @ 2020-11-17 0:05 UTC (permalink / raw) To: devel, jejb Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/16/20 21:42, Laszlo Ersek wrote: > On 11/12/20 01:13, James Bottomley wrote: >> diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf >> new file mode 100644 >> index 0000000000..62707b0bdd >> --- /dev/null >> +++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf >> @@ -0,0 +1,84 @@ >> +## @file >> +# Platform BDS customizations library. >> +# >> +# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.<BR> >> +# SPDX-License-Identifier: BSD-2-Clause-Patent >> +# >> +## >> + >> +[Defines] >> + INF_VERSION = 0x00010005 >> + BASE_NAME = PlatformBootManagerLibGrub >> + FILE_GUID = 3a8f8431-f0c9-4c95-8a1d-04445c582d4e >> + MODULE_TYPE = DXE_DRIVER >> + VERSION_STRING = 1.0 >> + LIBRARY_CLASS = PlatformBootManagerLib|DXE_DRIVER >> + >> +# >> +# The following information is for reference only and not required by the build tools. >> +# >> +# VALID_ARCHITECTURES = IA32 X64 EBC >> +# (23) This too should be X64 only. Thanks Laszlo ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 2/4] OvmfPkg/AmdSev: add Grub Firmware Volume Package 2020-11-16 20:42 ` [edk2-devel] " Laszlo Ersek 2020-11-17 0:05 ` Laszlo Ersek @ 2020-11-18 23:00 ` James Bottomley 2020-11-19 7:59 ` Laszlo Ersek 1 sibling, 1 reply; 35+ messages in thread From: James Bottomley @ 2020-11-18 23:00 UTC (permalink / raw) To: Laszlo Ersek, devel Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On Mon, 2020-11-16 at 21:42 +0100, Laszlo Ersek wrote: > On 11/12/20 01:13, James Bottomley wrote: [...] > > +## > > +# different distributions have different names for grub-mkimage, > > so > > +# search all the known ones > > +## > > +for b in grub2-mkimage grub-mkimage; do > > + if which $b > /dev/null 2>&1; then I did everything except this: > (11) s/which/command -v/ The problem with command -v is that it picks up aliases, which we definitely don't want (in the incredibly unlikely case that grub- mkimage has an alias). You can see the effects with ls which I've got aliased: jejb@jarvis:~> command -v ls alias ls='ls -F' jejb@jarvis:~> which ls /bin/ls We definitely want the latter behaviour in the script above ... I need the absolute path to the command, so I kept the which. James ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 2/4] OvmfPkg/AmdSev: add Grub Firmware Volume Package 2020-11-18 23:00 ` James Bottomley @ 2020-11-19 7:59 ` Laszlo Ersek 0 siblings, 0 replies; 35+ messages in thread From: Laszlo Ersek @ 2020-11-19 7:59 UTC (permalink / raw) To: jejb, devel Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/19/20 00:00, James Bottomley wrote: > On Mon, 2020-11-16 at 21:42 +0100, Laszlo Ersek wrote: >> On 11/12/20 01:13, James Bottomley wrote: > [...] >>> +## >>> +# different distributions have different names for grub-mkimage, >>> so >>> +# search all the known ones >>> +## >>> +for b in grub2-mkimage grub-mkimage; do >>> + if which $b > /dev/null 2>&1; then > > I did everything except this: > >> (11) s/which/command -v/ > > The problem with command -v is that it picks up aliases, which we > definitely don't want (in the incredibly unlikely case that grub- > mkimage has an alias). You can see the effects with ls which I've got > aliased: > > jejb@jarvis:~> command -v ls > alias ls='ls -F' > jejb@jarvis:~> which ls > /bin/ls > > We definitely want the latter behaviour in the script above ... I need > the absolute path to the command, so I kept the which. Right -- we could forcibly unalias each $b before running "command -v" (or even invoke '\unalias -a' near the top of the script): https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html#tag_20_22_17 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/unalias.html but I don't insist! :) If we seriously get into how self-defeating a user's shell environment can possibly be, we'll never get to the bottom of that. Thanks! Laszlo ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd 2020-11-12 0:13 [PATCH 0/4] SEV Encrypted Boot for Ovmf James Bottomley 2020-11-12 0:13 ` [PATCH 1/4] OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF James Bottomley 2020-11-12 0:13 ` [PATCH 2/4] OvmfPkg/AmdSev: add Grub Firmware Volume Package James Bottomley @ 2020-11-12 0:13 ` James Bottomley 2020-11-16 22:46 ` [edk2-devel] " Laszlo Ersek 2020-11-12 0:13 ` [PATCH 4/4] OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table James Bottomley ` (5 subsequent siblings) 8 siblings, 1 reply; 35+ messages in thread From: James Bottomley @ 2020-11-12 0:13 UTC (permalink / raw) To: devel Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, jejb, frankeh, Dr . David Alan Gilbert SEV needs an area to place an injected secret where OVMF can find it and pass it up as a ConfigurationTable. This patch implements the area itself as an addition to the SEV enhanced reset vector. The reset vector scheme allows additions but not removals. If the size of the reset vector is 22, it only contains the AP reset IP, but if it is 30 (or greater) it contains the SEV secret page location and size. Signed-off-by: James Bottomley <jejb@linux.ibm.com> --- OvmfPkg/OvmfPkg.dec | 5 +++++ OvmfPkg/AmdSev/AmdSevX64.fdf | 3 +++ OvmfPkg/ResetVector/ResetVector.inf | 4 ++++ OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 ++++ OvmfPkg/ResetVector/ResetVector.nasmb | 2 ++ 5 files changed, 18 insertions(+) diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec index 3fbf7a0ee1..b00f083417 100644 --- a/OvmfPkg/OvmfPkg.dec +++ b/OvmfPkg/OvmfPkg.dec @@ -117,6 +117,7 @@ gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}} gQemuKernelLoaderFsMediaGuid = {0x1428f772, 0xb64a, 0x441e, {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}} gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}} + gSevLaunchSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}} [Ppis] # PPI whose presence in the PPI database signals that the TPM base address @@ -304,6 +305,10 @@ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|0|UINT32|0x40 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize|0|UINT32|0x41 + ## The base address and size of the SEV Launch Secret Area + gSevLaunchSecretGuid.PcdSevLaunchSecretBase|0x0|UINT32|0 + gSevLaunchSecretGuid.PcdSevLaunchSecretSize|0x0|UINT32|1 + [PcdsDynamic, PcdsDynamicEx] gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10 diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf index 689386612d..1fd38b3fe2 100644 --- a/OvmfPkg/AmdSev/AmdSevX64.fdf +++ b/OvmfPkg/AmdSev/AmdSevX64.fdf @@ -59,6 +59,9 @@ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmf 0x00B000|0x001000 gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize +0x00C000|0x001000 +gSevLaunchSecretGuid.PcdSevLaunchSecretBase|gSevLaunchSecretGuid.PcdSevLaunchSecretSize + 0x010000|0x010000 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/ResetVector/ResetVector.inf index a53ae6c194..72fd78eef4 100644 --- a/OvmfPkg/ResetVector/ResetVector.inf +++ b/OvmfPkg/ResetVector/ResetVector.inf @@ -43,3 +43,7 @@ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize + +[FixedPcd] + gSevLaunchSecretGuid.PcdSevLaunchSecretBase + gSevLaunchSecretGuid.PcdSevLaunchSecretSize diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm index 980e0138e7..7d3214e55d 100644 --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm @@ -35,6 +35,8 @@ ALIGN 16 ; the build time RIP value. The GUID must always be 48 bytes from the ; end of the firmware. ; +; 0xffffffc2 (-0x3e) - Base Location of the SEV Launch Secret +; 0xffffffc6 (-0x3a) - Size of SEV Launch Secret ; 0xffffffca (-0x36) - IP value ; 0xffffffcc (-0x34) - CS segment base [31:16] ; 0xffffffce (-0x32) - Size of the SEV-ES reset block @@ -51,6 +53,8 @@ ALIGN 16 TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 sevEsResetBlockStart: + DD SEV_LAUNCH_SECRET_BASE + DD SEV_LAUNCH_SECRET_SIZE DD SEV_ES_AP_RESET_IP DW sevEsResetBlockEnd - sevEsResetBlockStart DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/ResetVector.nasmb index 4913b379a9..c5e0fe93ab 100644 --- a/OvmfPkg/ResetVector/ResetVector.nasmb +++ b/OvmfPkg/ResetVector/ResetVector.nasmb @@ -83,5 +83,7 @@ %include "Main.asm" %define SEV_ES_AP_RESET_IP FixedPcdGet32 (PcdSevEsWorkAreaBase) + %define SEV_LAUNCH_SECRET_BASE FixedPcdGet32 (PcdSevLaunchSecretBase) + %define SEV_LAUNCH_SECRET_SIZE FixedPcdGet32 (PcdSevLaunchSecretSize) %include "Ia16/ResetVectorVtf0.asm" -- 2.26.2 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd 2020-11-12 0:13 ` [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd James Bottomley @ 2020-11-16 22:46 ` Laszlo Ersek 2020-11-18 20:23 ` James Bottomley 2020-11-18 20:39 ` Lendacky, Thomas 0 siblings, 2 replies; 35+ messages in thread From: Laszlo Ersek @ 2020-11-16 22:46 UTC (permalink / raw) To: devel, jejb Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/12/20 01:13, James Bottomley wrote: > SEV needs an area to place an injected secret where OVMF can find it > and pass it up as a ConfigurationTable. This patch implements the > area itself as an addition to the SEV enhanced reset vector. The > reset vector scheme allows additions but not removals. If the size of > the reset vector is 22, it only contains the AP reset IP, but if it is > 30 (or greater) it contains the SEV secret page location and size. > > Signed-off-by: James Bottomley <jejb@linux.ibm.com> > --- > OvmfPkg/OvmfPkg.dec | 5 +++++ > OvmfPkg/AmdSev/AmdSevX64.fdf | 3 +++ > OvmfPkg/ResetVector/ResetVector.inf | 4 ++++ > OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 ++++ > OvmfPkg/ResetVector/ResetVector.nasmb | 2 ++ > 5 files changed, 18 insertions(+) > > diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec > index 3fbf7a0ee1..b00f083417 100644 > --- a/OvmfPkg/OvmfPkg.dec > +++ b/OvmfPkg/OvmfPkg.dec > @@ -117,6 +117,7 @@ > gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}} > gQemuKernelLoaderFsMediaGuid = {0x1428f772, 0xb64a, 0x441e, {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}} > gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}} > + gSevLaunchSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}} > > [Ppis] > # PPI whose presence in the PPI database signals that the TPM base address > @@ -304,6 +305,10 @@ > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|0|UINT32|0x40 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize|0|UINT32|0x41 > > + ## The base address and size of the SEV Launch Secret Area (1) I request that we please include the expression "remote attestation" in the above comment, somehow. (2) Please extend the comment with a statement that, in case the platform sets either PCD to nonzero, the platform is responsible for protecting the area from DXE-phase overwrites. > + gSevLaunchSecretGuid.PcdSevLaunchSecretBase|0x0|UINT32|0 > + gSevLaunchSecretGuid.PcdSevLaunchSecretSize|0x0|UINT32|1 > + (3) Please fold these new PCD declarations into the "gUefiOvmfPkgTokenSpaceGuid" token space, and (consequently) please use token values 0x42 and 0x43. > [PcdsDynamic, PcdsDynamicEx] > gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10 > diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf > index 689386612d..1fd38b3fe2 100644 > --- a/OvmfPkg/AmdSev/AmdSevX64.fdf > +++ b/OvmfPkg/AmdSev/AmdSevX64.fdf > @@ -59,6 +59,9 @@ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmf > 0x00B000|0x001000 > gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize > > +0x00C000|0x001000 > +gSevLaunchSecretGuid.PcdSevLaunchSecretBase|gSevLaunchSecretGuid.PcdSevLaunchSecretSize > + > 0x010000|0x010000 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize > (4) This hunk looks OK, but please move it over to the next patch (4/4). I feel it allows for nicer diffstats if: - patch#3 introduces the new PCDs and extends the (kind of general) reset vector with exposing the PCD values in the flash, and - patch#4 modifies the new platform to both set the PCDs and satisfy the requirement described under (2) -- by way of including SecretPei. > diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/ResetVector/ResetVector.inf > index a53ae6c194..72fd78eef4 100644 > --- a/OvmfPkg/ResetVector/ResetVector.inf > +++ b/OvmfPkg/ResetVector/ResetVector.inf > @@ -43,3 +43,7 @@ > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize > + > +[FixedPcd] > + gSevLaunchSecretGuid.PcdSevLaunchSecretBase > + gSevLaunchSecretGuid.PcdSevLaunchSecretSize OK. > diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > index 980e0138e7..7d3214e55d 100644 > --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > @@ -35,6 +35,8 @@ ALIGN 16 > ; the build time RIP value. The GUID must always be 48 bytes from the > ; end of the firmware. > ; > +; 0xffffffc2 (-0x3e) - Base Location of the SEV Launch Secret > +; 0xffffffc6 (-0x3a) - Size of SEV Launch Secret > ; 0xffffffca (-0x36) - IP value > ; 0xffffffcc (-0x34) - CS segment base [31:16] > ; 0xffffffce (-0x32) - Size of the SEV-ES reset block > @@ -51,6 +53,8 @@ ALIGN 16 > TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 > > sevEsResetBlockStart: > + DD SEV_LAUNCH_SECRET_BASE > + DD SEV_LAUNCH_SECRET_SIZE > DD SEV_ES_AP_RESET_IP > DW sevEsResetBlockEnd - sevEsResetBlockStart > DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F (5) I'd prefer if we could introduce a new GUID-ed structure for these new fields. The logic in QEMU should be extended to start scanning at 4GB-48 for GUIDS. If the GUID is not recognized, then terminate scanning. Otherwise, act upon the GUID-ed structure found there as necessary, and then determine the next GUID *candidate* location by subtracting the last recognized GUID-ed structure's "size" field. For a bit larger context from this file, we have (pre-patch): > ; > ; SEV-ES Processor Reset support > ; > ; sevEsResetBlock: > ; For the initial boot of an AP under SEV-ES, the "reset" RIP must be > ; programmed to the RAM area defined by SEV_ES_AP_RESET_IP. A known offset > ; and GUID will be used to locate this block in the firmware and extract > ; the build time RIP value. The GUID must always be 48 bytes from the > ; end of the firmware. > ; > ; 0xffffffca (-0x36) - IP value > ; 0xffffffcc (-0x34) - CS segment base [31:16] > ; 0xffffffce (-0x32) - Size of the SEV-ES reset block > ; 0xffffffd0 (-0x30) - SEV-ES reset block GUID > ; (00f771de-1a7e-4fcb-890e-68c77e2fb44e) > ; > ; A hypervisor reads the CS segement base and IP value. The CS segment base > ; value represents the high order 16-bits of the CS segment base, so the > ; hypervisor must left shift the value of the CS segement base by 16 bits to > ; form the full CS segment base for the CS segment register. It would then > ; program the EIP register with the IP value as read. > ; > > TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 > > sevEsResetBlockStart: > DD SEV_ES_AP_RESET_IP > DW sevEsResetBlockEnd - sevEsResetBlockStart > DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F > DB 0x89, 0x0E, 0x68, 0xC7, 0x7E, 0x2F, 0xB4, 0x4E > sevEsResetBlockEnd: I'm not exactly sure why we added the padding (TIMES ... DB 0) in edk2 commit 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector", 2020-08-17). I can imagine it was *already* for the same purpose -- to deterministically terminate the above-described backwards-traversal of the GUID-ed structures (and at the same time remain aligned to 32 bytes, regarding the cumulative size of all provided structures). So, in that vein, I'd propose something like this (relative to master @ d448574e7310): > diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > index 980e0138e7fe..957356ff997e 100644 > --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > @@ -16,55 +16,83 @@ ALIGN 16 > ; Pad the image size to 4k when page tables are in VTF0 > ; > ; If the VTF0 image has page tables built in, then we need to make > ; sure the end of VTF0 is 4k above where the page tables end. > ; > ; This is required so the page tables will be 4k aligned when VTF0 is > ; located just below 0x100000000 (4GB) in the firmware device. > ; > %ifdef ALIGN_TOP_TO_4K_FOR_PAGING > TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0 > %endif > > +; > +; pre-pad the sequence of GUIDed structures to a multiple of 32 bytes > +; > +TIMES (31 - (guidedStructuresEnd - guidedStructuresStart + 31) % 32) DB 0 > + > +guidedStructuresStart: > +; > +; Zero GUID to terminate decreasing address order traversal. > +; > +TIMES 16 DB 0 > + > +; > +; Expose the location of the SEV Launch Secret area to the hypervisor > +; (necessary when using the remote attestation firmware platform). > +; > +; sevLaunchSecretDescriptor: > +; This GUIDed structure is chained in decreasing address order from > +; sevEsResetBlock. It describes the guest RAM area where the hypervisor has > +; to securely inject the SEV Launch Secret. The GUID is > +; 78C93F1E-ADBC-4259-B92B-CE81E523FBC4. > +; > +sevLaunchSecretDescriptorStart: > + DD SEV_LAUNCH_SECRET_BASE > + DD SEV_LAUNCH_SECRET_SIZE > + DW sevLaunchSecretDescriptorEnd - sevLaunchSecretDescriptorStart > + DB 0x1E, 0x3F, 0xC9, 0x78, 0xBC, 0xAD, 0x59, 0x42 > + DB 0xB9, 0x2B, 0xCE, 0x81, 0xE5, 0x23, 0xFB, 0xC4 > +sevLaunchSecretDescriptorEnd: > + > ; > ; SEV-ES Processor Reset support > ; > ; sevEsResetBlock: > ; For the initial boot of an AP under SEV-ES, the "reset" RIP must be > ; programmed to the RAM area defined by SEV_ES_AP_RESET_IP. A known offset > ; and GUID will be used to locate this block in the firmware and extract > ; the build time RIP value. The GUID must always be 48 bytes from the > ; end of the firmware. > ; > ; 0xffffffca (-0x36) - IP value > ; 0xffffffcc (-0x34) - CS segment base [31:16] > ; 0xffffffce (-0x32) - Size of the SEV-ES reset block > ; 0xffffffd0 (-0x30) - SEV-ES reset block GUID > ; (00f771de-1a7e-4fcb-890e-68c77e2fb44e) > ; > ; A hypervisor reads the CS segement base and IP value. The CS segment base > ; value represents the high order 16-bits of the CS segment base, so the > ; hypervisor must left shift the value of the CS segement base by 16 bits to > ; form the full CS segment base for the CS segment register. It would then > ; program the EIP register with the IP value as read. > ; > > -TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 > - > sevEsResetBlockStart: > DD SEV_ES_AP_RESET_IP > DW sevEsResetBlockEnd - sevEsResetBlockStart > DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F > DB 0x89, 0x0E, 0x68, 0xC7, 0x7E, 0x2F, 0xB4, 0x4E > sevEsResetBlockEnd: > +guidedStructuresEnd: > > ALIGN 16 > > applicationProcessorEntryPoint: > ; > ; Application Processors entry point > ; > ; GenFv generates code aligned on a 4k boundary which will jump to this > ; location. (0xffffffe0) This allows the Local APIC Startup IPI to be > ; used to wake up the application processors. > ; > jmp EarlyApInitReal16 Back to your patch: On 11/12/20 01:13, James Bottomley wrote: > diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/ResetVector.nasmb > index 4913b379a9..c5e0fe93ab 100644 > --- a/OvmfPkg/ResetVector/ResetVector.nasmb > +++ b/OvmfPkg/ResetVector/ResetVector.nasmb > @@ -83,5 +83,7 @@ > %include "Main.asm" > > %define SEV_ES_AP_RESET_IP FixedPcdGet32 (PcdSevEsWorkAreaBase) > + %define SEV_LAUNCH_SECRET_BASE FixedPcdGet32 (PcdSevLaunchSecretBase) > + %define SEV_LAUNCH_SECRET_SIZE FixedPcdGet32 (PcdSevLaunchSecretSize) > %include "Ia16/ResetVectorVtf0.asm" > > OK. Thanks, Laszlo ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd 2020-11-16 22:46 ` [edk2-devel] " Laszlo Ersek @ 2020-11-18 20:23 ` James Bottomley 2020-11-19 7:50 ` Laszlo Ersek 2020-11-18 20:39 ` Lendacky, Thomas 1 sibling, 1 reply; 35+ messages in thread From: James Bottomley @ 2020-11-18 20:23 UTC (permalink / raw) To: Laszlo Ersek, devel Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On Mon, 2020-11-16 at 23:46 +0100, Laszlo Ersek wrote: > On 11/12/20 01:13, James Bottomley wrote: [... I made all the changes above this] > > diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > index 980e0138e7..7d3214e55d 100644 > > --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > @@ -35,6 +35,8 @@ ALIGN 16 > > ; the build time RIP value. The GUID must always be 48 bytes > > from the > > ; end of the firmware. > > ; > > +; 0xffffffc2 (-0x3e) - Base Location of the SEV Launch Secret > > +; 0xffffffc6 (-0x3a) - Size of SEV Launch Secret > > ; 0xffffffca (-0x36) - IP value > > ; 0xffffffcc (-0x34) - CS segment base [31:16] > > ; 0xffffffce (-0x32) - Size of the SEV-ES reset block > > @@ -51,6 +53,8 @@ ALIGN 16 > > TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 > > > > sevEsResetBlockStart: > > + DD SEV_LAUNCH_SECRET_BASE > > + DD SEV_LAUNCH_SECRET_SIZE > > DD SEV_ES_AP_RESET_IP > > DW sevEsResetBlockEnd - sevEsResetBlockStart > > DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F > > (5) I'd prefer if we could introduce a new GUID-ed structure for > these new fields. The logic in QEMU should be extended to start > scanning at 4GB-48 for GUIDS. If the GUID is not recognized, then > terminate scanning. Otherwise, act upon the GUID-ed structure found > there as necessary, and then determine the next GUID *candidate* > location by subtracting the last recognized GUID-ed structure's > "size" field. So for this one, we can do it either way. However, the current design of the sevEsRestBlock is (according to AMD) to allow the addition of SEV specific information. Each piece of information is a specific offset from the GUID and the length of the structure can only grow, so the ordering is fixed once the info is added and you can tell if the section contains what you're looking for is present if the length covers it. We can certainly move this to a fully GUID based system, which would allow us to have an unordered list rather than the strict definition the never decreasing length scheme allows, but if we do that, the length word above becomes redundant. I don't have a huge preference for either mechanism ... they seem to work equally well, but everyone should agree before I replace the length based scheme. James ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd 2020-11-18 20:23 ` James Bottomley @ 2020-11-19 7:50 ` Laszlo Ersek 2020-11-19 19:41 ` Brijesh Singh 0 siblings, 1 reply; 35+ messages in thread From: Laszlo Ersek @ 2020-11-19 7:50 UTC (permalink / raw) To: jejb, devel Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/18/20 21:23, James Bottomley wrote: > On Mon, 2020-11-16 at 23:46 +0100, Laszlo Ersek wrote: >> On 11/12/20 01:13, James Bottomley wrote: > [... I made all the changes above this] >>> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>> b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>> index 980e0138e7..7d3214e55d 100644 >>> --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>> +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>> @@ -35,6 +35,8 @@ ALIGN 16 >>> ; the build time RIP value. The GUID must always be 48 bytes >>> from the >>> ; end of the firmware. >>> ; >>> +; 0xffffffc2 (-0x3e) - Base Location of the SEV Launch Secret >>> +; 0xffffffc6 (-0x3a) - Size of SEV Launch Secret >>> ; 0xffffffca (-0x36) - IP value >>> ; 0xffffffcc (-0x34) - CS segment base [31:16] >>> ; 0xffffffce (-0x32) - Size of the SEV-ES reset block >>> @@ -51,6 +53,8 @@ ALIGN 16 >>> TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 >>> >>> sevEsResetBlockStart: >>> + DD SEV_LAUNCH_SECRET_BASE >>> + DD SEV_LAUNCH_SECRET_SIZE >>> DD SEV_ES_AP_RESET_IP >>> DW sevEsResetBlockEnd - sevEsResetBlockStart >>> DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F >> >> (5) I'd prefer if we could introduce a new GUID-ed structure for >> these new fields. The logic in QEMU should be extended to start >> scanning at 4GB-48 for GUIDS. If the GUID is not recognized, then >> terminate scanning. Otherwise, act upon the GUID-ed structure found >> there as necessary, and then determine the next GUID *candidate* >> location by subtracting the last recognized GUID-ed structure's >> "size" field. > > So for this one, we can do it either way. However, the current design > of the sevEsRestBlock is (according to AMD) to allow the addition of > SEV specific information. Each piece of information is a specific > offset from the GUID and the length of the structure can only grow, so > the ordering is fixed once the info is added and you can tell if the > section contains what you're looking for is present if the length > covers it. > > We can certainly move this to a fully GUID based system, which would > allow us to have an unordered list rather than the strict definition > the never decreasing length scheme allows, but if we do that, the > length word above becomes redundant. Well, GUIDed structs in UEFI/PI are sometimes permitted to grow compatibily, and for that, either a revision field or a size field is necessary / used. I kind of desire both here -- it makes sense to extend (for example) the SEV-ES reset block with relevant information, and to add other blocks of information (identified with different GUIDs). Basically I wouldn't want to finalize the SEV-ES AP reset block just yet, *but* I also think this new information does not beloing in the SEV-ES *AP reset block*. The new info is related to SEV-ES alright, but not to the AP reset block, in my opinion. If you read the larger context (the docs) in the assembly source around "sevEsResetBlockStart", the launch secret just doesn't seem to fit that. > I don't have a huge preference for either mechanism ... they seem to > work equally well, but everyone should agree before I replace the > length based scheme. I agree we should all agree about it first. And, to reiterate, I'd like to keep both the length fields and the GUID-ed identification. In other words, a GUID should not imply an exact struct size, just a minimum struct size. Thanks! Laszlo ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd 2020-11-19 7:50 ` Laszlo Ersek @ 2020-11-19 19:41 ` Brijesh Singh 2020-11-20 6:29 ` jejb 0 siblings, 1 reply; 35+ messages in thread From: Brijesh Singh @ 2020-11-19 19:41 UTC (permalink / raw) To: Laszlo Ersek, jejb, devel Cc: brijesh.singh, dovmurik, Dov.Murik1, ashish.kalra, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/19/20 1:50 AM, Laszlo Ersek wrote: > On 11/18/20 21:23, James Bottomley wrote: >> On Mon, 2020-11-16 at 23:46 +0100, Laszlo Ersek wrote: >>> On 11/12/20 01:13, James Bottomley wrote: >> [... I made all the changes above this] >>>> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>> b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>> index 980e0138e7..7d3214e55d 100644 >>>> --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>> +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>> @@ -35,6 +35,8 @@ ALIGN 16 >>>> ; the build time RIP value. The GUID must always be 48 bytes >>>> from the >>>> ; end of the firmware. >>>> ; >>>> +; 0xffffffc2 (-0x3e) - Base Location of the SEV Launch Secret >>>> +; 0xffffffc6 (-0x3a) - Size of SEV Launch Secret >>>> ; 0xffffffca (-0x36) - IP value >>>> ; 0xffffffcc (-0x34) - CS segment base [31:16] >>>> ; 0xffffffce (-0x32) - Size of the SEV-ES reset block >>>> @@ -51,6 +53,8 @@ ALIGN 16 >>>> TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 >>>> >>>> sevEsResetBlockStart: >>>> + DD SEV_LAUNCH_SECRET_BASE >>>> + DD SEV_LAUNCH_SECRET_SIZE >>>> DD SEV_ES_AP_RESET_IP >>>> DW sevEsResetBlockEnd - sevEsResetBlockStart >>>> DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F >>> (5) I'd prefer if we could introduce a new GUID-ed structure for >>> these new fields. The logic in QEMU should be extended to start >>> scanning at 4GB-48 for GUIDS. If the GUID is not recognized, then >>> terminate scanning. Otherwise, act upon the GUID-ed structure found >>> there as necessary, and then determine the next GUID *candidate* >>> location by subtracting the last recognized GUID-ed structure's >>> "size" field. >> So for this one, we can do it either way. However, the current design >> of the sevEsRestBlock is (according to AMD) to allow the addition of >> SEV specific information. Each piece of information is a specific >> offset from the GUID and the length of the structure can only grow, so >> the ordering is fixed once the info is added and you can tell if the >> section contains what you're looking for is present if the length >> covers it. >> >> We can certainly move this to a fully GUID based system, which would >> allow us to have an unordered list rather than the strict definition >> the never decreasing length scheme allows, but if we do that, the >> length word above becomes redundant. > Well, GUIDed structs in UEFI/PI are sometimes permitted to grow > compatibily, and for that, either a revision field or a size field is > necessary / used. I kind of desire both here -- it makes sense to extend > (for example) the SEV-ES reset block with relevant information, and to > add other blocks of information (identified with different GUIDs). > > Basically I wouldn't want to finalize the SEV-ES AP reset block just > yet, *but* I also think this new information does not beloing in the > SEV-ES *AP reset block*. The new info is related to SEV-ES alright, but > not to the AP reset block, in my opinion. If you read the larger context > (the docs) in the assembly source around "sevEsResetBlockStart", the > launch secret just doesn't seem to fit that. > >> I don't have a huge preference for either mechanism ... they seem to >> work equally well, but everyone should agree before I replace the >> length based scheme. > I agree we should all agree about it first. > > And, to reiterate, I'd like to keep both the length fields and the > GUID-ed identification. In other words, a GUID should not imply an exact > struct size, just a minimum struct size. I agree with the GUID based approach, it aligns well with the future needs. Looking forwardm we will need to reserve couple of pages (secret and cpuid) for the SNP. In my WIP patches I extended reset block to define a new GUID for those new fields. https://github.com/AMDESE/ovmf/commit/87d47319411763d91219b377da709efdb057e662#diff-0ca7ec2856c316694c87b519c95db3270e0cac798eb09745cce167aad7f2d46dR28 And I am using this qemu patch to iterate through all the GUIDs and call the corresponding callbacks. https://github.com/AMDESE/qemu/commit/16a1266353d372cbb7c1998f27081fb8aa4d31e9 > > Thanks! > Laszlo > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd 2020-11-19 19:41 ` Brijesh Singh @ 2020-11-20 6:29 ` jejb 2020-11-20 10:59 ` Laszlo Ersek 0 siblings, 1 reply; 35+ messages in thread From: jejb @ 2020-11-20 6:29 UTC (permalink / raw) To: Brijesh Singh, Laszlo Ersek, devel Cc: dovmurik, Dov.Murik1, ashish.kalra, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On Thu, 2020-11-19 at 13:41 -0600, Brijesh Singh wrote: > On 11/19/20 1:50 AM, Laszlo Ersek wrote: > > On 11/18/20 21:23, James Bottomley wrote: > > > On Mon, 2020-11-16 at 23:46 +0100, Laszlo Ersek wrote: > > > > On 11/12/20 01:13, James Bottomley wrote: > > > [... I made all the changes above this] > > > > > diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > > > > b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > > > > index 980e0138e7..7d3214e55d 100644 > > > > > --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > > > > +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > > > > > @@ -35,6 +35,8 @@ ALIGN 16 > > > > > ; the build time RIP value. The GUID must always be 48 > > > > > bytes > > > > > from the > > > > > ; end of the firmware. > > > > > ; > > > > > +; 0xffffffc2 (-0x3e) - Base Location of the SEV Launch > > > > > Secret > > > > > +; 0xffffffc6 (-0x3a) - Size of SEV Launch Secret > > > > > ; 0xffffffca (-0x36) - IP value > > > > > ; 0xffffffcc (-0x34) - CS segment base [31:16] > > > > > ; 0xffffffce (-0x32) - Size of the SEV-ES reset block > > > > > @@ -51,6 +53,8 @@ ALIGN 16 > > > > > TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB > > > > > 0 > > > > > > > > > > sevEsResetBlockStart: > > > > > + DD SEV_LAUNCH_SECRET_BASE > > > > > + DD SEV_LAUNCH_SECRET_SIZE > > > > > DD SEV_ES_AP_RESET_IP > > > > > DW sevEsResetBlockEnd - sevEsResetBlockStart > > > > > DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F > > > > (5) I'd prefer if we could introduce a new GUID-ed structure > > > > for these new fields. The logic in QEMU should be extended to > > > > start scanning at 4GB-48 for GUIDS. If the GUID is not > > > > recognized, then terminate scanning. Otherwise, act upon the > > > > GUID-ed structure found there as necessary, and then determine > > > > the next GUID *candidate* location by subtracting the last > > > > recognized GUID-ed structure's "size" field. > > > So for this one, we can do it either way. However, the current > > > design of the sevEsRestBlock is (according to AMD) to allow the > > > addition of SEV specific information. Each piece of information > > > is a specific offset from the GUID and the length of the > > > structure can only grow, so the ordering is fixed once the info > > > is added and you can tell if the section contains what you're > > > looking for is present if the length covers it. > > > > > > We can certainly move this to a fully GUID based system, which > > > would allow us to have an unordered list rather than the strict > > > definition the never decreasing length scheme allows, but if we > > > do that, the length word above becomes redundant. > > Well, GUIDed structs in UEFI/PI are sometimes permitted to grow > > compatibily, and for that, either a revision field or a size field > > is necessary / used. I kind of desire both here -- it makes sense > > to extend (for example) the SEV-ES reset block with relevant > > information, and to add other blocks of information (identified > > with different GUIDs). > > > > Basically I wouldn't want to finalize the SEV-ES AP reset block > > just yet, *but* I also think this new information does not beloing > > in the SEV-ES *AP reset block*. The new info is related to SEV-ES > > alright, but not to the AP reset block, in my opinion. If you read > > the larger context (the docs) in the assembly source around > > "sevEsResetBlockStart", the launch secret just doesn't seem to fit > > that. > > > > > I don't have a huge preference for either mechanism ... they seem > > > to work equally well, but everyone should agree before I replace > > > the length based scheme. I agree we should all agree about it > > > first. > > > > And, to reiterate, I'd like to keep both the length fields and the > > GUID-ed identification. In other words, a GUID should not imply an > > exact struct size, just a minimum struct size. > > I agree with the GUID based approach, it aligns well with the future > needs. Looking forwardm we will need to reserve couple of pages > (secret and cpuid) for the SNP. In my WIP patches I extended reset > block to define a new GUID for those new fields. > > https://github.com/AMDESE/ovmf/commit/87d47319411763d91219b377da709efdb057e662#diff-0ca7ec2856c316694c87b519c95db3270e0cac798eb09745cce167aad7f2d46dR28 > > And I am using this qemu patch to iterate through all the GUIDs and > call the corresponding callbacks. > > https://github.com/AMDESE/qemu/commit/16a1266353d372cbb7c1998f27081fb8aa4d31e9 OK, if that's not yet upstream, I think we should do this properly: that means having a guid and length that identifies the entire table and then all the incorporated guids and lengths. That way we don't have a double meaning for the reset block guid as both identifying the start of the table and the reset vector data. Also it means we don't need a zero guid to signal the end of the table. And also means the reset block GUID doesn't have to always be present (if it got deprecated for some reason). However, the downside is that you'll have to pull out the table by this new guid at 0xffffffd0 and its length and then iterate over the table to find the reset block guid ... but that will make it very easy to add the additional guids. James ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd 2020-11-20 6:29 ` jejb @ 2020-11-20 10:59 ` Laszlo Ersek 0 siblings, 0 replies; 35+ messages in thread From: Laszlo Ersek @ 2020-11-20 10:59 UTC (permalink / raw) To: jejb, Brijesh Singh, devel Cc: dovmurik, Dov.Murik1, ashish.kalra, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/20/20 07:29, James Bottomley wrote: > On Thu, 2020-11-19 at 13:41 -0600, Brijesh Singh wrote: >> On 11/19/20 1:50 AM, Laszlo Ersek wrote: >>> On 11/18/20 21:23, James Bottomley wrote: >>>> On Mon, 2020-11-16 at 23:46 +0100, Laszlo Ersek wrote: >>>>> On 11/12/20 01:13, James Bottomley wrote: >>>> [... I made all the changes above this] >>>>>> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>>>> b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>>>> index 980e0138e7..7d3214e55d 100644 >>>>>> --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>>>> +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>>>> @@ -35,6 +35,8 @@ ALIGN 16 >>>>>> ; the build time RIP value. The GUID must always be 48 >>>>>> bytes >>>>>> from the >>>>>> ; end of the firmware. >>>>>> ; >>>>>> +; 0xffffffc2 (-0x3e) - Base Location of the SEV Launch >>>>>> Secret >>>>>> +; 0xffffffc6 (-0x3a) - Size of SEV Launch Secret >>>>>> ; 0xffffffca (-0x36) - IP value >>>>>> ; 0xffffffcc (-0x34) - CS segment base [31:16] >>>>>> ; 0xffffffce (-0x32) - Size of the SEV-ES reset block >>>>>> @@ -51,6 +53,8 @@ ALIGN 16 >>>>>> TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB >>>>>> 0 >>>>>> >>>>>> sevEsResetBlockStart: >>>>>> + DD SEV_LAUNCH_SECRET_BASE >>>>>> + DD SEV_LAUNCH_SECRET_SIZE >>>>>> DD SEV_ES_AP_RESET_IP >>>>>> DW sevEsResetBlockEnd - sevEsResetBlockStart >>>>>> DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F >>>>> (5) I'd prefer if we could introduce a new GUID-ed structure >>>>> for these new fields. The logic in QEMU should be extended to >>>>> start scanning at 4GB-48 for GUIDS. If the GUID is not >>>>> recognized, then terminate scanning. Otherwise, act upon the >>>>> GUID-ed structure found there as necessary, and then determine >>>>> the next GUID *candidate* location by subtracting the last >>>>> recognized GUID-ed structure's "size" field. >>>> So for this one, we can do it either way. However, the current >>>> design of the sevEsRestBlock is (according to AMD) to allow the >>>> addition of SEV specific information. Each piece of information >>>> is a specific offset from the GUID and the length of the >>>> structure can only grow, so the ordering is fixed once the info >>>> is added and you can tell if the section contains what you're >>>> looking for is present if the length covers it. >>>> >>>> We can certainly move this to a fully GUID based system, which >>>> would allow us to have an unordered list rather than the strict >>>> definition the never decreasing length scheme allows, but if we >>>> do that, the length word above becomes redundant. >>> Well, GUIDed structs in UEFI/PI are sometimes permitted to grow >>> compatibily, and for that, either a revision field or a size field >>> is necessary / used. I kind of desire both here -- it makes sense >>> to extend (for example) the SEV-ES reset block with relevant >>> information, and to add other blocks of information (identified >>> with different GUIDs). >>> >>> Basically I wouldn't want to finalize the SEV-ES AP reset block >>> just yet, *but* I also think this new information does not beloing >>> in the SEV-ES *AP reset block*. The new info is related to SEV-ES >>> alright, but not to the AP reset block, in my opinion. If you read >>> the larger context (the docs) in the assembly source around >>> "sevEsResetBlockStart", the launch secret just doesn't seem to fit >>> that. >>> >>>> I don't have a huge preference for either mechanism ... they seem >>>> to work equally well, but everyone should agree before I replace >>>> the length based scheme. I agree we should all agree about it >>>> first. >>> >>> And, to reiterate, I'd like to keep both the length fields and the >>> GUID-ed identification. In other words, a GUID should not imply an >>> exact struct size, just a minimum struct size. >> >> I agree with the GUID based approach, it aligns well with the future >> needs. Looking forwardm we will need to reserve couple of pages >> (secret and cpuid) for the SNP. In my WIP patches I extended reset >> block to define a new GUID for those new fields. >> >> https://github.com/AMDESE/ovmf/commit/87d47319411763d91219b377da709efdb057e662#diff-0ca7ec2856c316694c87b519c95db3270e0cac798eb09745cce167aad7f2d46dR28 >> >> And I am using this qemu patch to iterate through all the GUIDs and >> call the corresponding callbacks. >> >> https://github.com/AMDESE/qemu/commit/16a1266353d372cbb7c1998f27081fb8aa4d31e9 > > OK, if that's not yet upstream, I think we should do this properly: > that means having a guid and length that identifies the entire table > and then all the incorporated guids and lengths. That way we don't > have a double meaning for the reset block guid as both identifying the > start of the table and the reset vector data. Also it means we don't > need a zero guid to signal the end of the table. And also means the > reset block GUID doesn't have to always be present (if it got > deprecated for some reason). > > However, the downside is that you'll have to pull out the table by this > new guid at 0xffffffd0 and its length and then iterate over the table > to find the reset block guid ... but that will make it very easy to add > the additional guids. I agree with doing things properly. Thanks Laszlo ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd 2020-11-16 22:46 ` [edk2-devel] " Laszlo Ersek 2020-11-18 20:23 ` James Bottomley @ 2020-11-18 20:39 ` Lendacky, Thomas 2020-11-19 7:51 ` Laszlo Ersek 1 sibling, 1 reply; 35+ messages in thread From: Lendacky, Thomas @ 2020-11-18 20:39 UTC (permalink / raw) To: devel, lersek, jejb Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, frankeh, Dr . David Alan Gilbert On 11/16/20 4:46 PM, Laszlo Ersek via groups.io wrote: > On 11/12/20 01:13, James Bottomley wrote: >> SEV needs an area to place an injected secret where OVMF can find it >> and pass it up as a ConfigurationTable. This patch implements the >> area itself as an addition to the SEV enhanced reset vector. The >> reset vector scheme allows additions but not removals. If the size of >> the reset vector is 22, it only contains the AP reset IP, but if it is >> 30 (or greater) it contains the SEV secret page location and size. >> >> Signed-off-by: James Bottomley <jejb@linux.ibm.com> >> --- >> OvmfPkg/OvmfPkg.dec | 5 +++++ >> OvmfPkg/AmdSev/AmdSevX64.fdf | 3 +++ >> OvmfPkg/ResetVector/ResetVector.inf | 4 ++++ >> OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 ++++ >> OvmfPkg/ResetVector/ResetVector.nasmb | 2 ++ >> 5 files changed, 18 insertions(+) >> ... >> ; >> ; SEV-ES Processor Reset support >> ; >> ; sevEsResetBlock: >> ; For the initial boot of an AP under SEV-ES, the "reset" RIP must be >> ; programmed to the RAM area defined by SEV_ES_AP_RESET_IP. A known offset >> ; and GUID will be used to locate this block in the firmware and extract >> ; the build time RIP value. The GUID must always be 48 bytes from the >> ; end of the firmware. >> ; >> ; 0xffffffca (-0x36) - IP value >> ; 0xffffffcc (-0x34) - CS segment base [31:16] >> ; 0xffffffce (-0x32) - Size of the SEV-ES reset block >> ; 0xffffffd0 (-0x30) - SEV-ES reset block GUID >> ; (00f771de-1a7e-4fcb-890e-68c77e2fb44e) >> ; >> ; A hypervisor reads the CS segement base and IP value. The CS segment base >> ; value represents the high order 16-bits of the CS segment base, so the >> ; hypervisor must left shift the value of the CS segement base by 16 bits to >> ; form the full CS segment base for the CS segment register. It would then >> ; program the EIP register with the IP value as read. >> ; >> >> TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 >> >> sevEsResetBlockStart: >> DD SEV_ES_AP_RESET_IP >> DW sevEsResetBlockEnd - sevEsResetBlockStart >> DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F >> DB 0x89, 0x0E, 0x68, 0xC7, 0x7E, 0x2F, 0xB4, 0x4E >> sevEsResetBlockEnd: > > I'm not exactly sure why we added the padding (TIMES ... DB 0) in edk2 > commit 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES > AP reset vector", 2020-08-17). I can imagine it was *already* for the > same purpose -- to deterministically terminate the above-described > backwards-traversal of the GUID-ed structures (and at the same time > remain aligned to 32 bytes, regarding the cumulative size of all > provided structures). The padding is required to "push" the GUID into the proper location at exactly 48 bytes from the end of the file. Without the padding, the GUID doesn't line up correctly and can't be located. Thanks, Tom > > So, in that vein, I'd propose something like this (relative to master @ > d448574e7310): > >> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >> index 980e0138e7fe..957356ff997e 100644 >> --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >> +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >> @@ -16,55 +16,83 @@ ALIGN 16 >> ; Pad the image size to 4k when page tables are in VTF0 >> ; >> ; If the VTF0 image has page tables built in, then we need to make >> ; sure the end of VTF0 is 4k above where the page tables end. >> ; >> ; This is required so the page tables will be 4k aligned when VTF0 is >> ; located just below 0x100000000 (4GB) in the firmware device. >> ; >> %ifdef ALIGN_TOP_TO_4K_FOR_PAGING >> TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0 >> %endif >> >> +; >> +; pre-pad the sequence of GUIDed structures to a multiple of 32 bytes >> +; >> +TIMES (31 - (guidedStructuresEnd - guidedStructuresStart + 31) % 32) DB 0 >> + >> +guidedStructuresStart: >> +; >> +; Zero GUID to terminate decreasing address order traversal. >> +; >> +TIMES 16 DB 0 >> + >> +; >> +; Expose the location of the SEV Launch Secret area to the hypervisor >> +; (necessary when using the remote attestation firmware platform). >> +; >> +; sevLaunchSecretDescriptor: >> +; This GUIDed structure is chained in decreasing address order from >> +; sevEsResetBlock. It describes the guest RAM area where the hypervisor has >> +; to securely inject the SEV Launch Secret. The GUID is >> +; 78C93F1E-ADBC-4259-B92B-CE81E523FBC4. >> +; >> +sevLaunchSecretDescriptorStart: >> + DD SEV_LAUNCH_SECRET_BASE >> + DD SEV_LAUNCH_SECRET_SIZE >> + DW sevLaunchSecretDescriptorEnd - sevLaunchSecretDescriptorStart >> + DB 0x1E, 0x3F, 0xC9, 0x78, 0xBC, 0xAD, 0x59, 0x42 >> + DB 0xB9, 0x2B, 0xCE, 0x81, 0xE5, 0x23, 0xFB, 0xC4 >> +sevLaunchSecretDescriptorEnd: >> + >> ; >> ; SEV-ES Processor Reset support >> ; >> ; sevEsResetBlock: >> ; For the initial boot of an AP under SEV-ES, the "reset" RIP must be >> ; programmed to the RAM area defined by SEV_ES_AP_RESET_IP. A known offset >> ; and GUID will be used to locate this block in the firmware and extract >> ; the build time RIP value. The GUID must always be 48 bytes from the >> ; end of the firmware. >> ; >> ; 0xffffffca (-0x36) - IP value >> ; 0xffffffcc (-0x34) - CS segment base [31:16] >> ; 0xffffffce (-0x32) - Size of the SEV-ES reset block >> ; 0xffffffd0 (-0x30) - SEV-ES reset block GUID >> ; (00f771de-1a7e-4fcb-890e-68c77e2fb44e) >> ; >> ; A hypervisor reads the CS segement base and IP value. The CS segment base >> ; value represents the high order 16-bits of the CS segment base, so the >> ; hypervisor must left shift the value of the CS segement base by 16 bits to >> ; form the full CS segment base for the CS segment register. It would then >> ; program the EIP register with the IP value as read. >> ; >> >> -TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 >> - >> sevEsResetBlockStart: >> DD SEV_ES_AP_RESET_IP >> DW sevEsResetBlockEnd - sevEsResetBlockStart >> DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F >> DB 0x89, 0x0E, 0x68, 0xC7, 0x7E, 0x2F, 0xB4, 0x4E >> sevEsResetBlockEnd: >> +guidedStructuresEnd: >> >> ALIGN 16 >> >> applicationProcessorEntryPoint: >> ; >> ; Application Processors entry point >> ; >> ; GenFv generates code aligned on a 4k boundary which will jump to this >> ; location. (0xffffffe0) This allows the Local APIC Startup IPI to be >> ; used to wake up the application processors. >> ; >> jmp EarlyApInitReal16 > > Back to your patch: > > On 11/12/20 01:13, James Bottomley wrote: >> diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/ResetVector.nasmb >> index 4913b379a9..c5e0fe93ab 100644 >> --- a/OvmfPkg/ResetVector/ResetVector.nasmb >> +++ b/OvmfPkg/ResetVector/ResetVector.nasmb >> @@ -83,5 +83,7 @@ >> %include "Main.asm" >> >> %define SEV_ES_AP_RESET_IP FixedPcdGet32 (PcdSevEsWorkAreaBase) >> + %define SEV_LAUNCH_SECRET_BASE FixedPcdGet32 (PcdSevLaunchSecretBase) >> + %define SEV_LAUNCH_SECRET_SIZE FixedPcdGet32 (PcdSevLaunchSecretSize) >> %include "Ia16/ResetVectorVtf0.asm" >> >> > > OK. > > Thanks, > Laszlo > > > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd 2020-11-18 20:39 ` Lendacky, Thomas @ 2020-11-19 7:51 ` Laszlo Ersek 0 siblings, 0 replies; 35+ messages in thread From: Laszlo Ersek @ 2020-11-19 7:51 UTC (permalink / raw) To: Tom Lendacky, devel, jejb Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, frankeh, Dr . David Alan Gilbert On 11/18/20 21:39, Tom Lendacky wrote: > On 11/16/20 4:46 PM, Laszlo Ersek via groups.io wrote: >> On 11/12/20 01:13, James Bottomley wrote: >>> SEV needs an area to place an injected secret where OVMF can find it >>> and pass it up as a ConfigurationTable. This patch implements the >>> area itself as an addition to the SEV enhanced reset vector. The >>> reset vector scheme allows additions but not removals. If the size of >>> the reset vector is 22, it only contains the AP reset IP, but if it is >>> 30 (or greater) it contains the SEV secret page location and size. >>> >>> Signed-off-by: James Bottomley <jejb@linux.ibm.com> >>> --- >>> OvmfPkg/OvmfPkg.dec | 5 +++++ >>> OvmfPkg/AmdSev/AmdSevX64.fdf | 3 +++ >>> OvmfPkg/ResetVector/ResetVector.inf | 4 ++++ >>> OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 ++++ >>> OvmfPkg/ResetVector/ResetVector.nasmb | 2 ++ >>> 5 files changed, 18 insertions(+) >>> > > ... > >>> ; >>> ; SEV-ES Processor Reset support >>> ; >>> ; sevEsResetBlock: >>> ; For the initial boot of an AP under SEV-ES, the "reset" RIP must be >>> ; programmed to the RAM area defined by SEV_ES_AP_RESET_IP. A known >>> offset >>> ; and GUID will be used to locate this block in the firmware and >>> extract >>> ; the build time RIP value. The GUID must always be 48 bytes from the >>> ; end of the firmware. >>> ; >>> ; 0xffffffca (-0x36) - IP value >>> ; 0xffffffcc (-0x34) - CS segment base [31:16] >>> ; 0xffffffce (-0x32) - Size of the SEV-ES reset block >>> ; 0xffffffd0 (-0x30) - SEV-ES reset block GUID >>> ; (00f771de-1a7e-4fcb-890e-68c77e2fb44e) >>> ; >>> ; A hypervisor reads the CS segement base and IP value. The CS >>> segment base >>> ; value represents the high order 16-bits of the CS segment base, >>> so the >>> ; hypervisor must left shift the value of the CS segement base by >>> 16 bits to >>> ; form the full CS segment base for the CS segment register. It >>> would then >>> ; program the EIP register with the IP value as read. >>> ; >>> >>> TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 >>> >>> sevEsResetBlockStart: >>> DD SEV_ES_AP_RESET_IP >>> DW sevEsResetBlockEnd - sevEsResetBlockStart >>> DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F >>> DB 0x89, 0x0E, 0x68, 0xC7, 0x7E, 0x2F, 0xB4, 0x4E >>> sevEsResetBlockEnd: >> >> I'm not exactly sure why we added the padding (TIMES ... DB 0) in edk2 >> commit 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES >> AP reset vector", 2020-08-17). I can imagine it was *already* for the >> same purpose -- to deterministically terminate the above-described >> backwards-traversal of the GUID-ed structures (and at the same time >> remain aligned to 32 bytes, regarding the cumulative size of all >> provided structures). > > The padding is required to "push" the GUID into the proper location at > exactly 48 bytes from the end of the file. Without the padding, the GUID > doesn't line up correctly and can't be located. OK, thanks! So I think that my proposed movement / reworking of the prepended padding should be fine. Laszlo > > Thanks, > Tom > >> >> So, in that vein, I'd propose something like this (relative to master @ >> d448574e7310): >> >>> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>> b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>> index 980e0138e7fe..957356ff997e 100644 >>> --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>> +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>> @@ -16,55 +16,83 @@ ALIGN 16 >>> ; Pad the image size to 4k when page tables are in VTF0 >>> ; >>> ; If the VTF0 image has page tables built in, then we need to make >>> ; sure the end of VTF0 is 4k above where the page tables end. >>> ; >>> ; This is required so the page tables will be 4k aligned when VTF0 is >>> ; located just below 0x100000000 (4GB) in the firmware device. >>> ; >>> %ifdef ALIGN_TOP_TO_4K_FOR_PAGING >>> TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0 >>> %endif >>> >>> +; >>> +; pre-pad the sequence of GUIDed structures to a multiple of 32 bytes >>> +; >>> +TIMES (31 - (guidedStructuresEnd - guidedStructuresStart + 31) % 32) >>> DB 0 >>> + >>> +guidedStructuresStart: >>> +; >>> +; Zero GUID to terminate decreasing address order traversal. >>> +; >>> +TIMES 16 DB 0 >>> + >>> +; >>> +; Expose the location of the SEV Launch Secret area to the hypervisor >>> +; (necessary when using the remote attestation firmware platform). >>> +; >>> +; sevLaunchSecretDescriptor: >>> +; This GUIDed structure is chained in decreasing address order from >>> +; sevEsResetBlock. It describes the guest RAM area where the >>> hypervisor has >>> +; to securely inject the SEV Launch Secret. The GUID is >>> +; 78C93F1E-ADBC-4259-B92B-CE81E523FBC4. >>> +; >>> +sevLaunchSecretDescriptorStart: >>> + DD SEV_LAUNCH_SECRET_BASE >>> + DD SEV_LAUNCH_SECRET_SIZE >>> + DW sevLaunchSecretDescriptorEnd - >>> sevLaunchSecretDescriptorStart >>> + DB 0x1E, 0x3F, 0xC9, 0x78, 0xBC, 0xAD, 0x59, 0x42 >>> + DB 0xB9, 0x2B, 0xCE, 0x81, 0xE5, 0x23, 0xFB, 0xC4 >>> +sevLaunchSecretDescriptorEnd: >>> + >>> ; >>> ; SEV-ES Processor Reset support >>> ; >>> ; sevEsResetBlock: >>> ; For the initial boot of an AP under SEV-ES, the "reset" RIP >>> must be >>> ; programmed to the RAM area defined by SEV_ES_AP_RESET_IP. A >>> known offset >>> ; and GUID will be used to locate this block in the firmware and >>> extract >>> ; the build time RIP value. The GUID must always be 48 bytes from >>> the >>> ; end of the firmware. >>> ; >>> ; 0xffffffca (-0x36) - IP value >>> ; 0xffffffcc (-0x34) - CS segment base [31:16] >>> ; 0xffffffce (-0x32) - Size of the SEV-ES reset block >>> ; 0xffffffd0 (-0x30) - SEV-ES reset block GUID >>> ; (00f771de-1a7e-4fcb-890e-68c77e2fb44e) >>> ; >>> ; A hypervisor reads the CS segement base and IP value. The CS >>> segment base >>> ; value represents the high order 16-bits of the CS segment base, >>> so the >>> ; hypervisor must left shift the value of the CS segement base by >>> 16 bits to >>> ; form the full CS segment base for the CS segment register. It >>> would then >>> ; program the EIP register with the IP value as read. >>> ; >>> >>> -TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0 >>> - >>> sevEsResetBlockStart: >>> DD SEV_ES_AP_RESET_IP >>> DW sevEsResetBlockEnd - sevEsResetBlockStart >>> DB 0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F >>> DB 0x89, 0x0E, 0x68, 0xC7, 0x7E, 0x2F, 0xB4, 0x4E >>> sevEsResetBlockEnd: >>> +guidedStructuresEnd: >>> >>> ALIGN 16 >>> >>> applicationProcessorEntryPoint: >>> ; >>> ; Application Processors entry point >>> ; >>> ; GenFv generates code aligned on a 4k boundary which will jump to >>> this >>> ; location. (0xffffffe0) This allows the Local APIC Startup IPI >>> to be >>> ; used to wake up the application processors. >>> ; >>> jmp EarlyApInitReal16 >> >> Back to your patch: >> >> On 11/12/20 01:13, James Bottomley wrote: >>> diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb >>> b/OvmfPkg/ResetVector/ResetVector.nasmb >>> index 4913b379a9..c5e0fe93ab 100644 >>> --- a/OvmfPkg/ResetVector/ResetVector.nasmb >>> +++ b/OvmfPkg/ResetVector/ResetVector.nasmb >>> @@ -83,5 +83,7 @@ >>> %include "Main.asm" >>> >>> %define SEV_ES_AP_RESET_IP FixedPcdGet32 (PcdSevEsWorkAreaBase) >>> + %define SEV_LAUNCH_SECRET_BASE FixedPcdGet32 >>> (PcdSevLaunchSecretBase) >>> + %define SEV_LAUNCH_SECRET_SIZE FixedPcdGet32 >>> (PcdSevLaunchSecretSize) >>> %include "Ia16/ResetVectorVtf0.asm" >>> >>> >> >> OK. >> >> Thanks, >> Laszlo >> >> >> >> >> >> > ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 4/4] OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table 2020-11-12 0:13 [PATCH 0/4] SEV Encrypted Boot for Ovmf James Bottomley ` (2 preceding siblings ...) 2020-11-12 0:13 ` [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd James Bottomley @ 2020-11-12 0:13 ` James Bottomley 2020-11-17 0:12 ` [edk2-devel] " Laszlo Ersek 2020-11-12 16:21 ` [PATCH 0/4] SEV Encrypted Boot for Ovmf Ashish Kalra ` (4 subsequent siblings) 8 siblings, 1 reply; 35+ messages in thread From: James Bottomley @ 2020-11-12 0:13 UTC (permalink / raw) To: devel Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, jejb, frankeh, Dr . David Alan Gilbert This is to allow the boot loader (grub) to pick up the secret area. The Configuration Table simply points to the base and size (in physical memory) and this area is covered by a Boot time HOB, meaning that the secret will be freed after ExitBootServices, by which time it should be consumed anyway. Signed-off-by: James Bottomley <jejb@linux.ibm.com> --- OvmfPkg/AmdSev/AmdSevX64.dsc | 3 ++ OvmfPkg/AmdSev/AmdSevX64.fdf | 3 ++ .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 +++++++++++++++ .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 +++++++++++++++++++ .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 ++++++++++++ .../SevLaunchSecret/SecretPei/SecretPei.c | 26 +++++++++++ 6 files changed, 145 insertions(+) create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc index 7d3663150e..eb8cc9d60a 100644 --- a/OvmfPkg/AmdSev/AmdSevX64.dsc +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc @@ -698,6 +698,7 @@ OvmfPkg/SmmAccess/SmmAccessPei.inf !endif UefiCpuPkg/CpuMpPei/CpuMpPei.inf + OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf !if $(TPM_ENABLE) == TRUE OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf @@ -1007,6 +1008,8 @@ } !endif + OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf + # # TPM support # diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf index 1fd38b3fe2..65ee4d993b 100644 --- a/OvmfPkg/AmdSev/AmdSevX64.fdf +++ b/OvmfPkg/AmdSev/AmdSevX64.fdf @@ -146,6 +146,7 @@ INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf INF OvmfPkg/SmmAccess/SmmAccessPei.inf !endif INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf +INF OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf !if $(TPM_ENABLE) == TRUE INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf @@ -290,6 +291,8 @@ INF ShellPkg/Application/Shell/Shell.inf INF MdeModulePkg/Logo/LogoDxe.inf +INF OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf + # # Network modules # diff --git a/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf b/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf new file mode 100644 index 0000000000..085162e5c4 --- /dev/null +++ b/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf @@ -0,0 +1,38 @@ +## @file +# Sev Secret configuration Table installer +# +# Copyright (C) 2020 James Bottomley, IBM Corporation. +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +[Defines] + INF_VERSION = 0x00010005 + BASE_NAME = SecretDxe + FILE_GUID = 6e2b9619-8810-4e9d-a177-d432bb9abeda + MODULE_TYPE = DXE_DRIVER + VERSION_STRING = 1.0 + ENTRY_POINT = InitializeSecretDxe + +[Sources] + SecretDxe.c + +[Packages] + OvmfPkg/OvmfPkg.dec + MdePkg/MdePkg.dec + +[LibraryClasses] + UefiBootServicesTableLib + UefiDriverEntryPoint + UefiLib + +[Guids] + gSevLaunchSecretGuid + +[FixedPcd] + gSevLaunchSecretGuid.PcdSevLaunchSecretBase + gSevLaunchSecretGuid.PcdSevLaunchSecretSize + +[Depex] + TRUE diff --git a/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf b/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf new file mode 100644 index 0000000000..b154dcc74e --- /dev/null +++ b/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf @@ -0,0 +1,46 @@ +## @file +# PEI support for SEV Secrets +# +# Copyright (C) 2020 James Bottomley, IBM Corporation. +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +[Defines] + INF_VERSION = 0x00010005 + BASE_NAME = SecretPei + FILE_GUID = 45260dde-0c3c-4b41-a226-ef3803fac7d4 + MODULE_TYPE = PEIM + VERSION_STRING = 1.0 + ENTRY_POINT = InitializeSecretPei + +# +# The following information is for reference only and not required by the build tools. +# +# VALID_ARCHITECTURES = IA32 X64 EBC +# + +[Sources] + SecretPei.c + +[Packages] + OvmfPkg/OvmfPkg.dec + MdePkg/MdePkg.dec + MdeModulePkg/MdeModulePkg.dec + +[LibraryClasses] + BaseLib + DebugLib + HobLib + PeiServicesLib + PeiServicesTablePointerLib + PeimEntryPoint + PcdLib + +[FixedPcd] + gSevLaunchSecretGuid.PcdSevLaunchSecretBase + gSevLaunchSecretGuid.PcdSevLaunchSecretSize + +[Depex] + TRUE diff --git a/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c b/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c new file mode 100644 index 0000000000..b40bbe1eb9 --- /dev/null +++ b/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c @@ -0,0 +1,29 @@ +/** @file + SEV Secret configuration table constructor + + Copyright (C) 2020 James Bottomley, IBM Corporation. + SPDX-License-Identifier: BSD-2-Clause-Patent +**/ +#include <PiDxe.h> +#include <Library/UefiLib.h> +#include <Library/UefiDriverEntryPoint.h> +#include <Library/UefiBootServicesTableLib.h> + +struct { + UINT32 base; + UINT32 size; +} secretDxeTable = { + FixedPcdGet32(PcdSevLaunchSecretBase), + FixedPcdGet32(PcdSevLaunchSecretSize), +}; + +EFI_STATUS +EFIAPI +InitializeSecretDxe( + IN EFI_HANDLE ImageHandle, + IN EFI_SYSTEM_TABLE *SystemTable + ) +{ + return gBS->InstallConfigurationTable (&gSevLaunchSecretGuid, + &secretDxeTable); +} diff --git a/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c b/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c new file mode 100644 index 0000000000..16b49792ad --- /dev/null +++ b/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c @@ -0,0 +1,26 @@ +/** @file + SEV Secret boot time HOB placement + + Copyright (C) 2020 James Bottomley, IBM Corporation. + SPDX-License-Identifier: BSD-2-Clause-Patent +**/ +#include <PiPei.h> +#include <Library/BaseLib.h> +#include <Library/DebugLib.h> +#include <Library/HobLib.h> +#include <Library/PcdLib.h> + +EFI_STATUS +EFIAPI +InitializeSecretPei ( + IN EFI_PEI_FILE_HANDLE FileHandle, + IN CONST EFI_PEI_SERVICES **PeiServices + ) +{ + BuildMemoryAllocationHob ( + PcdGet32 (PcdSevLaunchSecretBase), + PcdGet32 (PcdSevLaunchSecretSize), + EfiBootServicesData); + + return EFI_SUCCESS; +} -- 2.26.2 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 4/4] OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table 2020-11-12 0:13 ` [PATCH 4/4] OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table James Bottomley @ 2020-11-17 0:12 ` Laszlo Ersek 0 siblings, 0 replies; 35+ messages in thread From: Laszlo Ersek @ 2020-11-17 0:12 UTC (permalink / raw) To: devel, jejb Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/12/20 01:13, James Bottomley wrote: > This is to allow the boot loader (grub) to pick up the secret area. > The Configuration Table simply points to the base and size (in > physical memory) and this area is covered by a Boot time HOB, meaning > that the secret will be freed after ExitBootServices, by which time it > should be consumed anyway. > > Signed-off-by: James Bottomley <jejb@linux.ibm.com> > --- > OvmfPkg/AmdSev/AmdSevX64.dsc | 3 ++ > OvmfPkg/AmdSev/AmdSevX64.fdf | 3 ++ > .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 +++++++++++++++ > .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 +++++++++++++++++++ > .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 ++++++++++++ > .../SevLaunchSecret/SecretPei/SecretPei.c | 26 +++++++++++ > 6 files changed, 145 insertions(+) > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c > > diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc > index 7d3663150e..eb8cc9d60a 100644 > --- a/OvmfPkg/AmdSev/AmdSevX64.dsc > +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc > @@ -698,6 +698,7 @@ > OvmfPkg/SmmAccess/SmmAccessPei.inf > !endif > UefiCpuPkg/CpuMpPei/CpuMpPei.inf > + OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > > !if $(TPM_ENABLE) == TRUE > OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf > @@ -1007,6 +1008,8 @@ > } > !endif > > + OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > + > # > # TPM support > # > diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf > index 1fd38b3fe2..65ee4d993b 100644 > --- a/OvmfPkg/AmdSev/AmdSevX64.fdf > +++ b/OvmfPkg/AmdSev/AmdSevX64.fdf > @@ -146,6 +146,7 @@ INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf > INF OvmfPkg/SmmAccess/SmmAccessPei.inf > !endif > INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf > +INF OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > > !if $(TPM_ENABLE) == TRUE > INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf > @@ -290,6 +291,8 @@ INF ShellPkg/Application/Shell/Shell.inf > > INF MdeModulePkg/Logo/LogoDxe.inf > > +INF OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > + > # > # Network modules > # (1) Please split the SecretDxe-related hunks and new files to a separate patch. (1.a) Patch#4 should be called OvmfPkg/AmdSev: assign and protect the Sev Secret area It should contain the PEI phase-related changes. (1.b) Patch#5 should inherit the present subject ("OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table"), and should contain the DXE phase-related hunks and new files. I'll comment on patch#5 more, below. (2) In both the DSC and the FDF files, please place the OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf just above OvmfPkg/AmdSev/Grub/Grub.inf (Not a functional difference, it just improves consistency between the DSC and the FDF, plus this placement appears quite logical too.) (3) I suggest unnesting both SecretPei and SecretDxe from the SevLaunchSecret subdirectory, and removing that subdirectory. To me the following pathnames seem fine: - OvmfPkg/AmdSev/SecretPei/ - OvmfPkg/AmdSev/SecretDxe/ > diff --git a/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf b/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > new file mode 100644 > index 0000000000..b154dcc74e > --- /dev/null > +++ b/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > @@ -0,0 +1,46 @@ > +## @file > +# PEI support for SEV Secrets > +# > +# Copyright (C) 2020 James Bottomley, IBM Corporation. > +# > +# SPDX-License-Identifier: BSD-2-Clause-Patent > +# > +## > + > +[Defines] > + INF_VERSION = 0x00010005 > + BASE_NAME = SecretPei > + FILE_GUID = 45260dde-0c3c-4b41-a226-ef3803fac7d4 > + MODULE_TYPE = PEIM > + VERSION_STRING = 1.0 > + ENTRY_POINT = InitializeSecretPei > + > +# > +# The following information is for reference only and not required by the build tools. > +# > +# VALID_ARCHITECTURES = IA32 X64 EBC > +# (4) Please either drop VALID_ARCHITECTURES, or restrict it to X64 only. > + > +[Sources] > + SecretPei.c > + > +[Packages] > + OvmfPkg/OvmfPkg.dec > + MdePkg/MdePkg.dec > + MdeModulePkg/MdeModulePkg.dec (5) MdeModulePkg seems unnecessary > + > +[LibraryClasses] > + BaseLib > + DebugLib > + HobLib > + PeiServicesLib > + PeiServicesTablePointerLib > + PeimEntryPoint > + PcdLib (6) only HobLib, PcdLib, and PeimEntryPoint appear necessary > + > +[FixedPcd] > + gSevLaunchSecretGuid.PcdSevLaunchSecretBase > + gSevLaunchSecretGuid.PcdSevLaunchSecretSize > + > +[Depex] > + TRUE > diff --git a/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c b/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c > new file mode 100644 > index 0000000000..16b49792ad > --- /dev/null > +++ b/OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c > @@ -0,0 +1,26 @@ > +/** @file > + SEV Secret boot time HOB placement > + > + Copyright (C) 2020 James Bottomley, IBM Corporation. > + SPDX-License-Identifier: BSD-2-Clause-Patent > +**/ > +#include <PiPei.h> > +#include <Library/BaseLib.h> > +#include <Library/DebugLib.h> > +#include <Library/HobLib.h> > +#include <Library/PcdLib.h> (7) From Library/, only HobLib and PcdLib look required. After removing the other lib class headers, you may have to include <Uefi/UefiMultiPhase.h> separately, for EfiBootServicesData. > + > +EFI_STATUS > +EFIAPI > +InitializeSecretPei ( > + IN EFI_PEI_FILE_HANDLE FileHandle, > + IN CONST EFI_PEI_SERVICES **PeiServices > + ) > +{ > + BuildMemoryAllocationHob ( > + PcdGet32 (PcdSevLaunchSecretBase), > + PcdGet32 (PcdSevLaunchSecretSize), > + EfiBootServicesData); (8) Please break the closing paren to a new line: BuildMemoryAllocationHob ( PcdGet32 (PcdSevLaunchSecretBase), PcdGet32 (PcdSevLaunchSecretSize), EfiBootServicesData ); (Note that the indentation of the closing paren is not a mistake, it is intentional.) > + > + return EFI_SUCCESS; > +} > > diff --git a/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf b/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > new file mode 100644 > index 0000000000..085162e5c4 > --- /dev/null > +++ b/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > @@ -0,0 +1,38 @@ > +## @file > +# Sev Secret configuration Table installer > +# > +# Copyright (C) 2020 James Bottomley, IBM Corporation. > +# > +# SPDX-License-Identifier: BSD-2-Clause-Patent > +# > +## > + > +[Defines] > + INF_VERSION = 0x00010005 > + BASE_NAME = SecretDxe > + FILE_GUID = 6e2b9619-8810-4e9d-a177-d432bb9abeda > + MODULE_TYPE = DXE_DRIVER > + VERSION_STRING = 1.0 > + ENTRY_POINT = InitializeSecretDxe > + > +[Sources] > + SecretDxe.c > + > +[Packages] > + OvmfPkg/OvmfPkg.dec > + MdePkg/MdePkg.dec > + > +[LibraryClasses] > + UefiBootServicesTableLib > + UefiDriverEntryPoint > + UefiLib (9) UefiLib looks superfluous > + > +[Guids] > + gSevLaunchSecretGuid > + > +[FixedPcd] > + gSevLaunchSecretGuid.PcdSevLaunchSecretBase > + gSevLaunchSecretGuid.PcdSevLaunchSecretSize > + > +[Depex] > + TRUE > diff --git a/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c b/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c > new file mode 100644 > index 0000000000..b40bbe1eb9 > --- /dev/null > +++ b/OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c > @@ -0,0 +1,29 @@ > +/** @file > + SEV Secret configuration table constructor > + > + Copyright (C) 2020 James Bottomley, IBM Corporation. > + SPDX-License-Identifier: BSD-2-Clause-Patent > +**/ > +#include <PiDxe.h> > +#include <Library/UefiLib.h> (10) UefiLib looks superfluous. > +#include <Library/UefiDriverEntryPoint.h> (11) Entry point libraries must be listed in the INF files' [LibraryClasses] sections, but should not be #included in the C source files. > +#include <Library/UefiBootServicesTableLib.h> > + > +struct { > + UINT32 base; > + UINT32 size; > +} secretDxeTable = { > + FixedPcdGet32(PcdSevLaunchSecretBase), > + FixedPcdGet32(PcdSevLaunchSecretSize), > +}; > + (12) This is an interface between (theoretically) independent applications, so we should place the structure definition in a dedicated header file. (12.a) Please move the following hunk, from patch#3: > diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec > index 3fbf7a0ee1a4..b00f08341713 100644 > --- a/OvmfPkg/OvmfPkg.dec > +++ b/OvmfPkg/OvmfPkg.dec > @@ -117,6 +117,7 @@ [Guids] > gLinuxEfiInitrdMediaGuid = {0x5568e427, 0x68fc, 0x4f3d, {0xac, 0x74, 0xca, 0x55, 0x52, 0x31, 0xcc, 0x68}} > gQemuKernelLoaderFsMediaGuid = {0x1428f772, 0xb64a, 0x441e, {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}} > gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}} > + gSevLaunchSecretGuid = {0xadf956ad, 0xe98c, 0x484c, {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}} > > [Ppis] > # PPI whose presence in the PPI database signals that the TPM base address to patch#5 (i.e., the patch that's going to introduce SecretDxe). (12.b) In patch #5, please create another new header file: OvmfPkg/Include/Guid/SevLaunchSecret.h with the following contents (fix up the (C) notice): > /** @file > UEFI Configuration Table for exposing the SEV Launch Secret location to UEFI > applications (boot loaders). > > Copyright (C) <FIXME> > SPDX-License-Identifier: BSD-2-Clause-Patent > **/ > > #ifndef SEV_LAUNCH_SECRET_H_ > #define SEV_LAUNCH_SECRET_H_ > > #include <Uefi/UefiBaseType.h> > > #define SEV_LAUNCH_SECRET_GUID \ > { 0xadf956ad, \ > 0xe98c, \ > 0x484c, \ > { 0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47 }, \ > } > > typedef struct { > UINT32 Base; > UINT32 Size; > } SEV_LAUNCH_SECRET_LOCATION; > > extern EFI_GUID gSevLaunchSecretGuid; > > #endif // SEV_LAUNCH_SECRET_H_ (12.c) In the "SecretDxe.c" file, please use the following syntax, for defining the table: > #include <Guid/SevLaunchSecret.h> > > STATIC CONST SEV_LAUNCH_SECRET_LOCATION mSecretDxeTable = { > FixedPcdGet32 (PcdSevLaunchSecretBase), > FixedPcdGet32 (PcdSevLaunchSecretSize), > }; (12.d) Note the space character just after "FixedPcdGet32", and the "m" prefix in the global variable's name. Back to your patch: On 11/12/20 01:13, James Bottomley wrote: > +EFI_STATUS > +EFIAPI > +InitializeSecretDxe( > + IN EFI_HANDLE ImageHandle, > + IN EFI_SYSTEM_TABLE *SystemTable > + ) > +{ > + return gBS->InstallConfigurationTable (&gSevLaunchSecretGuid, > + &secretDxeTable); > +} (13) There are two styles to indent this idiomatically: (13.a) the official edk2 one: return gBS->InstallConfigurationTable ( &gSevLaunchSecretGuid, &mSecretDxeTable ); - each argument *and* the closing paren on a new line, - each argument *and* the closing paren indented 2 spaces relative to "InstallConfigurationTable" (not relative to "gBS") (13.b) or the "condensed" style: return gBS->InstallConfigurationTable (&gSevLaunchSecretGuid, &mSecretDxeTable); The only difference from (13.a) is that a new source line is only started when we'd exceed the recommended line length (80). Thanks, Laszlo ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 0:13 [PATCH 0/4] SEV Encrypted Boot for Ovmf James Bottomley ` (3 preceding siblings ...) 2020-11-12 0:13 ` [PATCH 4/4] OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table James Bottomley @ 2020-11-12 16:21 ` Ashish Kalra 2020-11-12 16:34 ` Dr. David Alan Gilbert 2020-11-12 17:32 ` Brijesh Singh ` (3 subsequent siblings) 8 siblings, 1 reply; 35+ messages in thread From: Ashish Kalra @ 2020-11-12 16:21 UTC (permalink / raw) To: James Bottomley Cc: devel, dovmurik, Dov.Murik1, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On Wed, Nov 11, 2020 at 04:13:12PM -0800, James Bottomley wrote: > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > This patch series is modelled on the structure of the Bhyve patches > for Ovmf, since it does somewhat similar things. This patch series > creates a separate build for an AmdSev OVMF.fd that does nothing > except combine with grub and boot straight through the internal grub > to try to mount an encrypted volume. > > Concept: SEV Secure Encrypted Images > ==================================== > > The SEV patches in Linux and OVMF allow for the booting of SEV VMs in > an encrypted state, but don't really show how this could be done with > an encrypted image. A basic question here ... the SEV usage model in which the firmware is encrypted and loaded into VM using LAUNCH_UPDATA_DATA and then measurement is provided and attestation is done with the VM owner and after VM owner verifies measurement, the VM owner encrypts the disk encryption key and sends it to the guest and it is injected into the guest using the LAUNCH_SECRET API, which is then used to decrypt the OS encrypted image, won't this work to start the SEV VM with an encrypted image ? Thanks, Ashish >Since the key used to decrypt the image must be > maintained within the SEV encryption envelope, encrypted QCOW is not > an option because the key would then have to be known to QEMU which is > outside the encryption envelope. The proposal here is that an > encrypted image should be a QCOW image consisting of two partitions, > the normal unencrypted EFI partition (Identifying it as an OVMF > bootable image) and a luks encrypted root partition. The kernel would > be inside the encrypted root in the /boot directory. The secret > injected securely through QEMU is extracted by OVMF and passed to grub > which uses it to mount the encrypted root and boot the kernel > normally. The creator of the secret bundle must be satisfied with the > SEV attestation before the secret is constructed. Unfortunately, the > SEV attestation can only be on the first QEMU firmware volume and > nothing else, so this patch series builds grub itself into a firmware > volume and places it inside OVMF so that the entire boot system can be > attested. In a normal OVMF KVM system, the variable store is on the > second flash volume (which is read/write). Unfortunately, this > mutable configuration provided by the variables is outside the > attestation envelope and can significantly alter the boot path, > possibly leading to secret leak, so encrypted image boot should only > be done with the OVMF.fd that combines both the code and variables. > the OVMF.fd is constructed so that it becomes impossible to interrupt > the boot sequence after attestation and the system will either boot > the image or fail. The boot sequence runs the grub.efi embedded in the > OVMF firmware volume so the encrypted image owner knows their own > version of grub is the only one that will boot before injecting the > secret. Note this boot path actually ignores the unencrypted EFI > partition. However, as part of this design, the encrypted image may be > booted by a standard OVMF KVM boot and in that case, the user will > have to type the encryption password. This standard boot will be > insecure but it might be used by the constructor of the encrypted > images on their own private laptop, for instance. The standard boot > path will use the unencrypted EFI partition. > > Patches Required Outside of OVMF > ================================ > > There is a patch set to grub which allows it to extract the SEV secret > area from the configuration table and use the secret as a password to > do a luks crypto mount of root (this is the sevsecret grub module). > > There is also a patch to qemu which allows it to search through the > OVMF.fd and find the SEV secret area which is now described inside the > Reset Vector using the existing SEV_ES reset block. This area is the > place QEMU will inject the encrypted SEV secret bundle. > > Security of the System > ====================== > > Since Grub is now part of the attested OVMF.fd bundle, the VM owner > knows absolutely that it will proceed straight to partition decryption > inside the attested code and boot the kernel off the encrypted > partition. Even if a different QCOW image is substituted, the boot > will fail without revealing the secret because the system is designed > to fail hard in that case and because the secret is always contained > within the encrypted envelope it should be impossible for the cloud > operator to obtain it even if they can pause the boot and examine the > machine memory. > > Putting it All Together > ======================= > > This is somewhat hard. You must first understand how to boot a QEMU > system so as to have the VM pause after firmware loading (-S option) > and use the qmp port to request an attestation. Only if the > attestation corresponds to the expected sha256sum of OVMF.fd should > the secret bundle be constructed and injected using qmp. The tools > for constructing the secret bundle are in > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fsev-tool%2F&data=04%7C01%7Cashish.kalra%40amd.com%7Ceb007b21e05c4e9c05cf08d8869fc874%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407368115912177%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TwcpYSl10ePPfomMIQQjjxcOufjlxkzDkR8H7BxKZtw%3D&reserved=0 > > James > > --- > > James Bottomley (4): > OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF > OvmfPkg/AmdSev: add Grub Firmware Volume Package > OvmfPkg: create a SEV secret area in the AmdSev memfd > OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table > > OvmfPkg/OvmfPkg.dec | 6 + > OvmfPkg/AmdSev/AmdSevX64.dsc | 1035 +++++++++++ > OvmfPkg/AmdSev/AmdSevX64.fdf | 515 ++++++ > OvmfPkg/AmdSev/Grub/Grub.inf | 37 + > .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 + > .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 + > .../PlatformBootManagerLibGrub.inf | 84 + > OvmfPkg/ResetVector/ResetVector.inf | 4 + > .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++ > .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 + > .../SevLaunchSecret/SecretPei/SecretPei.c | 26 + > .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++ > .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++ > OvmfPkg/AmdSev/Grub/.gitignore | 1 + > OvmfPkg/AmdSev/Grub/grub.cfg | 35 + > OvmfPkg/AmdSev/Grub/grub.sh | 54 + > OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 + > OvmfPkg/ResetVector/ResetVector.nasmb | 2 + > 18 files changed, 3846 insertions(+) > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf > create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c > create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore > create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg > create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh > > -- > 2.26.2 > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 16:21 ` [PATCH 0/4] SEV Encrypted Boot for Ovmf Ashish Kalra @ 2020-11-12 16:34 ` Dr. David Alan Gilbert 2020-11-12 17:07 ` James Bottomley 0 siblings, 1 reply; 35+ messages in thread From: Dr. David Alan Gilbert @ 2020-11-12 16:34 UTC (permalink / raw) To: Ashish Kalra Cc: James Bottomley, devel, dovmurik, Dov.Murik1, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh * Ashish Kalra (ashish.kalra@amd.com) wrote: > On Wed, Nov 11, 2020 at 04:13:12PM -0800, James Bottomley wrote: > > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > > > This patch series is modelled on the structure of the Bhyve patches > > for Ovmf, since it does somewhat similar things. This patch series > > creates a separate build for an AmdSev OVMF.fd that does nothing > > except combine with grub and boot straight through the internal grub > > to try to mount an encrypted volume. > > > > Concept: SEV Secure Encrypted Images > > ==================================== > > > > The SEV patches in Linux and OVMF allow for the booting of SEV VMs in > > an encrypted state, but don't really show how this could be done with > > an encrypted image. > > A basic question here ... the SEV usage model in which the firmware is > encrypted and loaded into VM using LAUNCH_UPDATA_DATA and then > measurement is provided and attestation is done with the VM owner and > after VM owner verifies measurement, the VM owner encrypts the disk > encryption key and sends it to the guest and it is injected into the > guest using the LAUNCH_SECRET API, which is then used to decrypt the > OS encrypted image, won't this work to start the SEV VM > with an encrypted image ? That's still what James system does, but the problem is maintaining a chain of trust from the set of measured binaries to the point at which you can use the injected secret. On the current OVMF world we end up measuring the OVMF binary, but not the stored variable flash; but then what? Who would read the injected secret? Because SEV/SEV-ES has no way of performing a later attestation, or updating the measurements, we have no way of following the path from OVMF (possibly via variables) to a boot loader, to a filesystem. Dave > Thanks, > Ashish > > >Since the key used to decrypt the image must be > > maintained within the SEV encryption envelope, encrypted QCOW is not > > an option because the key would then have to be known to QEMU which is > > outside the encryption envelope. The proposal here is that an > > encrypted image should be a QCOW image consisting of two partitions, > > the normal unencrypted EFI partition (Identifying it as an OVMF > > bootable image) and a luks encrypted root partition. The kernel would > > be inside the encrypted root in the /boot directory. The secret > > injected securely through QEMU is extracted by OVMF and passed to grub > > which uses it to mount the encrypted root and boot the kernel > > normally. The creator of the secret bundle must be satisfied with the > > SEV attestation before the secret is constructed. Unfortunately, the > > SEV attestation can only be on the first QEMU firmware volume and > > nothing else, so this patch series builds grub itself into a firmware > > volume and places it inside OVMF so that the entire boot system can be > > attested. In a normal OVMF KVM system, the variable store is on the > > second flash volume (which is read/write). Unfortunately, this > > mutable configuration provided by the variables is outside the > > attestation envelope and can significantly alter the boot path, > > possibly leading to secret leak, so encrypted image boot should only > > be done with the OVMF.fd that combines both the code and variables. > > the OVMF.fd is constructed so that it becomes impossible to interrupt > > the boot sequence after attestation and the system will either boot > > the image or fail. The boot sequence runs the grub.efi embedded in the > > OVMF firmware volume so the encrypted image owner knows their own > > version of grub is the only one that will boot before injecting the > > secret. Note this boot path actually ignores the unencrypted EFI > > partition. However, as part of this design, the encrypted image may be > > booted by a standard OVMF KVM boot and in that case, the user will > > have to type the encryption password. This standard boot will be > > insecure but it might be used by the constructor of the encrypted > > images on their own private laptop, for instance. The standard boot > > path will use the unencrypted EFI partition. > > > > Patches Required Outside of OVMF > > ================================ > > > > There is a patch set to grub which allows it to extract the SEV secret > > area from the configuration table and use the secret as a password to > > do a luks crypto mount of root (this is the sevsecret grub module). > > > > There is also a patch to qemu which allows it to search through the > > OVMF.fd and find the SEV secret area which is now described inside the > > Reset Vector using the existing SEV_ES reset block. This area is the > > place QEMU will inject the encrypted SEV secret bundle. > > > > Security of the System > > ====================== > > > > Since Grub is now part of the attested OVMF.fd bundle, the VM owner > > knows absolutely that it will proceed straight to partition decryption > > inside the attested code and boot the kernel off the encrypted > > partition. Even if a different QCOW image is substituted, the boot > > will fail without revealing the secret because the system is designed > > to fail hard in that case and because the secret is always contained > > within the encrypted envelope it should be impossible for the cloud > > operator to obtain it even if they can pause the boot and examine the > > machine memory. > > > > Putting it All Together > > ======================= > > > > This is somewhat hard. You must first understand how to boot a QEMU > > system so as to have the VM pause after firmware loading (-S option) > > and use the qmp port to request an attestation. Only if the > > attestation corresponds to the expected sha256sum of OVMF.fd should > > the secret bundle be constructed and injected using qmp. The tools > > for constructing the secret bundle are in > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fsev-tool%2F&data=04%7C01%7Cashish.kalra%40amd.com%7Ceb007b21e05c4e9c05cf08d8869fc874%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407368115912177%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TwcpYSl10ePPfomMIQQjjxcOufjlxkzDkR8H7BxKZtw%3D&reserved=0 > > > > James > > > > --- > > > > James Bottomley (4): > > OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF > > OvmfPkg/AmdSev: add Grub Firmware Volume Package > > OvmfPkg: create a SEV secret area in the AmdSev memfd > > OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table > > > > OvmfPkg/OvmfPkg.dec | 6 + > > OvmfPkg/AmdSev/AmdSevX64.dsc | 1035 +++++++++++ > > OvmfPkg/AmdSev/AmdSevX64.fdf | 515 ++++++ > > OvmfPkg/AmdSev/Grub/Grub.inf | 37 + > > .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 + > > .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 + > > .../PlatformBootManagerLibGrub.inf | 84 + > > OvmfPkg/ResetVector/ResetVector.inf | 4 + > > .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++ > > .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 + > > .../SevLaunchSecret/SecretPei/SecretPei.c | 26 + > > .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++ > > .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++ > > OvmfPkg/AmdSev/Grub/.gitignore | 1 + > > OvmfPkg/AmdSev/Grub/grub.cfg | 35 + > > OvmfPkg/AmdSev/Grub/grub.sh | 54 + > > OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 + > > OvmfPkg/ResetVector/ResetVector.nasmb | 2 + > > 18 files changed, 3846 insertions(+) > > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc > > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf > > create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c > > create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore > > create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg > > create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh > > > > -- > > 2.26.2 > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 16:34 ` Dr. David Alan Gilbert @ 2020-11-12 17:07 ` James Bottomley 2020-11-12 17:22 ` Ashish Kalra 0 siblings, 1 reply; 35+ messages in thread From: James Bottomley @ 2020-11-12 17:07 UTC (permalink / raw) To: Dr. David Alan Gilbert, Ashish Kalra Cc: devel, dovmurik, Dov.Murik1, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh On Thu, 2020-11-12 at 16:34 +0000, Dr. David Alan Gilbert wrote: > * Ashish Kalra (ashish.kalra@amd.com) wrote: > > On Wed, Nov 11, 2020 at 04:13:12PM -0800, James Bottomley wrote: > > > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > > > > > This patch series is modelled on the structure of the Bhyve > > > patches for Ovmf, since it does somewhat similar things. This > > > patch series creates a separate build for an AmdSev OVMF.fd that > > > does nothing except combine with grub and boot straight through > > > the internal grub to try to mount an encrypted volume. > > > > > > Concept: SEV Secure Encrypted Images > > > ==================================== > > > > > > The SEV patches in Linux and OVMF allow for the booting of SEV > > > VMs in an encrypted state, but don't really show how this could > > > be done with an encrypted image. > > > > A basic question here ... the SEV usage model in which the firmware > > is encrypted and loaded into VM using LAUNCH_UPDATA_DATA and then > > measurement is provided and attestation is done with the VM owner > > and after VM owner verifies measurement, the VM owner encrypts the > > disk encryption key and sends it to the guest and it is injected > > into the guest using the LAUNCH_SECRET API, which is then used to > > decrypt the OS encrypted image, won't this work to start the SEV VM > > with an encrypted image ? > > That's still what James system does, but the problem is maintaining a > chain of trust from the set of measured binaries to the point at > which you can use the injected secret. > > On the current OVMF world we end up measuring the OVMF binary, but > not the stored variable flash; but then what? Who would read the > injected secret? Because SEV/SEV-ES has no way of performing a later > attestation, or updating the measurements, we have no way of > following the path from OVMF (possibly via variables) to a boot > loader, to a filesystem. Right, the specific problem is our current linux boot sequence goes OVMF->grub->linux But OVMF can only execute things on an unencrypted vFAT filesytem, so if grub is on vFAT there's no way to prevent a cloud admin substituting the grub binary after attestation is done and the key released if we only attest OVMF, so the bogus grub binary could simply capture the key and transmit it to a hacker. Pulling grub inside OVMF allows us to attest both OVMF and grub as one entity and also prevents the boot going via the unencrypted vFAT filesystem, eliminating the potential interception point. James ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 17:07 ` James Bottomley @ 2020-11-12 17:22 ` Ashish Kalra 0 siblings, 0 replies; 35+ messages in thread From: Ashish Kalra @ 2020-11-12 17:22 UTC (permalink / raw) To: James Bottomley Cc: Dr. David Alan Gilbert, devel, dovmurik, Dov.Murik1, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh On Thu, Nov 12, 2020 at 09:07:11AM -0800, James Bottomley wrote: > On Thu, 2020-11-12 at 16:34 +0000, Dr. David Alan Gilbert wrote: > > * Ashish Kalra (ashish.kalra@amd.com) wrote: > > > On Wed, Nov 11, 2020 at 04:13:12PM -0800, James Bottomley wrote: > > > > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > > > > > > > This patch series is modelled on the structure of the Bhyve > > > > patches for Ovmf, since it does somewhat similar things. This > > > > patch series creates a separate build for an AmdSev OVMF.fd that > > > > does nothing except combine with grub and boot straight through > > > > the internal grub to try to mount an encrypted volume. > > > > > > > > Concept: SEV Secure Encrypted Images > > > > ==================================== > > > > > > > > The SEV patches in Linux and OVMF allow for the booting of SEV > > > > VMs in an encrypted state, but don't really show how this could > > > > be done with an encrypted image. > > > > > > A basic question here ... the SEV usage model in which the firmware > > > is encrypted and loaded into VM using LAUNCH_UPDATA_DATA and then > > > measurement is provided and attestation is done with the VM owner > > > and after VM owner verifies measurement, the VM owner encrypts the > > > disk encryption key and sends it to the guest and it is injected > > > into the guest using the LAUNCH_SECRET API, which is then used to > > > decrypt the OS encrypted image, won't this work to start the SEV VM > > > with an encrypted image ? > > > > That's still what James system does, but the problem is maintaining a > > chain of trust from the set of measured binaries to the point at > > which you can use the injected secret. > > > > On the current OVMF world we end up measuring the OVMF binary, but > > not the stored variable flash; but then what? Who would read the > > injected secret? Because SEV/SEV-ES has no way of performing a later > > attestation, or updating the measurements, we have no way of > > following the path from OVMF (possibly via variables) to a boot > > loader, to a filesystem. > > Right, the specific problem is our current linux boot sequence goes > > OVMF->grub->linux > > But OVMF can only execute things on an unencrypted vFAT filesytem, so > if grub is on vFAT there's no way to prevent a cloud admin substituting > the grub binary after attestation is done and the key released if we > only attest OVMF, so the bogus grub binary could simply capture the key > and transmit it to a hacker. > > Pulling grub inside OVMF allows us to attest both OVMF and grub as one > entity and also prevents the boot going via the unencrypted vFAT > filesystem, eliminating the potential interception point. > > James > > Thanks James and Dave for the detailed explanations, i get the picture. Also after discussion with Brijesh, i understand that this is fixing a known gap in the SEV s/w stack. Ashish ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 0:13 [PATCH 0/4] SEV Encrypted Boot for Ovmf James Bottomley ` (4 preceding siblings ...) 2020-11-12 16:21 ` [PATCH 0/4] SEV Encrypted Boot for Ovmf Ashish Kalra @ 2020-11-12 17:32 ` Brijesh Singh 2020-11-12 19:38 ` Dr. David Alan Gilbert 2020-11-12 19:44 ` James Bottomley 2020-11-13 2:04 ` [edk2-devel] " James Bottomley ` (2 subsequent siblings) 8 siblings, 2 replies; 35+ messages in thread From: Brijesh Singh @ 2020-11-12 17:32 UTC (permalink / raw) To: James Bottomley, devel Cc: brijesh.singh, dovmurik, Dov.Murik1, ashish.kalra, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert Hi James, Thanks for series, I glanced at it, the changes looks okay to me. I have one questions. How does the grub locate the disk decryption key ? Am I correct in assuming that the gurb is iterating through a configuration table entries and comparing the Secret GUID to locate the secret key. As per the SEV spec, its possible that a guest owner can call the secret injection more than once. I don't see the patch consider that case, should we support this or limit to one inject? Maybe Qemu can enforce this property. Do you see any need for the Linux kernel needing to access the secret? Since the secret blob is available through configuration table, I believe we can have a platform driver that can read the configuration table and retrieve the secret blob. thanks On 11/11/20 6:13 PM, James Bottomley wrote: > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > This patch series is modelled on the structure of the Bhyve patches > for Ovmf, since it does somewhat similar things. This patch series > creates a separate build for an AmdSev OVMF.fd that does nothing > except combine with grub and boot straight through the internal grub > to try to mount an encrypted volume. > > Concept: SEV Secure Encrypted Images > ==================================== > > The SEV patches in Linux and OVMF allow for the booting of SEV VMs in > an encrypted state, but don't really show how this could be done with > an encrypted image. Since the key used to decrypt the image must be > maintained within the SEV encryption envelope, encrypted QCOW is not > an option because the key would then have to be known to QEMU which is > outside the encryption envelope. The proposal here is that an > encrypted image should be a QCOW image consisting of two partitions, > the normal unencrypted EFI partition (Identifying it as an OVMF > bootable image) and a luks encrypted root partition. The kernel would > be inside the encrypted root in the /boot directory. The secret > injected securely through QEMU is extracted by OVMF and passed to grub > which uses it to mount the encrypted root and boot the kernel > normally. The creator of the secret bundle must be satisfied with the > SEV attestation before the secret is constructed. Unfortunately, the > SEV attestation can only be on the first QEMU firmware volume and > nothing else, so this patch series builds grub itself into a firmware > volume and places it inside OVMF so that the entire boot system can be > attested. In a normal OVMF KVM system, the variable store is on the > second flash volume (which is read/write). Unfortunately, this > mutable configuration provided by the variables is outside the > attestation envelope and can significantly alter the boot path, > possibly leading to secret leak, so encrypted image boot should only > be done with the OVMF.fd that combines both the code and variables. > the OVMF.fd is constructed so that it becomes impossible to interrupt > the boot sequence after attestation and the system will either boot > the image or fail. The boot sequence runs the grub.efi embedded in the > OVMF firmware volume so the encrypted image owner knows their own > version of grub is the only one that will boot before injecting the > secret. Note this boot path actually ignores the unencrypted EFI > partition. However, as part of this design, the encrypted image may be > booted by a standard OVMF KVM boot and in that case, the user will > have to type the encryption password. This standard boot will be > insecure but it might be used by the constructor of the encrypted > images on their own private laptop, for instance. The standard boot > path will use the unencrypted EFI partition. > > Patches Required Outside of OVMF > ================================ > > There is a patch set to grub which allows it to extract the SEV secret > area from the configuration table and use the secret as a password to > do a luks crypto mount of root (this is the sevsecret grub module). > > There is also a patch to qemu which allows it to search through the > OVMF.fd and find the SEV secret area which is now described inside the > Reset Vector using the existing SEV_ES reset block. This area is the > place QEMU will inject the encrypted SEV secret bundle. > > Security of the System > ====================== > > Since Grub is now part of the attested OVMF.fd bundle, the VM owner > knows absolutely that it will proceed straight to partition decryption > inside the attested code and boot the kernel off the encrypted > partition. Even if a different QCOW image is substituted, the boot > will fail without revealing the secret because the system is designed > to fail hard in that case and because the secret is always contained > within the encrypted envelope it should be impossible for the cloud > operator to obtain it even if they can pause the boot and examine the > machine memory. > > Putting it All Together > ======================= > > This is somewhat hard. You must first understand how to boot a QEMU > system so as to have the VM pause after firmware loading (-S option) > and use the qmp port to request an attestation. Only if the > attestation corresponds to the expected sha256sum of OVMF.fd should > the secret bundle be constructed and injected using qmp. The tools > for constructing the secret bundle are in > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fsev-tool%2F&data=04%7C01%7Cbrijesh.singh%40amd.com%7Ceb007b21e05c4e9c05cf08d8869fc874%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407368116062086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BbCtv37bH0%2B6JDLM3afAubVN6K0Y%2FdO4TRz4ZkP1AKg%3D&reserved=0 Where you able to use the sev-tool as-is to generate a secret blob that can be injected through the Qemu QMP interface? The reason why I am asking this is because the last time when I looked at the sev-tool I found that it did not generated the blob which was in the correct format. > > James > > --- > > James Bottomley (4): > OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF > OvmfPkg/AmdSev: add Grub Firmware Volume Package > OvmfPkg: create a SEV secret area in the AmdSev memfd > OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table > > OvmfPkg/OvmfPkg.dec | 6 + > OvmfPkg/AmdSev/AmdSevX64.dsc | 1035 +++++++++++ > OvmfPkg/AmdSev/AmdSevX64.fdf | 515 ++++++ > OvmfPkg/AmdSev/Grub/Grub.inf | 37 + > .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 + > .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 + > .../PlatformBootManagerLibGrub.inf | 84 + > OvmfPkg/ResetVector/ResetVector.inf | 4 + > .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++ > .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 + > .../SevLaunchSecret/SecretPei/SecretPei.c | 26 + > .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++ > .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++ > OvmfPkg/AmdSev/Grub/.gitignore | 1 + > OvmfPkg/AmdSev/Grub/grub.cfg | 35 + > OvmfPkg/AmdSev/Grub/grub.sh | 54 + > OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 + > OvmfPkg/ResetVector/ResetVector.nasmb | 2 + > 18 files changed, 3846 insertions(+) > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf > create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c > create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore > create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg > create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 17:32 ` Brijesh Singh @ 2020-11-12 19:38 ` Dr. David Alan Gilbert 2020-11-12 21:56 ` Brijesh Singh 2020-11-12 19:44 ` James Bottomley 1 sibling, 1 reply; 35+ messages in thread From: Dr. David Alan Gilbert @ 2020-11-12 19:38 UTC (permalink / raw) To: Brijesh Singh Cc: James Bottomley, devel, dovmurik, Dov.Murik1, ashish.kalra, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh * Brijesh Singh (brijesh.singh@amd.com) wrote: > Hi James, > > Thanks for series, I glanced at it, the changes looks okay to me. I have > one questions. > > How does the grub locate the disk decryption key ? Am I correct in > assuming that the gurb is iterating through a configuration table > entries and comparing the Secret GUID to locate the secret key. As per > the SEV spec, its possible that a guest owner can call the secret > injection more than once. I don't see the patch consider that case, > should we support this or limit to one inject? Maybe Qemu can enforce > this property. That's interesting, I hadn't realised that was possible - however, I can't see a way to use it - for it to be useful, you would have to have a way for the guest to communicate to the owner that it had finished with the first injection and would like the next; but if you already have a way to communicate from the guest to the owner to request stuff, then you could pass a new secret by that comms route? > Do you see any need for the Linux kernel needing to access the secret? > Since the secret blob is available through configuration table, I > believe we can have a platform driver that can read the configuration > table and retrieve the secret blob. I guess it depends if you get the Grub to pass the fs secret down to the kernel or let it pick it up itself from the same place. Dave > > thanks > > On 11/11/20 6:13 PM, James Bottomley wrote: > > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > > > This patch series is modelled on the structure of the Bhyve patches > > for Ovmf, since it does somewhat similar things. This patch series > > creates a separate build for an AmdSev OVMF.fd that does nothing > > except combine with grub and boot straight through the internal grub > > to try to mount an encrypted volume. > > > > Concept: SEV Secure Encrypted Images > > ==================================== > > > > The SEV patches in Linux and OVMF allow for the booting of SEV VMs in > > an encrypted state, but don't really show how this could be done with > > an encrypted image. Since the key used to decrypt the image must be > > maintained within the SEV encryption envelope, encrypted QCOW is not > > an option because the key would then have to be known to QEMU which is > > outside the encryption envelope. The proposal here is that an > > encrypted image should be a QCOW image consisting of two partitions, > > the normal unencrypted EFI partition (Identifying it as an OVMF > > bootable image) and a luks encrypted root partition. The kernel would > > be inside the encrypted root in the /boot directory. The secret > > injected securely through QEMU is extracted by OVMF and passed to grub > > which uses it to mount the encrypted root and boot the kernel > > normally. The creator of the secret bundle must be satisfied with the > > SEV attestation before the secret is constructed. Unfortunately, the > > SEV attestation can only be on the first QEMU firmware volume and > > nothing else, so this patch series builds grub itself into a firmware > > volume and places it inside OVMF so that the entire boot system can be > > attested. In a normal OVMF KVM system, the variable store is on the > > second flash volume (which is read/write). Unfortunately, this > > mutable configuration provided by the variables is outside the > > attestation envelope and can significantly alter the boot path, > > possibly leading to secret leak, so encrypted image boot should only > > be done with the OVMF.fd that combines both the code and variables. > > the OVMF.fd is constructed so that it becomes impossible to interrupt > > the boot sequence after attestation and the system will either boot > > the image or fail. The boot sequence runs the grub.efi embedded in the > > OVMF firmware volume so the encrypted image owner knows their own > > version of grub is the only one that will boot before injecting the > > secret. Note this boot path actually ignores the unencrypted EFI > > partition. However, as part of this design, the encrypted image may be > > booted by a standard OVMF KVM boot and in that case, the user will > > have to type the encryption password. This standard boot will be > > insecure but it might be used by the constructor of the encrypted > > images on their own private laptop, for instance. The standard boot > > path will use the unencrypted EFI partition. > > > > Patches Required Outside of OVMF > > ================================ > > > > There is a patch set to grub which allows it to extract the SEV secret > > area from the configuration table and use the secret as a password to > > do a luks crypto mount of root (this is the sevsecret grub module). > > > > There is also a patch to qemu which allows it to search through the > > OVMF.fd and find the SEV secret area which is now described inside the > > Reset Vector using the existing SEV_ES reset block. This area is the > > place QEMU will inject the encrypted SEV secret bundle. > > > > Security of the System > > ====================== > > > > Since Grub is now part of the attested OVMF.fd bundle, the VM owner > > knows absolutely that it will proceed straight to partition decryption > > inside the attested code and boot the kernel off the encrypted > > partition. Even if a different QCOW image is substituted, the boot > > will fail without revealing the secret because the system is designed > > to fail hard in that case and because the secret is always contained > > within the encrypted envelope it should be impossible for the cloud > > operator to obtain it even if they can pause the boot and examine the > > machine memory. > > > > Putting it All Together > > ======================= > > > > This is somewhat hard. You must first understand how to boot a QEMU > > system so as to have the VM pause after firmware loading (-S option) > > and use the qmp port to request an attestation. Only if the > > attestation corresponds to the expected sha256sum of OVMF.fd should > > the secret bundle be constructed and injected using qmp. The tools > > for constructing the secret bundle are in > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fsev-tool%2F&data=04%7C01%7Cbrijesh.singh%40amd.com%7Ceb007b21e05c4e9c05cf08d8869fc874%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407368116062086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BbCtv37bH0%2B6JDLM3afAubVN6K0Y%2FdO4TRz4ZkP1AKg%3D&reserved=0 > > > Where you able to use the sev-tool as-is to generate a secret blob that > can be injected through the Qemu QMP interface? The reason why I am > asking this is because the last time when I looked at the sev-tool I > found that it did not generated the blob which was in the correct format. > > > > > > James > > > > --- > > > > James Bottomley (4): > > OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF > > OvmfPkg/AmdSev: add Grub Firmware Volume Package > > OvmfPkg: create a SEV secret area in the AmdSev memfd > > OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table > > > > OvmfPkg/OvmfPkg.dec | 6 + > > OvmfPkg/AmdSev/AmdSevX64.dsc | 1035 +++++++++++ > > OvmfPkg/AmdSev/AmdSevX64.fdf | 515 ++++++ > > OvmfPkg/AmdSev/Grub/Grub.inf | 37 + > > .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 + > > .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 + > > .../PlatformBootManagerLibGrub.inf | 84 + > > OvmfPkg/ResetVector/ResetVector.inf | 4 + > > .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++ > > .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 + > > .../SevLaunchSecret/SecretPei/SecretPei.c | 26 + > > .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++ > > .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++ > > OvmfPkg/AmdSev/Grub/.gitignore | 1 + > > OvmfPkg/AmdSev/Grub/grub.cfg | 35 + > > OvmfPkg/AmdSev/Grub/grub.sh | 54 + > > OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 + > > OvmfPkg/ResetVector/ResetVector.nasmb | 2 + > > 18 files changed, 3846 insertions(+) > > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc > > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf > > create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c > > create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore > > create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg > > create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 19:38 ` Dr. David Alan Gilbert @ 2020-11-12 21:56 ` Brijesh Singh 2020-11-12 22:50 ` James Bottomley 0 siblings, 1 reply; 35+ messages in thread From: Brijesh Singh @ 2020-11-12 21:56 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: brijesh.singh, James Bottomley, devel, dovmurik, Dov.Murik1, ashish.kalra, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh On 11/12/20 1:38 PM, Dr. David Alan Gilbert wrote: > * Brijesh Singh (brijesh.singh@amd.com) wrote: >> Hi James, >> >> Thanks for series, I glanced at it, the changes looks okay to me. I have >> one questions. >> >> How does the grub locate the disk decryption key ? Am I correct in >> assuming that the gurb is iterating through a configuration table >> entries and comparing the Secret GUID to locate the secret key. As per >> the SEV spec, its possible that a guest owner can call the secret >> injection more than once. I don't see the patch consider that case, >> should we support this or limit to one inject? Maybe Qemu can enforce >> this property. > That's interesting, I hadn't realised that was possible - however, > I can't see a way to use it - for it to be useful, you would have to > have a way for the guest to communicate to the owner that it had > finished with the first injection and would like the next; but if you > already have a way to communicate from the guest to the owner to request > stuff, then you could pass a new secret by that comms route? The main reason for its existence was to allow guest owner to inject multiple blocks of the data if they need to do so, e.g IIRC, Enarx folks use this to inject the keep which is much bigger than 128K. I am not sure if we really need it for the VM boot flow but we probably need to define the secret page layout such that it contains multiple entries in it. In our case the Secret can't be more than a page, so, we can define a secret page layout such that it can contain more than one disk key. I was thinking about something like this typedef enum { DISK_KEY_AES_128, SSH_PRIVATE_KEY, ... } data_type; struct secret_data { u8 entries; struct { data_type type; u16 len; u8 name[16]; u8 data[]; } entry[]; } This should allow us to package multiple secrets in one inject. > >> Do you see any need for the Linux kernel needing to access the secret? >> Since the secret blob is available through configuration table, I >> believe we can have a platform driver that can read the configuration >> table and retrieve the secret blob. > I guess it depends if you get the Grub to pass the fs secret down to the > kernel or let it pick it up itself from the same place. I guess the main reason why I was asking this is, what if guest owner provides more than one disk keys in the secret injection blob. Grub can use the boot disk key to access the Linux images and other disk keys may later be used by Linux. > Dave > >> thanks >> >> On 11/11/20 6:13 PM, James Bottomley wrote: >>> From: James Bottomley <James.Bottomley@HansenPartnership.com> >>> >>> This patch series is modelled on the structure of the Bhyve patches >>> for Ovmf, since it does somewhat similar things. This patch series >>> creates a separate build for an AmdSev OVMF.fd that does nothing >>> except combine with grub and boot straight through the internal grub >>> to try to mount an encrypted volume. >>> >>> Concept: SEV Secure Encrypted Images >>> ==================================== >>> >>> The SEV patches in Linux and OVMF allow for the booting of SEV VMs in >>> an encrypted state, but don't really show how this could be done with >>> an encrypted image. Since the key used to decrypt the image must be >>> maintained within the SEV encryption envelope, encrypted QCOW is not >>> an option because the key would then have to be known to QEMU which is >>> outside the encryption envelope. The proposal here is that an >>> encrypted image should be a QCOW image consisting of two partitions, >>> the normal unencrypted EFI partition (Identifying it as an OVMF >>> bootable image) and a luks encrypted root partition. The kernel would >>> be inside the encrypted root in the /boot directory. The secret >>> injected securely through QEMU is extracted by OVMF and passed to grub >>> which uses it to mount the encrypted root and boot the kernel >>> normally. The creator of the secret bundle must be satisfied with the >>> SEV attestation before the secret is constructed. Unfortunately, the >>> SEV attestation can only be on the first QEMU firmware volume and >>> nothing else, so this patch series builds grub itself into a firmware >>> volume and places it inside OVMF so that the entire boot system can be >>> attested. In a normal OVMF KVM system, the variable store is on the >>> second flash volume (which is read/write). Unfortunately, this >>> mutable configuration provided by the variables is outside the >>> attestation envelope and can significantly alter the boot path, >>> possibly leading to secret leak, so encrypted image boot should only >>> be done with the OVMF.fd that combines both the code and variables. >>> the OVMF.fd is constructed so that it becomes impossible to interrupt >>> the boot sequence after attestation and the system will either boot >>> the image or fail. The boot sequence runs the grub.efi embedded in the >>> OVMF firmware volume so the encrypted image owner knows their own >>> version of grub is the only one that will boot before injecting the >>> secret. Note this boot path actually ignores the unencrypted EFI >>> partition. However, as part of this design, the encrypted image may be >>> booted by a standard OVMF KVM boot and in that case, the user will >>> have to type the encryption password. This standard boot will be >>> insecure but it might be used by the constructor of the encrypted >>> images on their own private laptop, for instance. The standard boot >>> path will use the unencrypted EFI partition. >>> >>> Patches Required Outside of OVMF >>> ================================ >>> >>> There is a patch set to grub which allows it to extract the SEV secret >>> area from the configuration table and use the secret as a password to >>> do a luks crypto mount of root (this is the sevsecret grub module). >>> >>> There is also a patch to qemu which allows it to search through the >>> OVMF.fd and find the SEV secret area which is now described inside the >>> Reset Vector using the existing SEV_ES reset block. This area is the >>> place QEMU will inject the encrypted SEV secret bundle. >>> >>> Security of the System >>> ====================== >>> >>> Since Grub is now part of the attested OVMF.fd bundle, the VM owner >>> knows absolutely that it will proceed straight to partition decryption >>> inside the attested code and boot the kernel off the encrypted >>> partition. Even if a different QCOW image is substituted, the boot >>> will fail without revealing the secret because the system is designed >>> to fail hard in that case and because the secret is always contained >>> within the encrypted envelope it should be impossible for the cloud >>> operator to obtain it even if they can pause the boot and examine the >>> machine memory. >>> >>> Putting it All Together >>> ======================= >>> >>> This is somewhat hard. You must first understand how to boot a QEMU >>> system so as to have the VM pause after firmware loading (-S option) >>> and use the qmp port to request an attestation. Only if the >>> attestation corresponds to the expected sha256sum of OVMF.fd should >>> the secret bundle be constructed and injected using qmp. The tools >>> for constructing the secret bundle are in >>> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fsev-tool%2F&data=04%7C01%7Cbrijesh.singh%40amd.com%7Cc5b99bba03c74eb5bc2308d887428054%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637408066981024287%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SSmQZgDWx4P5a2hOJZRnhrM0n5ExpqzjLGolv0f0CC8%3D&reserved=0 >> >> Where you able to use the sev-tool as-is to generate a secret blob that >> can be injected through the Qemu QMP interface? The reason why I am >> asking this is because the last time when I looked at the sev-tool I >> found that it did not generated the blob which was in the correct format. >> >> >>> James >>> >>> --- >>> >>> James Bottomley (4): >>> OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF >>> OvmfPkg/AmdSev: add Grub Firmware Volume Package >>> OvmfPkg: create a SEV secret area in the AmdSev memfd >>> OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table >>> >>> OvmfPkg/OvmfPkg.dec | 6 + >>> OvmfPkg/AmdSev/AmdSevX64.dsc | 1035 +++++++++++ >>> OvmfPkg/AmdSev/AmdSevX64.fdf | 515 ++++++ >>> OvmfPkg/AmdSev/Grub/Grub.inf | 37 + >>> .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 + >>> .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 + >>> .../PlatformBootManagerLibGrub.inf | 84 + >>> OvmfPkg/ResetVector/ResetVector.inf | 4 + >>> .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++ >>> .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 + >>> .../SevLaunchSecret/SecretPei/SecretPei.c | 26 + >>> .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++ >>> .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++ >>> OvmfPkg/AmdSev/Grub/.gitignore | 1 + >>> OvmfPkg/AmdSev/Grub/grub.cfg | 35 + >>> OvmfPkg/AmdSev/Grub/grub.sh | 54 + >>> OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 + >>> OvmfPkg/ResetVector/ResetVector.nasmb | 2 + >>> 18 files changed, 3846 insertions(+) >>> create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc >>> create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf >>> create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf >>> create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf >>> create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf >>> create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf >>> create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h >>> create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c >>> create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c >>> create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c >>> create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c >>> create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore >>> create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg >>> create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh >>> ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 21:56 ` Brijesh Singh @ 2020-11-12 22:50 ` James Bottomley 2020-11-15 14:08 ` Brijesh Singh 0 siblings, 1 reply; 35+ messages in thread From: James Bottomley @ 2020-11-12 22:50 UTC (permalink / raw) To: Brijesh Singh, Dr. David Alan Gilbert Cc: devel, dovmurik, Dov.Murik1, ashish.kalra, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh On Thu, 2020-11-12 at 15:56 -0600, Brijesh Singh wrote: > On 11/12/20 1:38 PM, Dr. David Alan Gilbert wrote: > > * Brijesh Singh (brijesh.singh@amd.com) wrote: > > > Hi James, > > > > > > Thanks for series, I glanced at it, the changes looks okay to me. > > > I have one questions. > > > > > > How does the grub locate the disk decryption key ? Am I correct > > > in assuming that the gurb is iterating through a configuration > > > table entries and comparing the Secret GUID to locate the secret > > > key. As per the SEV spec, its possible that a guest owner can > > > call the secret injection more than once. I don't see the patch > > > consider that case, should we support this or limit to one > > > inject? Maybe Qemu can enforce this property. > > That's interesting, I hadn't realised that was possible - however, > > I can't see a way to use it - for it to be useful, you would have > > to have a way for the guest to communicate to the owner that it had > > finished with the first injection and would like the next; but if > > you already have a way to communicate from the guest to the owner > > to request stuff, then you could pass a new secret by that comms > > route? > > The main reason for its existence was to allow guest owner to inject > multiple blocks of the data if they need to do so, e.g IIRC, Enarx > folks use this to inject the keep which is much bigger than 128K. In some ways this sounds like the wrong approach. I mean we could use injection to inject the entire VM image as well, but we don't, we inject the key and decrypt the image ... it does rather sound like that's what should be happening for other bulk data, like the keep. If you do it this way you can use the main CPU and bulk memory encryption to pull the data into the secure memory rather than using the PSP, which is a lot slower. Also one of the problems with having OVMF define the secret location is that we have to find space in the MEMFD. For a single page like the current implementation uses, that's easy, but for tens to hundreds of pages it would be impossible. Even if we guid describe everything, standard aes keys are 16-32 bytes, so even in the worst case we can fit 85 guid described decryption keys in a page, which should be more than enough for anyone, provided we inject the key to the bulk data, not the bulk data itself. > I am not sure if we really need it for the VM boot flow but we > probably need to define the secret page layout such that it contains > multiple entries in it. In our case the Secret can't be more than a > page, so, we can define a secret page layout such that it can contain > more than one disk key. I was thinking about something like this > > typedef enum { > > DISK_KEY_AES_128, > > SSH_PRIVATE_KEY, > > ... > > } data_type; > > struct secret_data { > > u8 entries; > > struct { > > data_type type; > > u16 len; > > u8 name[16]; > > u8 data[]; > > } entry[]; > > } > > This should allow us to package multiple secrets in one inject. I proposed something slightly different in a prior email. If we use the guid approach, we don't have to define the data structure a-priori ... just the producer and consumer have to agree on what it is. > > > Do you see any need for the Linux kernel needing to access the > > > secret? Since the secret blob is available through configuration > > > table, I believe we can have a platform driver that can read the > > > configuration table and retrieve the secret blob. > > I guess it depends if you get the Grub to pass the fs secret down > > to the kernel or let it pick it up itself from the same place. > > I guess the main reason why I was asking this is, what if guest owner > provides more than one disk keys in the secret injection blob. Grub > can use the boot disk key to access the Linux images and other disk > keys may later be used by Linux. Right, see other email for limitations. James ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 22:50 ` James Bottomley @ 2020-11-15 14:08 ` Brijesh Singh 0 siblings, 0 replies; 35+ messages in thread From: Brijesh Singh @ 2020-11-15 14:08 UTC (permalink / raw) To: jejb, Dr. David Alan Gilbert Cc: brijesh.singh, devel, dovmurik, Dov.Murik1, ashish.kalra, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh On 11/12/20 4:50 PM, James Bottomley wrote: > On Thu, 2020-11-12 at 15:56 -0600, Brijesh Singh wrote: >> On 11/12/20 1:38 PM, Dr. David Alan Gilbert wrote: >>> * Brijesh Singh (brijesh.singh@amd.com) wrote: >>>> Hi James, >>>> >>>> Thanks for series, I glanced at it, the changes looks okay to me. >>>> I have one questions. >>>> >>>> How does the grub locate the disk decryption key ? Am I correct >>>> in assuming that the gurb is iterating through a configuration >>>> table entries and comparing the Secret GUID to locate the secret >>>> key. As per the SEV spec, its possible that a guest owner can >>>> call the secret injection more than once. I don't see the patch >>>> consider that case, should we support this or limit to one >>>> inject? Maybe Qemu can enforce this property. >>> That's interesting, I hadn't realised that was possible - however, >>> I can't see a way to use it - for it to be useful, you would have >>> to have a way for the guest to communicate to the owner that it had >>> finished with the first injection and would like the next; but if >>> you already have a way to communicate from the guest to the owner >>> to request stuff, then you could pass a new secret by that comms >>> route? >> The main reason for its existence was to allow guest owner to inject >> multiple blocks of the data if they need to do so, e.g IIRC, Enarx >> folks use this to inject the keep which is much bigger than 128K. > In some ways this sounds like the wrong approach. I mean we could use > injection to inject the entire VM image as well, but we don't, we > inject the key and decrypt the image ... it does rather sound like > that's what should be happening for other bulk data, like the keep. If > you do it this way you can use the main CPU and bulk memory encryption > to pull the data into the secure memory rather than using the PSP, > which is a lot slower. I wanted to highlight spec. I agree that in our VM launch I don't see a need to provide a multiple LAUNCH_SECRET as long as we define producer and consumer format to package the multiple secrets in one inject. > > Also one of the problems with having OVMF define the secret location is > that we have to find space in the MEMFD. For a single page like the > current implementation uses, that's easy, but for tens to hundreds of > pages it would be impossible. Even if we guid describe everything, > standard aes keys are 16-32 bytes, so even in the worst case we can fit > 85 guid described decryption keys in a page, which should be more than > enough for anyone, provided we inject the key to the bulk data, not the > bulk data itself. >> I am not sure if we really need it for the VM boot flow but we >> probably need to define the secret page layout such that it contains >> multiple entries in it. In our case the Secret can't be more than a >> page, so, we can define a secret page layout such that it can contain >> more than one disk key. I was thinking about something like this >> >> typedef enum { >> >> DISK_KEY_AES_128, >> >> SSH_PRIVATE_KEY, >> >> ... >> >> } data_type; >> >> struct secret_data { >> >> u8 entries; >> >> struct { >> >> data_type type; >> >> u16 len; >> >> u8 name[16]; >> >> u8 data[]; >> >> } entry[]; >> >> } >> >> This should allow us to package multiple secrets in one inject. > I proposed something slightly different in a prior email. If we use > the guid approach, we don't have to define the data structure a-priori > ... just the producer and consumer have to agree on what it is. Yes, your guid approach is much preferred. thanks > >>>> Do you see any need for the Linux kernel needing to access the >>>> secret? Since the secret blob is available through configuration >>>> table, I believe we can have a platform driver that can read the >>>> configuration table and retrieve the secret blob. >>> I guess it depends if you get the Grub to pass the fs secret down >>> to the kernel or let it pick it up itself from the same place. >> I guess the main reason why I was asking this is, what if guest owner >> provides more than one disk keys in the secret injection blob. Grub >> can use the boot disk key to access the Linux images and other disk >> keys may later be used by Linux. > Right, see other email for limitations. > > James > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 17:32 ` Brijesh Singh 2020-11-12 19:38 ` Dr. David Alan Gilbert @ 2020-11-12 19:44 ` James Bottomley 1 sibling, 0 replies; 35+ messages in thread From: James Bottomley @ 2020-11-12 19:44 UTC (permalink / raw) To: Brijesh Singh, devel Cc: dovmurik, Dov.Murik1, ashish.kalra, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On Thu, 2020-11-12 at 11:32 -0600, Brijesh Singh wrote: > Hi James, > > Thanks for series, I glanced at it, the changes looks okay to me. I > have > one questions. > > How does the grub locate the disk decryption key ? Am I correct in > assuming that the gurb is iterating through a configuration table > entries and comparing the Secret GUID to locate the secret key. As > per the SEV spec, its possible that a guest owner can call the secret > injection more than once. I don't see the patch consider that case, > should we support this or limit to one inject? Maybe Qemu can > enforce this property. Well in the original patch, grub recognized the secret in the area by the prefix "PASSWORD:". I think that's a bit fragile, so I was planning to rework the grub patch to do everything by guid, so the secrets table itself would have its own guid which would be followed by the entire table length. Then the entries in the table would have the format |guid|len|data| So every consumer first of all validates the table by the initial guid and gets the total length then iterates over the entries to see if its interested in any of them. The format of |data| would be up to the consumer. > Do you see any need for the Linux kernel needing to access the > secret? Since the secret blob is available through configuration > table, I believe we can have a platform driver that can read the > configuration table and retrieve the secret blob. I've only been really concentrating on the grub use case. However, as you saw in my reply about migration, we likely also need an entry so that the migration helper can pick up its ECDH identity. The scheme would definitely cover passing a secret to the kernel as well. The one caveat there is that the HOB that covers the secret is boot time, so the secret would have to be extracted in the kernel EFI stub before ExitBootServices() is called. I suppose nothing really prevent the HOB from becoming runtime except the security maxim that you want all secret lifetimes to be as short as possible. James ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 0:13 [PATCH 0/4] SEV Encrypted Boot for Ovmf James Bottomley ` (5 preceding siblings ...) 2020-11-12 17:32 ` Brijesh Singh @ 2020-11-13 2:04 ` James Bottomley 2020-11-13 22:41 ` Laszlo Ersek 2020-11-16 18:50 ` Laszlo Ersek 8 siblings, 0 replies; 35+ messages in thread From: James Bottomley @ 2020-11-13 2:04 UTC (permalink / raw) To: devel Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On Wed, 2020-11-11 at 16:13 -0800, James Bottomley wrote: > This patch series is modelled on the structure of the Bhyve patches > for Ovmf, since it does somewhat similar things. This patch series > creates a separate build for an AmdSev OVMF.fd that does nothing > except combine with grub and boot straight through the internal grub > to try to mount an encrypted volume. The necessary patches to grub to allow it to retrieve the SEV secret are now posted on the grub development list: https://lists.gnu.org/archive/html/grub-devel/2020-11/msg00078.html This includes the sevsecret module which is required to build the embedded grub. Regards, James ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 0:13 [PATCH 0/4] SEV Encrypted Boot for Ovmf James Bottomley ` (6 preceding siblings ...) 2020-11-13 2:04 ` [edk2-devel] " James Bottomley @ 2020-11-13 22:41 ` Laszlo Ersek 2020-11-16 18:50 ` Laszlo Ersek 8 siblings, 0 replies; 35+ messages in thread From: Laszlo Ersek @ 2020-11-13 22:41 UTC (permalink / raw) To: devel, jejb Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/12/20 01:13, James Bottomley wrote: > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > This patch series is modelled on the structure of the Bhyve patches > for Ovmf, since it does somewhat similar things. This patch series > creates a separate build for an AmdSev OVMF.fd that does nothing > except combine with grub and boot straight through the internal grub > to try to mount an encrypted volume. > > Concept: SEV Secure Encrypted Images > ==================================== > > The SEV patches in Linux and OVMF allow for the booting of SEV VMs in > an encrypted state, but don't really show how this could be done with > an encrypted image. Since the key used to decrypt the image must be > maintained within the SEV encryption envelope, encrypted QCOW is not > an option because the key would then have to be known to QEMU which is > outside the encryption envelope. The proposal here is that an > encrypted image should be a QCOW image consisting of two partitions, > the normal unencrypted EFI partition (Identifying it as an OVMF > bootable image) and a luks encrypted root partition. The kernel would > be inside the encrypted root in the /boot directory. The secret > injected securely through QEMU is extracted by OVMF and passed to grub > which uses it to mount the encrypted root and boot the kernel > normally. The creator of the secret bundle must be satisfied with the > SEV attestation before the secret is constructed. Unfortunately, the > SEV attestation can only be on the first QEMU firmware volume and > nothing else, so this patch series builds grub itself into a firmware > volume and places it inside OVMF so that the entire boot system can be > attested. In a normal OVMF KVM system, the variable store is on the > second flash volume (which is read/write). Unfortunately, this > mutable configuration provided by the variables is outside the > attestation envelope and can significantly alter the boot path, > possibly leading to secret leak, so encrypted image boot should only > be done with the OVMF.fd that combines both the code and variables. > the OVMF.fd is constructed so that it becomes impossible to interrupt > the boot sequence after attestation and the system will either boot > the image or fail. The boot sequence runs the grub.efi embedded in the > OVMF firmware volume so the encrypted image owner knows their own > version of grub is the only one that will boot before injecting the > secret. Note this boot path actually ignores the unencrypted EFI > partition. However, as part of this design, the encrypted image may be > booted by a standard OVMF KVM boot and in that case, the user will > have to type the encryption password. This standard boot will be > insecure but it might be used by the constructor of the encrypted > images on their own private laptop, for instance. The standard boot > path will use the unencrypted EFI partition. > > Patches Required Outside of OVMF > ================================ > > There is a patch set to grub which allows it to extract the SEV secret > area from the configuration table and use the secret as a password to > do a luks crypto mount of root (this is the sevsecret grub module). > > There is also a patch to qemu which allows it to search through the > OVMF.fd and find the SEV secret area which is now described inside the > Reset Vector using the existing SEV_ES reset block. This area is the > place QEMU will inject the encrypted SEV secret bundle. > > Security of the System > ====================== > > Since Grub is now part of the attested OVMF.fd bundle, the VM owner > knows absolutely that it will proceed straight to partition decryption > inside the attested code and boot the kernel off the encrypted > partition. Even if a different QCOW image is substituted, the boot > will fail without revealing the secret because the system is designed > to fail hard in that case and because the secret is always contained > within the encrypted envelope it should be impossible for the cloud > operator to obtain it even if they can pause the boot and examine the > machine memory. > > Putting it All Together > ======================= > > This is somewhat hard. You must first understand how to boot a QEMU > system so as to have the VM pause after firmware loading (-S option) > and use the qmp port to request an attestation. Only if the > attestation corresponds to the expected sha256sum of OVMF.fd should > the secret bundle be constructed and injected using qmp. The tools > for constructing the secret bundle are in > > https://github.com/AMDESE/sev-tool/ > > James > > --- > > James Bottomley (4): > OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF > OvmfPkg/AmdSev: add Grub Firmware Volume Package > OvmfPkg: create a SEV secret area in the AmdSev memfd > OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table > > OvmfPkg/OvmfPkg.dec | 6 + > OvmfPkg/AmdSev/AmdSevX64.dsc | 1035 +++++++++++ > OvmfPkg/AmdSev/AmdSevX64.fdf | 515 ++++++ > OvmfPkg/AmdSev/Grub/Grub.inf | 37 + > .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 + > .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 + > .../PlatformBootManagerLibGrub.inf | 84 + > OvmfPkg/ResetVector/ResetVector.inf | 4 + > .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++ > .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 + > .../SevLaunchSecret/SecretPei/SecretPei.c | 26 + > .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++ > .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++ > OvmfPkg/AmdSev/Grub/.gitignore | 1 + > OvmfPkg/AmdSev/Grub/grub.cfg | 35 + > OvmfPkg/AmdSev/Grub/grub.sh | 54 + > OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 + > OvmfPkg/ResetVector/ResetVector.nasmb | 2 + > 18 files changed, 3846 insertions(+) > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf > create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c > create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore > create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg > create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh > queued this thread for review ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-12 0:13 [PATCH 0/4] SEV Encrypted Boot for Ovmf James Bottomley ` (7 preceding siblings ...) 2020-11-13 22:41 ` Laszlo Ersek @ 2020-11-16 18:50 ` Laszlo Ersek 2020-11-16 18:56 ` Laszlo Ersek 2020-11-16 19:55 ` James Bottomley 8 siblings, 2 replies; 35+ messages in thread From: Laszlo Ersek @ 2020-11-16 18:50 UTC (permalink / raw) To: devel, jejb Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert Hi James, On 11/12/20 01:13, James Bottomley wrote: > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > This patch series is modelled on the structure of the Bhyve patches > for Ovmf, since it does somewhat similar things. This patch series > creates a separate build for an AmdSev OVMF.fd that does nothing > except combine with grub and boot straight through the internal grub > to try to mount an encrypted volume. I've opened a feture request BZ at <https://bugzilla.tianocore.org/show_bug.cgi?id=3077>. Can you please register in the TianoCore Bugzilla, and assign the bug to yourself? I'll post more comments under the individual patches. Thanks, Laszlo > > Concept: SEV Secure Encrypted Images > ==================================== > > The SEV patches in Linux and OVMF allow for the booting of SEV VMs in > an encrypted state, but don't really show how this could be done with > an encrypted image. Since the key used to decrypt the image must be > maintained within the SEV encryption envelope, encrypted QCOW is not > an option because the key would then have to be known to QEMU which is > outside the encryption envelope. The proposal here is that an > encrypted image should be a QCOW image consisting of two partitions, > the normal unencrypted EFI partition (Identifying it as an OVMF > bootable image) and a luks encrypted root partition. The kernel would > be inside the encrypted root in the /boot directory. The secret > injected securely through QEMU is extracted by OVMF and passed to grub > which uses it to mount the encrypted root and boot the kernel > normally. The creator of the secret bundle must be satisfied with the > SEV attestation before the secret is constructed. Unfortunately, the > SEV attestation can only be on the first QEMU firmware volume and > nothing else, so this patch series builds grub itself into a firmware > volume and places it inside OVMF so that the entire boot system can be > attested. In a normal OVMF KVM system, the variable store is on the > second flash volume (which is read/write). Unfortunately, this > mutable configuration provided by the variables is outside the > attestation envelope and can significantly alter the boot path, > possibly leading to secret leak, so encrypted image boot should only > be done with the OVMF.fd that combines both the code and variables. > the OVMF.fd is constructed so that it becomes impossible to interrupt > the boot sequence after attestation and the system will either boot > the image or fail. The boot sequence runs the grub.efi embedded in the > OVMF firmware volume so the encrypted image owner knows their own > version of grub is the only one that will boot before injecting the > secret. Note this boot path actually ignores the unencrypted EFI > partition. However, as part of this design, the encrypted image may be > booted by a standard OVMF KVM boot and in that case, the user will > have to type the encryption password. This standard boot will be > insecure but it might be used by the constructor of the encrypted > images on their own private laptop, for instance. The standard boot > path will use the unencrypted EFI partition. > > Patches Required Outside of OVMF > ================================ > > There is a patch set to grub which allows it to extract the SEV secret > area from the configuration table and use the secret as a password to > do a luks crypto mount of root (this is the sevsecret grub module). > > There is also a patch to qemu which allows it to search through the > OVMF.fd and find the SEV secret area which is now described inside the > Reset Vector using the existing SEV_ES reset block. This area is the > place QEMU will inject the encrypted SEV secret bundle. > > Security of the System > ====================== > > Since Grub is now part of the attested OVMF.fd bundle, the VM owner > knows absolutely that it will proceed straight to partition decryption > inside the attested code and boot the kernel off the encrypted > partition. Even if a different QCOW image is substituted, the boot > will fail without revealing the secret because the system is designed > to fail hard in that case and because the secret is always contained > within the encrypted envelope it should be impossible for the cloud > operator to obtain it even if they can pause the boot and examine the > machine memory. > > Putting it All Together > ======================= > > This is somewhat hard. You must first understand how to boot a QEMU > system so as to have the VM pause after firmware loading (-S option) > and use the qmp port to request an attestation. Only if the > attestation corresponds to the expected sha256sum of OVMF.fd should > the secret bundle be constructed and injected using qmp. The tools > for constructing the secret bundle are in > > https://github.com/AMDESE/sev-tool/ > > James > > --- > > James Bottomley (4): > OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF > OvmfPkg/AmdSev: add Grub Firmware Volume Package > OvmfPkg: create a SEV secret area in the AmdSev memfd > OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table > > OvmfPkg/OvmfPkg.dec | 6 + > OvmfPkg/AmdSev/AmdSevX64.dsc | 1035 +++++++++++ > OvmfPkg/AmdSev/AmdSevX64.fdf | 515 ++++++ > OvmfPkg/AmdSev/Grub/Grub.inf | 37 + > .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 + > .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 + > .../PlatformBootManagerLibGrub.inf | 84 + > OvmfPkg/ResetVector/ResetVector.inf | 4 + > .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++ > .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 + > .../SevLaunchSecret/SecretPei/SecretPei.c | 26 + > .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++ > .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++ > OvmfPkg/AmdSev/Grub/.gitignore | 1 + > OvmfPkg/AmdSev/Grub/grub.cfg | 35 + > OvmfPkg/AmdSev/Grub/grub.sh | 54 + > OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 + > OvmfPkg/ResetVector/ResetVector.nasmb | 2 + > 18 files changed, 3846 insertions(+) > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf > create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c > create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore > create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg > create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-16 18:50 ` Laszlo Ersek @ 2020-11-16 18:56 ` Laszlo Ersek 2020-11-16 19:55 ` James Bottomley 1 sibling, 0 replies; 35+ messages in thread From: Laszlo Ersek @ 2020-11-16 18:56 UTC (permalink / raw) To: devel, jejb Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On 11/16/20 19:50, Laszlo Ersek wrote: > Hi James, > > On 11/12/20 01:13, James Bottomley wrote: >> From: James Bottomley <James.Bottomley@HansenPartnership.com> >> >> This patch series is modelled on the structure of the Bhyve patches >> for Ovmf, since it does somewhat similar things. This patch series >> creates a separate build for an AmdSev OVMF.fd that does nothing >> except combine with grub and boot straight through the internal grub >> to try to mount an encrypted volume. > > I've opened a feture request BZ at > <https://bugzilla.tianocore.org/show_bug.cgi?id=3077>. > > Can you please register in the TianoCore Bugzilla, and assign the bug to > yourself? > > I'll post more comments under the individual patches. (1) There are a number of git settings that are useful with edk2 clones. Most of them are described at <https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05> but for convenience, the edk2 repo provides the "BaseTools/Scripts/SetupGit.py" script. Can you please run it in your git repo? (2) Every commit message should reference TianoCore#3077 like this: """ Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 """ just above the S-o-b. Thanks Laszlo ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [edk2-devel] [PATCH 0/4] SEV Encrypted Boot for Ovmf 2020-11-16 18:50 ` Laszlo Ersek 2020-11-16 18:56 ` Laszlo Ersek @ 2020-11-16 19:55 ` James Bottomley 1 sibling, 0 replies; 35+ messages in thread From: James Bottomley @ 2020-11-16 19:55 UTC (permalink / raw) To: Laszlo Ersek, devel Cc: dovmurik, Dov.Murik1, ashish.kalra, brijesh.singh, tobin, david.kaplan, jon.grimm, thomas.lendacky, frankeh, Dr . David Alan Gilbert On Mon, 2020-11-16 at 19:50 +0100, Laszlo Ersek wrote: > Hi James, > > On 11/12/20 01:13, James Bottomley wrote: > > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > > > This patch series is modelled on the structure of the Bhyve patches > > for Ovmf, since it does somewhat similar things. This patch series > > creates a separate build for an AmdSev OVMF.fd that does nothing > > except combine with grub and boot straight through the internal > > grub > > to try to mount an encrypted volume. > > I've opened a feture request BZ at > <https://bugzilla.tianocore.org/show_bug.cgi?id=3077>;. > > Can you please register in the TianoCore Bugzilla, and assign the bug > to yourself? OK, done. > I'll post more comments under the individual patches. Great, thanks! James ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2020-11-20 10:59 UTC | newest] Thread overview: 35+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-11-12 0:13 [PATCH 0/4] SEV Encrypted Boot for Ovmf James Bottomley 2020-11-12 0:13 ` [PATCH 1/4] OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF James Bottomley 2020-11-16 19:11 ` [edk2-devel] " Laszlo Ersek 2020-11-16 20:00 ` James Bottomley 2020-11-12 0:13 ` [PATCH 2/4] OvmfPkg/AmdSev: add Grub Firmware Volume Package James Bottomley 2020-11-16 20:42 ` [edk2-devel] " Laszlo Ersek 2020-11-17 0:05 ` Laszlo Ersek 2020-11-18 23:00 ` James Bottomley 2020-11-19 7:59 ` Laszlo Ersek 2020-11-12 0:13 ` [PATCH 3/4] OvmfPkg: create a SEV secret area in the AmdSev memfd James Bottomley 2020-11-16 22:46 ` [edk2-devel] " Laszlo Ersek 2020-11-18 20:23 ` James Bottomley 2020-11-19 7:50 ` Laszlo Ersek 2020-11-19 19:41 ` Brijesh Singh 2020-11-20 6:29 ` jejb 2020-11-20 10:59 ` Laszlo Ersek 2020-11-18 20:39 ` Lendacky, Thomas 2020-11-19 7:51 ` Laszlo Ersek 2020-11-12 0:13 ` [PATCH 4/4] OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table James Bottomley 2020-11-17 0:12 ` [edk2-devel] " Laszlo Ersek 2020-11-12 16:21 ` [PATCH 0/4] SEV Encrypted Boot for Ovmf Ashish Kalra 2020-11-12 16:34 ` Dr. David Alan Gilbert 2020-11-12 17:07 ` James Bottomley 2020-11-12 17:22 ` Ashish Kalra 2020-11-12 17:32 ` Brijesh Singh 2020-11-12 19:38 ` Dr. David Alan Gilbert 2020-11-12 21:56 ` Brijesh Singh 2020-11-12 22:50 ` James Bottomley 2020-11-15 14:08 ` Brijesh Singh 2020-11-12 19:44 ` James Bottomley 2020-11-13 2:04 ` [edk2-devel] " James Bottomley 2020-11-13 22:41 ` Laszlo Ersek 2020-11-16 18:50 ` Laszlo Ersek 2020-11-16 18:56 ` Laszlo Ersek 2020-11-16 19:55 ` James Bottomley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox