Date   

[PATCH 0/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()

Christoph Willing
 

Use of Qemu's -kernel option (thus also -initrd & -append) is currently n=
ot
working correctly under UEFI boot. The nominated kernel is loaded and the
initrd is opened successfully but there is no access to the VM filesystem=
.
Booting without the -kernel option i.e. using the VM's internal kernel & =
intird
works as expected with UEFI.

This behaviour has been observed in all of the four Linux systems tested =
for
verification.

The commit at which this behaviour appears has been identified and the p=
atch
proposed here just reverses it i.e. we now run TryRunningQemuKernel() aft=
er
PlatformBdsConnectSequence() instead of before it. When the proposed patc=
h is
applied, all four systems are subsequently able to boot correctly under U=
EFI.

Christoph Willing (1):
OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()

OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--=20
2.32.0


Event: TianoCore Bug Triage - APAC / NAMO - 07/27/2021 #cal-reminder

devel@edk2.groups.io Calendar <noreply@...>
 

Reminder: TianoCore Bug Triage - APAC / NAMO

When:
07/27/2021
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

Organizer: Liming Gao gaoliming@...

View Event

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,77463821#   United States, Sacramento

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


Re: [PATCH V3 06/10] OvmfPkg: Add AmdSev.asm in ResetVector

Min Xu
 

On July 27, 2021 8:31 PM, Brijesh Singh wrote:
On 7/27/21 6:51 AM, Xu, Min M wrote:
On July 27, 2021 6:57 PM, Brijesh Singh wrote:
Hi Min,

This refactoring is already done by the SNP patch series.

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk
2.groups.io%2Fg%2Fdevel%2Fmessage%2F77336%3Fp%3D%2C%2C%2C20%
2C0%2C0%2
C0%3A%3ACreated%2C%2Cpost&amp;data=04%7C01%7Cbrijesh.singh%40a
md.com%
7C22b61f2ff5bb48348b0608d950f4d7c5%7C3dd8961fe4884e608e11a82d994
e183d
%7C0%7C0%7C637629834792320372%7CUnknown%7CTWFpbGZsb3d8ey
JWIjoiMC4wLjA
wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s
data=
tMGpR4a2uZTTR%2FsciTN0oeca2mZ32GfX3K78lA5BWas%3D&amp;reserved
=0
erid%3A5969970,20,2,20,83891510

It appears that you are also pulling in some of TDX logic inside the
AMDSev.asm such as

;
+PostJump64BitAndLandHereSev:
+
+ ;
+ ; If it is Tdx guest, jump to exit point directly.
+ ; This is because following code may access the memory region which
has
+ ; not been accepted. It is not allowed in Tdx guests.
+ ;
+ mov eax, dword[TDX_WORK_AREA]
+ cmp eax, 0x47584454 ; 'TDXG'
+ jz GoodCompare

Why we are referring the TDX workarea inside the AmdSev.asm ?
See my explanation in the above comments. In Tdx guests memory region
cannot be accessed unless it is accepted by guest or initialized by
the host VMM. In PostJump64BitAndLandHereSev there is access to
dword[SEV_ES_WORK_AREA_RDRAND] which is not initialized by host
VMM.
If this code will not be executed in Tdx guest, then the above check is not
needed. I need your help to confirm it.

There are similar Tdx check in my patch of AmdSev.asm. For example in
CheckSevFeatures byte[SEV_ES_WORK_AREA] is used to record the SEV-ES
flag. This memory region is not initialized by host VMM either. So in Tdx it
will trigger error.

Another solution is that the memory region used by SEV in ResetVector
are added Into Tdx metadata so that host VMM will initialize those
memory region when It creates the Td guest. What's your opinion?
I am not full versed on TDX yet and sorry I am not able to follow you
question completely to provide any advice. With SEV and SEV-ES, a guest can
access the memory without going through the validation process, but with
the SEV-SNP, the page need to be validated (aka accepted) before the access.
TDX has the same requirement.
In SNP series, we ensure that the data pages used in the reset vector are pre-
validated during the VM creation time -- this allows us to access the pages
without going through accept process. If I follow you correctly on your
metadata comment then it is similar to saying is pre-validate these range of
pages used in the reset vector code (that include GHCB page, Page table
pages etc), right ?
That's right. Tdx metadata describes the memory region which host VMM initialized
during the VM creation time.

In the current patch-set, below memory region are described in Tdx metadata.
- TdMailbox (PcdOvmfSecGhcbBackupBase)
- TdHob(PcdOvmfSecGhcbBase)
- TdExtraPage(PcdOvmfSecGhcbPageTableBase)
- OvmfPageTable (PcdOvmfSecPageTablesBase)
These memory regions are initialized by host VMM so they can be accessed in ResetVector in Tdx guests.

In the SEV codes, I find some memory is accessed as well. CheckSevFeatures is the example.
In CheckSevFeatures byte[SEV_ES_WORK_AREA] (PcdSevEsWorkAreaBase) is used to record/check
if it is SEV. So if this function is called in Tdx guest, then error is triggered.

What I am concerned is that, in the current pattern:
====================
OneTimeCall PreMainFunctionHookSev
OneTimeCall PreMainFunctionHookTdx
MainFunction:
XXXXXX
OneTimeCall PostMainFunctionHookSev
OneTimeCall PostMainFunctionHookTdx
====================
The TEE function need implement a TEE check function (such as IsSev, or IsTdx).
Tdx call CPUID(0x21) to determine if it is tdx guest in the very beginning of ResetVector. Then 'TDXG' is set
in TDX_WORK_AREA.
SEV does the similar work which call CheckSevFeatures to set SEV_ES_WORK_AREA to 1.
After that both TDX and SEV read the above WORK_AREA to check it is TDX or SEV or legacy guest.

In Tdx the access to SEV_ES_WORK_AREA will trigger error because SEV_ES_WORK_AREA is initialized by host VMM.
In SEV-SNP I am afraid the access to TDX_WORK_AREA will trigger error too.

I am wondering if TDX and SEV can use the same memory region (for example, TEE_WORK_AREA) as the work area?
So that this work area is guaranteed to be initialized in both TDX and SEV. Structure of the TEE_WORK_AREA may
look like this:
typedef struct {
UINT8 Flag[4]; 'TDXG' or 'SEVG' or all-0
UINT8 Others[];
} TEE_WORK_AREA;


For SEV-SNP, see this patch

https://edk2.groups.io/g/devel/message/77342?p=,,,20,0,0,0::Created,,post
erid%3A5969970,20,2,20,83891520

A VMM (qemu) looks for the range of page it need to prevalidate before the
boot, the range is provided through the GUID (SevSnpBootBlock).

I will take out my refactoring patch outside of the SNP series and
submit it so that you can build on top of. This will simplify review process.
Thank you very much for the refactoring. I will refine my patch based on it.
thanks


Re: [EXTERNAL] [edk2-devel] Missing TPM 2 related call to Tpm2HierarchyChangeAuth

Stefan Berger
 


On 7/27/21 12:25 PM, Yao, Jiewen wrote:

Oops. Sorry for late response.

 

The code is NOT in EDKII, but EDKII-platform as example. https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Tcg

 

We allow a platform having its own implementation. That is why it is NOT in EDKII.


How do edk2 and edk2-platform relate? Do we need to copy code form one to the other ?

   Stefan


 

Thank you

Yao Jiewen

 

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Bret Barkelew via groups.io
Sent: Wednesday, July 28, 2021 12:11 AM
To: devel@edk2.groups.io; stefanb@...; Yao, Jiewen <jiewen.yao@...>; Jeremiah Cox <jerecox@...>; Michael Kubacki <Michael.Kubacki@...>
Cc: Marc-André Lureau <marcandre.lureau@...>
Subject: Re: [EXTERNAL] [edk2-devel] Missing TPM 2 related call to Tpm2HierarchyChangeAuth

 

Adding @Jeremiah

 

Jeremiah, weren’t you or @Michael shopping this change to MinPlatform?

 

- Bret

 

From: Stefan Berger via groups.io
Sent: Monday, July 26, 2021 7:48 AM
To: Yao, Jiewen; devel@edk2.groups.io
Cc: Marc-André Lureau
Subject: [EXTERNAL] [edk2-devel] Missing TPM 2 related call to Tpm2HierarchyChangeAuth

 

Hello!

   The TPM 2 code in EDK2 is missing an important call to
Tpm2HierarchyChangeAuth for the platform hierarchy. We have to set the
password of that hierarchy and discard the password. See also specs
section 11:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedcomputinggroup.org%2Fwp-content%2Fuploads%2FTCG_PCClient_PFP_r1p05_v22_02dec2020.pdf&amp;data=04%7C01%7Cbret.barkelew%40microsoft.com%7Cf2a2262eee2c44b3760c08d95044601a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637629077356686202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=N7VQIw87rHqUAFQ54TvhNwcsPFEwJzdZQ9JZrmX1S4E%3D&amp;reserved=0

"Platform Firmware MUST protect access to the Platform Hierarchy and
prevent access to the platform hierarchy by
non-manufacturer-controlled components.  "

I was wondering where we could put that call so it's invoked after the
user has possibly interacted with the menu and before passing control to
the next stage such as boot loader.

Regards,

   Stefan





 


[PATCH v5 06/11] ArmVirtPkg: add BlobVerifierLibNull to DSC

Dov Murik
 

This prepares the ground for calling VerifyBlob() in
QemuKernelLoaderFsDxe.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
---
ArmVirtPkg/ArmVirtQemu.dsc | 5 ++++-
ArmVirtPkg/ArmVirtQemuKernel.dsc | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 7ef5e7297bc7..97539edef799 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -440,7 +440,10 @@ [Components.common]
NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf=0D
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanc=
eManagerUiLib.inf=0D
}=0D
- OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf=0D
+ OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {=0D
+ <LibraryClasses>=0D
+ NULL|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf=0D
+ }=0D
=0D
#=0D
# Networking stack=0D
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKerne=
l.dsc
index a542fcb157e9..28064199c8a9 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -376,7 +376,10 @@ [Components.common]
NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf=0D
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanc=
eManagerUiLib.inf=0D
}=0D
- OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf=0D
+ OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {=0D
+ <LibraryClasses>=0D
+ NULL|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf=0D
+ }=0D
=0D
#=0D
# Networking stack=0D
--=20
2.25.1


[PATCH v5 08/11] OvmfPkg/AmdSev/SecretPei: build hob for full page

Dov Murik
 

Round up the size of the SEV launch secret area to a whole page, as
required by BuildMemoryAllocationHob. This will allow the secret
area defined in the MEMFD to take less than a whole 4KB page.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
---
OvmfPkg/AmdSev/SecretPei/SecretPei.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/AmdSev/SecretPei/SecretPei.c b/OvmfPkg/AmdSev/SecretPe=
i/SecretPei.c
index ad491515dd5d..db94c26b54d1 100644
--- a/OvmfPkg/AmdSev/SecretPei/SecretPei.c
+++ b/OvmfPkg/AmdSev/SecretPei/SecretPei.c
@@ -4,6 +4,7 @@
Copyright (C) 2020 James Bottomley, IBM Corporation.=0D
SPDX-License-Identifier: BSD-2-Clause-Patent=0D
**/=0D
+#include <Base.h>=0D
#include <PiPei.h>=0D
#include <Library/HobLib.h>=0D
#include <Library/PcdLib.h>=0D
@@ -17,7 +18,7 @@ InitializeSecretPei (
{=0D
BuildMemoryAllocationHob (=0D
PcdGet32 (PcdSevLaunchSecretBase),=0D
- PcdGet32 (PcdSevLaunchSecretSize),=0D
+ ALIGN_VALUE (PcdGet32 (PcdSevLaunchSecretSize), EFI_PAGE_SIZE),=0D
EfiBootServicesData=0D
);=0D
=0D
--=20
2.25.1


[PATCH v5 09/11] OvmfPkg/AmdSev: reserve MEMFD space for for firmware config hashes

Dov Murik
 

From: James Bottomley <jejb@linux.ibm.com>

Split the existing 4KB page reserved for SEV launch secrets into two
parts: first 3KB for SEV launch secrets and last 1KB for firmware
config hashes.

The area of the firmware config hashes will be attested (measured) by
the PSP and thus the untrusted VMM can't pass in different files from
what the guest owner allows.

Declare this in the Reset Vector table using GUID
7255371f-3a3b-4b04-927b-1da6efa8d454 and a uint32_t table of a base
and size value (similar to the structure used to declare the launch
secret block).

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Co-developed-by: Dov Murik <dovmurik@linux.ibm.com>
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
---
OvmfPkg/OvmfPkg.dec | 6 ++++++
OvmfPkg/AmdSev/AmdSevX64.fdf | 5 ++++-
OvmfPkg/ResetVector/ResetVector.inf | 2 ++
OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 20 ++++++++++++++++++++
OvmfPkg/ResetVector/ResetVector.nasmb | 2 ++
5 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index f82228d69cc2..2ab27f0c73c2 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -324,6 +324,12 @@ [PcdsFixedAtBuild]
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|0x0|UINT32|0x42=0D
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize|0x0|UINT32|0x43=0D
=0D
+ ## The base address and size of a hash table confirming allowed=0D
+ # parameters to be passed in via the Qemu firmware configuration=0D
+ # device=0D
+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|0x0|UINT32|0x47=0D
+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize|0x0|UINT32|0x48=0D
+=0D
[PcdsDynamic, PcdsDynamicEx]=0D
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2=0D
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x1=
0=0D
diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf
index 9977b0f00a18..0a89749700c3 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.fdf
+++ b/OvmfPkg/AmdSev/AmdSevX64.fdf
@@ -59,9 +59,12 @@ [FD.MEMFD]
0x00B000|0x001000=0D
gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.P=
cdSevEsWorkAreaSize=0D
=0D
-0x00C000|0x001000=0D
+0x00C000|0x000C00=0D
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGu=
id.PcdSevLaunchSecretSize=0D
=0D
+0x00CC00|0x000400=0D
+gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid=
.PcdQemuHashTableSize=0D
+=0D
0x00D000|0x001000=0D
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase|gUefiOvmfPkgTokenSpace=
Guid.PcdOvmfSecGhcbBackupSize=0D
=0D
diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/ResetVector/Rese=
tVector.inf
index dc38f68919cd..d028c92d8cfa 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -47,3 +47,5 @@ [Pcd]
[FixedPcd]=0D
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase=0D
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize=0D
+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase=0D
+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize=0D
diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVe=
ctor/Ia16/ResetVectorVtf0.asm
index 9c0b5853a46f..7ec3c6e980c3 100644
--- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
+++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
@@ -47,7 +47,27 @@ TIMES (15 - ((guidedStructureEnd - guidedStructureStart =
+ 15) % 16)) DB 0
;=0D
guidedStructureStart:=0D
=0D
+; SEV Hash Table Block=0D
;=0D
+; This describes the guest ram area where the hypervisor should=0D
+; install a table describing the hashes of certain firmware configuration=
=0D
+; device files that would otherwise be passed in unchecked. The current=0D
+; use is for the kernel, initrd and command line values, but others may be=
=0D
+; added. The data format is:=0D
+;=0D
+; base physical address (32 bit word)=0D
+; table length (32 bit word)=0D
+;=0D
+; GUID (SEV FW config hash block): 7255371f-3a3b-4b04-927b-1da6efa8d454=0D
+;=0D
+sevFwHashBlockStart:=0D
+ DD SEV_FW_HASH_BLOCK_BASE=0D
+ DD SEV_FW_HASH_BLOCK_SIZE=0D
+ DW sevFwHashBlockEnd - sevFwHashBlockStart=0D
+ DB 0x1f, 0x37, 0x55, 0x72, 0x3b, 0x3a, 0x04, 0x4b=0D
+ DB 0x92, 0x7b, 0x1d, 0xa6, 0xef, 0xa8, 0xd4, 0x54=0D
+sevFwHashBlockEnd:=0D
+=0D
; SEV Secret block=0D
;=0D
; This describes the guest ram area where the hypervisor should=0D
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/Re=
setVector.nasmb
index 5fbacaed5f9d..8d0bab02f8cb 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -88,5 +88,7 @@
%define SEV_ES_AP_RESET_IP FixedPcdGet32 (PcdSevEsWorkAreaBase)=0D
%define SEV_LAUNCH_SECRET_BASE FixedPcdGet32 (PcdSevLaunchSecretBase)=0D
%define SEV_LAUNCH_SECRET_SIZE FixedPcdGet32 (PcdSevLaunchSecretSize)=0D
+ %define SEV_FW_HASH_BLOCK_BASE FixedPcdGet32 (PcdQemuHashTableBase)=0D
+ %define SEV_FW_HASH_BLOCK_SIZE FixedPcdGet32 (PcdQemuHashTableSize)=0D
%include "Ia16/ResetVectorVtf0.asm"=0D
=0D
--=20
2.25.1


[PATCH v5 04/11] OvmfPkg: add library class BlobVerifierLib with null implementation

Dov Murik
 

BlobVerifierLib will be used to verify blobs fetching them from QEMU's
firmware config (fw_cfg) in platforms that enable such verification.

The null implementation BlobVerifierLibNull treats all blobs as valid.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/OvmfPkg.dec | 3 ++
OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf | 24 +++++++++=
++++
OvmfPkg/Include/Library/BlobVerifierLib.h | 38 +++++++++=
+++++++++++
OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierNull.c | 33 +++++++++=
++++++++
4 files changed, 98 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 6ae733f6e39f..f82228d69cc2 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -23,6 +23,9 @@ [LibraryClasses]
## @libraryclass Access bhyve's firmware control interface.=0D
BhyveFwCtlLib|Include/Library/BhyveFwCtlLib.h=0D
=0D
+ ## @libraryclass Verify blobs read from the VMM=0D
+ BlobVerifierLib|Include/Library/BlobVerifierLib.h=0D
+=0D
## @libraryclass Loads and boots a Linux kernel image=0D
#=0D
LoadLinuxLib|Include/Library/LoadLinuxLib.h=0D
diff --git a/OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf b/=
OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf
new file mode 100644
index 000000000000..850d398e65a4
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf
@@ -0,0 +1,24 @@
+## @file=0D
+#=0D
+# Null implementation of the blob verifier library.=0D
+#=0D
+# Copyright (C) 2021, IBM Corp=0D
+#=0D
+# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+#=0D
+##=0D
+=0D
+[Defines]=0D
+ INF_VERSION =3D 1.29=0D
+ BASE_NAME =3D BlobVerifierLibNull=0D
+ FILE_GUID =3D b1b5533e-e01a-43bb-9e54-414f00ca036e=
=0D
+ MODULE_TYPE =3D BASE=0D
+ VERSION_STRING =3D 1.0=0D
+ LIBRARY_CLASS =3D BlobVerifierLib=0D
+=0D
+[Sources]=0D
+ BlobVerifierNull.c=0D
+=0D
+[Packages]=0D
+ MdePkg/MdePkg.dec=0D
+ OvmfPkg/OvmfPkg.dec=0D
diff --git a/OvmfPkg/Include/Library/BlobVerifierLib.h b/OvmfPkg/Include/Li=
brary/BlobVerifierLib.h
new file mode 100644
index 000000000000..65c01af9bf18
--- /dev/null
+++ b/OvmfPkg/Include/Library/BlobVerifierLib.h
@@ -0,0 +1,38 @@
+/** @file=0D
+=0D
+ Blob verification library=0D
+=0D
+ This library class allows verifiying whether blobs from external sources=
=0D
+ (such as QEMU's firmware config) are trusted.=0D
+=0D
+ Copyright (C) 2021, IBM Corporation=0D
+=0D
+ SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+**/=0D
+=0D
+#ifndef BLOB_VERIFIER_LIB_H_=0D
+#define BLOB_VERIFIER_LIB_H_=0D
+=0D
+#include <Uefi/UefiBaseType.h>=0D
+#include <Base.h>=0D
+=0D
+/**=0D
+ Verify blob from an external source.=0D
+=0D
+ @param[in] BlobName The name of the blob=0D
+ @param[in] Buf The data of the blob=0D
+ @param[in] BufSize The size of the blob in bytes=0D
+=0D
+ @retval EFI_SUCCESS The blob was verified successfully.=0D
+ @retval EFI_ACCESS_DENIED The blob could not be verified, and theref=
ore=0D
+ should be considered non-secure.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+VerifyBlob (=0D
+ IN CONST CHAR16 *BlobName,=0D
+ IN CONST VOID *Buf,=0D
+ IN UINT32 BufSize=0D
+ );=0D
+=0D
+#endif=0D
diff --git a/OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierNull.c b/OvmfP=
kg/Library/BlobVerifierLibNull/BlobVerifierNull.c
new file mode 100644
index 000000000000..975d4dd52f80
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierNull.c
@@ -0,0 +1,33 @@
+/** @file=0D
+=0D
+ Null implementation of the blob verifier library.=0D
+=0D
+ Copyright (C) 2021, IBM Corporation=0D
+=0D
+ SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+**/=0D
+=0D
+#include <Library/BaseLib.h>=0D
+#include <Library/BlobVerifierLib.h>=0D
+=0D
+/**=0D
+ Verify blob from an external source.=0D
+=0D
+ @param[in] BlobName The name of the blob=0D
+ @param[in] Buf The data of the blob=0D
+ @param[in] BufSize The size of the blob in bytes=0D
+=0D
+ @retval EFI_SUCCESS The blob was verified successfully.=0D
+ @retval EFI_ACCESS_DENIED The blob could not be verified, and theref=
ore=0D
+ should be considered non-secure.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+VerifyBlob (=0D
+ IN CONST CHAR16 *BlobName,=0D
+ IN CONST VOID *Buf,=0D
+ IN UINT32 BufSize=0D
+ )=0D
+{=0D
+ return EFI_SUCCESS;=0D
+}=0D
--=20
2.25.1


[PATCH v5 11/11] OvmfPkg/AmdSev: Enforce hash verification of kernel blobs

Dov Murik
 

In the AmdSevX64 build, use BlobVerifierLibSevHashes to enforce
verification of hashes of the kernel/initrd/cmdline blobs fetched from
firmware config.

This allows for secure (measured) boot of SEV guests with QEMU's
-kernel/-initrd/-append switches (with the corresponding QEMU support
for injecting the hashes table into initial measured guest memory).

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/AmdSev/AmdSevX64.dsc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index db8bd59579b9..e6cd10b75922 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -173,7 +173,7 @@ [LibraryClasses]
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf=0D
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/Customize=
dDisplayLib.inf=0D
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltL=
ib.inf=0D
- BlobVerifierLib|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.=
inf=0D
+ BlobVerifierLib|OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierLibS=
evHashes.inf=0D
=0D
!if $(SOURCE_DEBUG_ENABLE) =3D=3D TRUE=0D
PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDeb=
ug/PeCoffExtraActionLibDebug.inf=0D
@@ -696,7 +696,7 @@ [Components]
}=0D
OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {=0D
<LibraryClasses>=0D
- NULL|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf=0D
+ NULL|OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierLibSevHashe=
s.inf=0D
}=0D
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf=0D
OvmfPkg/Virtio10Dxe/Virtio10.inf=0D
--=20
2.25.1


[PATCH v5 01/11] OvmfPkg/AmdSev/SecretDxe: fix header comment to generic naming

Dov Murik
 

From: James Bottomley <jejb@linux.ibm.com>

Commit 96201ae7bf97 ("OvmfPkg/AmdSev/SecretDxe: make secret location
naming generic", 2020-12-15) replaced references to SEV with the generic
term Confidential Computing, but missed the file header comment. Fix
the naming in that header.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
---
OvmfPkg/AmdSev/SecretDxe/SecretDxe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/AmdSev/SecretDxe/SecretDxe.c b/OvmfPkg/AmdSev/SecretDx=
e/SecretDxe.c
index 308022b5b25e..934ad207632b 100644
--- a/OvmfPkg/AmdSev/SecretDxe/SecretDxe.c
+++ b/OvmfPkg/AmdSev/SecretDxe/SecretDxe.c
@@ -1,5 +1,5 @@
/** @file=0D
- SEV Secret configuration table constructor=0D
+ Confidential Computing Secret configuration table constructor=0D
=0D
Copyright (C) 2020 James Bottomley, IBM Corporation.=0D
SPDX-License-Identifier: BSD-2-Clause-Patent=0D
--=20
2.25.1


[PATCH v5 00/11] Measured SEV boot with kernel/initrd/cmdline

Dov Murik
 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3457

Booting with SEV prevented the loading of kernel, initrd, and kernel
command-line via QEMU fw_cfg interface because they arrive from the VMM
which is untrusted in SEV.

However, in some cases the kernel, initrd, and cmdline are not secret
but should not be modified by the host. In such a case, we want to
verify inside the trusted VM that the kernel, initrd, and cmdline are
indeed the ones expected by the Guest Owner, and only if that is the
case go on and boot them up (removing the need for grub inside OVMF in
that mode).

This patch series reserves an area in MEMFD (previously the last 1KB of
the launch secret page) which will contain the hashes of these three
blobs (kernel, initrd, cmdline), each under its own GUID entry. This
tables of hashes is populated by QEMU before launch, and encrypted as
part of the initial VM memory; this makes sure these hashes are part of
the SEV measurement (which has to be approved by the Guest Owner for
secret injection, for example). Note that populating the hashes table
requires QEMU support [1].

OVMF parses the table of hashes populated by QEMU (patch 10), and as it
reads the fw_cfg blobs from QEMU, it will verify each one against the
expected hash. This is all done inside the trusted VM context. If all
the hashes are correct, boot of the kernel is allowed to continue.

Any attempt by QEMU to modify the kernel, initrd, cmdline (including
dropping one of them), or to modify the OVMF code that verifies those
hashes, will cause the initial SEV measurement to change and therefore
will be detectable by the Guest Owner during launch before secret
injection.

Relevant part of OVMF serial log during boot with AmdSevX86 build and
QEMU with -kernel/-initrd/-append:

...
BlobVerifierLibSevHashesConstructor: Found injected hashes table in secure location
Select Item: 0x17
Select Item: 0x8
FetchBlob: loading 7379328 bytes for "kernel"
Select Item: 0x18
Select Item: 0x11
VerifyBlob: Found GUID 4DE79437-ABD2-427F-B835-D5B172D2045B in table
VerifyBlob: Hash comparison succeeded for "kernel"
Select Item: 0xB
FetchBlob: loading 12483878 bytes for "initrd"
Select Item: 0x12
VerifyBlob: Found GUID 44BAF731-3A2F-4BD7-9AF1-41E29169781D in table
VerifyBlob: Hash comparison succeeded for "initrd"
Select Item: 0x14
FetchBlob: loading 86 bytes for "cmdline"
Select Item: 0x15
VerifyBlob: Found GUID 97D02DD8-BD20-4C94-AA78-E7714D36AB2A in table
VerifyBlob: Hash comparison succeeded for "cmdline"
...

The patch series is organized as follows:

1: Simple comment fix in adjacent area in the code.
2: Use GenericQemuLoadImageLib to gain one location for fw_cfg blob
fetching.
3: Allow the (previously blocked) usage of -kernel in AmdSevX64.
4-7: Add BlobVerifierLib with null implementation and use it in the correct
location in QemuKernelLoaderFsDxe.
8-9: Reserve memory for hashes table, declare this area in the reset vector.
10-11: Add the secure implementation BlobVerifierLibSevHashes and use it in
AmdSevX64 builds.

[1] https://lore.kernel.org/qemu-devel/20210624102040.2015280-1-dovmurik@linux.ibm.com/

Code is at
https://github.com/confidential-containers-demo/edk2/tree/sev-hashes-v5

v5 changes:
- rename the null implementation dir to OvmfPkg/Library/BlobVerifierLibNull
(note that I didn't remove the R-b tags on these patches; please let me
know if I should have acted otherwise)
- move the SevHashes implementation to OvmfPkg/AmdSev/BlobVerifierLibSevHashes
- BlobVerifierLib.h: fix #ifndef according to ECC warnings
- separate variable declaration and assignment in
BlobVerifierLibSevHashesConstructor (ECC warning)

v4: https://edk2.groups.io/g/devel/message/78075
v4 changes:
- BlobVerifierSevHashes (patch 10): more comprehensive overflow tests
when parsing the SEV hashes table structure

v3: https://edk2.groups.io/g/devel/message/77955
v3 changes:
- Rename to BlobVerifierLibNull, use decimal INF_VERSION, remove unused
DebugLib reference, fix doxygen comments, add missing IN attribute
- Rename to BlobVerifierLibSevHashes, use decimal INF_VERSION, fix
doxygen comments, add missing IN attribute,
calculate buffer hash only when the guid is found in hashes table
- SecretPei: use ALIGN_VALUE to round the hob size
- Coding style fixes
- Add missing 'Ref:' in patch 1 commit message
- Fix phrasing and typos in commit messages
- Remove Cc: Laszlo from series

v2: https://edk2.groups.io/g/devel/message/77505
v2 changes:
- Use the last 1KB of the existing SEV launch secret page for hashes table
(instead of reserving a whole new MEMFD page).
- Build on top of commit cf203024745f ("OvmfPkg/GenericQemuLoadImageLib: Read
cmdline from QemuKernelLoaderFs", 2021-06-28) to have a single location in
which all of kernel/initrd/cmdline are fetched from QEMU.
- Use static linking of the two BlobVerifierLib implemenatations.
- Reorganize series.

v1: https://edk2.groups.io/g/devel/message/75567

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>

Dov Murik (8):
OvmfPkg/AmdSev: use GenericQemuLoadImageLib in AmdSev builds
OvmfPkg: add library class BlobVerifierLib with null implementation
OvmfPkg: add BlobVerifierLibNull to DSC
ArmVirtPkg: add BlobVerifierLibNull to DSC
OvmfPkg/QemuKernelLoaderFsDxe: call VerifyBlob after fetch from fw_cfg
OvmfPkg/AmdSev/SecretPei: build hob for full page
OvmfPkg/AmdSev: add BlobVerifierLibSevHashes
OvmfPkg/AmdSev: Enforce hash verification of kernel blobs

James Bottomley (3):
OvmfPkg/AmdSev/SecretDxe: fix header comment to generic naming
OvmfPkg: PlatformBootManagerLibGrub: Allow executing kernel via fw_cfg
OvmfPkg/AmdSev: reserve MEMFD space for for firmware config hashes

OvmfPkg/OvmfPkg.dec | 9 +
ArmVirtPkg/ArmVirtQemu.dsc | 5 +-
ArmVirtPkg/ArmVirtQemuKernel.dsc | 5 +-
OvmfPkg/AmdSev/AmdSevX64.dsc | 9 +-
OvmfPkg/OvmfPkgIa32.dsc | 5 +-
OvmfPkg/OvmfPkgIa32X64.dsc | 5 +-
OvmfPkg/OvmfPkgX64.dsc | 5 +-
OvmfPkg/AmdSev/AmdSevX64.fdf | 5 +-
OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierLibSevHashes.inf | 37 ++++
OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf | 24 +++
OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf | 2 +
OvmfPkg/ResetVector/ResetVector.inf | 2 +
OvmfPkg/Include/Library/BlobVerifierLib.h | 38 ++++
OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h | 11 ++
OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierSevHashes.c | 202 ++++++++++++++++++++
OvmfPkg/AmdSev/SecretDxe/SecretDxe.c | 2 +-
OvmfPkg/AmdSev/SecretPei/SecretPei.c | 3 +-
OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierNull.c | 33 ++++
OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c | 5 +
OvmfPkg/Library/{PlatformBootManagerLib => PlatformBootManagerLibGrub}/QemuKernel.c | 0
OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c | 9 +
OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 20 ++
OvmfPkg/ResetVector/ResetVector.nasmb | 2 +
23 files changed, 428 insertions(+), 10 deletions(-)
create mode 100644 OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierLibSevHashes.inf
create mode 100644 OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf
create mode 100644 OvmfPkg/Include/Library/BlobVerifierLib.h
create mode 100644 OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierSevHashes.c
create mode 100644 OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierNull.c
copy OvmfPkg/Library/{PlatformBootManagerLib => PlatformBootManagerLibGrub}/QemuKernel.c (100%)

--
2.25.1


[PATCH v5 10/11] OvmfPkg/AmdSev: add BlobVerifierLibSevHashes

Dov Murik
 

Add an implementation for BlobVerifierLib that locates the SEV hashes
table and verifies that the calculated hashes of the kernel, initrd, and
cmdline blobs indeed match the expected hashes stated in the hashes
table.

If there's a missing hash or a hash mismatch then EFI_ACCESS_DENIED is
returned which will cause a failure to load a kernel image.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Co-developed-by: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
---
OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierLibSevHashes.inf | 37=
++++
OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierSevHashes.c | 202=
++++++++++++++++++++
2 files changed, 239 insertions(+)

diff --git a/OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierLibSevHash=
es.inf b/OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierLibSevHashes.i=
nf
new file mode 100644
index 000000000000..76ca0b8154ce
--- /dev/null
+++ b/OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierLibSevHashes.inf
@@ -0,0 +1,37 @@
+## @file=0D
+#=0D
+# Blob verifier library that uses SEV hashes table. The hashes table hol=
ds the=0D
+# allowed hashes of the kernel, initrd, and cmdline blobs.=0D
+#=0D
+# Copyright (C) 2021, IBM Corp=0D
+#=0D
+# SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+#=0D
+##=0D
+=0D
+[Defines]=0D
+ INF_VERSION =3D 1.29=0D
+ BASE_NAME =3D BlobVerifierLibSevHashes=0D
+ FILE_GUID =3D 59e713b5-eff3-46a7-8d8b-46f4c004ad7b=
=0D
+ MODULE_TYPE =3D BASE=0D
+ VERSION_STRING =3D 1.0=0D
+ LIBRARY_CLASS =3D BlobVerifierLib=0D
+ CONSTRUCTOR =3D BlobVerifierLibSevHashesConstructor=0D
+=0D
+[Sources]=0D
+ BlobVerifierSevHashes.c=0D
+=0D
+[Packages]=0D
+ CryptoPkg/CryptoPkg.dec=0D
+ MdePkg/MdePkg.dec=0D
+ OvmfPkg/OvmfPkg.dec=0D
+=0D
+[LibraryClasses]=0D
+ BaseCryptLib=0D
+ BaseMemoryLib=0D
+ DebugLib=0D
+ PcdLib=0D
+=0D
+[FixedPcd]=0D
+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase=0D
+ gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize=0D
diff --git a/OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierSevHashes.=
c b/OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierSevHashes.c
new file mode 100644
index 000000000000..b9054879b07f
--- /dev/null
+++ b/OvmfPkg/AmdSev/BlobVerifierLibSevHashes/BlobVerifierSevHashes.c
@@ -0,0 +1,202 @@
+/** @file=0D
+=0D
+ Blob verifier library that uses SEV hashes table. The hashes table hold=
s the=0D
+ allowed hashes of the kernel, initrd, and cmdline blobs.=0D
+=0D
+ Copyright (C) 2021, IBM Corporation=0D
+=0D
+ SPDX-License-Identifier: BSD-2-Clause-Patent=0D
+**/=0D
+=0D
+#include <Library/BaseCryptLib.h>=0D
+#include <Library/BaseLib.h>=0D
+#include <Library/BaseMemoryLib.h>=0D
+#include <Library/DebugLib.h>=0D
+#include <Library/BlobVerifierLib.h>=0D
+=0D
+/**=0D
+ The SEV Hashes table must be in encrypted memory and has the table=0D
+ and its entries described by=0D
+=0D
+ <GUID>|UINT16 <len>|<data>=0D
+=0D
+ With the whole table GUID being 9438d606-4f22-4cc9-b479-a793d411fd21=0D
+=0D
+ The current possible table entries are for the kernel, the initrd=0D
+ and the cmdline:=0D
+=0D
+ 4de79437-abd2-427f-b835-d5b172d2045b kernel=0D
+ 44baf731-3a2f-4bd7-9af1-41e29169781d initrd=0D
+ 97d02dd8-bd20-4c94-aa78-e7714d36ab2a cmdline=0D
+=0D
+ The size of the entry is used to identify the hash, but the=0D
+ expectation is that it will be 32 bytes of SHA-256.=0D
+**/=0D
+=0D
+#define SEV_HASH_TABLE_GUID \=0D
+ (GUID) { 0x9438d606, 0x4f22, 0x4cc9, { 0xb4, 0x79, 0xa7, 0x93, 0xd4, 0x1=
1, 0xfd, 0x21 } }=0D
+#define SEV_KERNEL_HASH_GUID \=0D
+ (GUID) { 0x4de79437, 0xabd2, 0x427f, { 0xb8, 0x35, 0xd5, 0xb1, 0x72, 0xd=
2, 0x04, 0x5b } }=0D
+#define SEV_INITRD_HASH_GUID \=0D
+ (GUID) { 0x44baf731, 0x3a2f, 0x4bd7, { 0x9a, 0xf1, 0x41, 0xe2, 0x91, 0x6=
9, 0x78, 0x1d } }=0D
+#define SEV_CMDLINE_HASH_GUID \=0D
+ (GUID) { 0x97d02dd8, 0xbd20, 0x4c94, { 0xaa, 0x78, 0xe7, 0x71, 0x4d, 0x3=
6, 0xab, 0x2a } }=0D
+=0D
+STATIC CONST EFI_GUID mSevKernelHashGuid =3D SEV_KERNEL_HASH_GUID;=0D
+STATIC CONST EFI_GUID mSevInitrdHashGuid =3D SEV_INITRD_HASH_GUID;=0D
+STATIC CONST EFI_GUID mSevCmdlineHashGuid =3D SEV_CMDLINE_HASH_GUID;=0D
+=0D
+#pragma pack (1)=0D
+typedef struct {=0D
+ GUID Guid;=0D
+ UINT16 Len;=0D
+ UINT8 Data[];=0D
+} HASH_TABLE;=0D
+#pragma pack ()=0D
+=0D
+STATIC HASH_TABLE *mHashesTable;=0D
+STATIC UINT16 mHashesTableSize;=0D
+=0D
+STATIC=0D
+CONST GUID*=0D
+FindBlobEntryGuid (=0D
+ IN CONST CHAR16 *BlobName=0D
+ )=0D
+{=0D
+ if (StrCmp (BlobName, L"kernel") =3D=3D 0) {=0D
+ return &mSevKernelHashGuid;=0D
+ } else if (StrCmp (BlobName, L"initrd") =3D=3D 0) {=0D
+ return &mSevInitrdHashGuid;=0D
+ } else if (StrCmp (BlobName, L"cmdline") =3D=3D 0) {=0D
+ return &mSevCmdlineHashGuid;=0D
+ } else {=0D
+ return NULL;=0D
+ }=0D
+}=0D
+=0D
+/**=0D
+ Verify blob from an external source.=0D
+=0D
+ @param[in] BlobName The name of the blob=0D
+ @param[in] Buf The data of the blob=0D
+ @param[in] BufSize The size of the blob in bytes=0D
+=0D
+ @retval EFI_SUCCESS The blob was verified successfully.=0D
+ @retval EFI_ACCESS_DENIED The blob could not be verified, and theref=
ore=0D
+ should be considered non-secure.=0D
+**/=0D
+EFI_STATUS=0D
+EFIAPI=0D
+VerifyBlob (=0D
+ IN CONST CHAR16 *BlobName,=0D
+ IN CONST VOID *Buf,=0D
+ IN UINT32 BufSize=0D
+ )=0D
+{=0D
+ CONST GUID *Guid;=0D
+ INT32 Remaining;=0D
+ HASH_TABLE *Entry;=0D
+=0D
+ if (mHashesTable =3D=3D NULL || mHashesTableSize =3D=3D 0) {=0D
+ DEBUG ((DEBUG_ERROR,=0D
+ "%a: Verifier called but no hashes table discoverd in MEMFD\n",=0D
+ __FUNCTION__));=0D
+ return EFI_ACCESS_DENIED;=0D
+ }=0D
+=0D
+ Guid =3D FindBlobEntryGuid (BlobName);=0D
+ if (Guid =3D=3D NULL) {=0D
+ DEBUG ((DEBUG_ERROR, "%a: Unknown blob name \"%s\"\n", __FUNCTION__,=0D
+ BlobName));=0D
+ return EFI_ACCESS_DENIED;=0D
+ }=0D
+=0D
+ //=0D
+ // Remaining is INT32 to catch underflow in case Entry->Len has a=0D
+ // very high UINT16 value=0D
+ //=0D
+ for (Entry =3D mHashesTable, Remaining =3D mHashesTableSize;=0D
+ Remaining >=3D sizeof *Entry && Remaining >=3D Entry->Len;=0D
+ Remaining -=3D Entry->Len,=0D
+ Entry =3D (HASH_TABLE *)((UINT8 *)Entry + Entry->Len)) {=0D
+ UINTN EntrySize;=0D
+ EFI_STATUS Status;=0D
+ UINT8 Hash[SHA256_DIGEST_SIZE];=0D
+=0D
+ if (!CompareGuid (&Entry->Guid, Guid)) {=0D
+ continue;=0D
+ }=0D
+=0D
+ DEBUG ((DEBUG_INFO, "%a: Found GUID %g in table\n", __FUNCTION__, Guid=
));=0D
+=0D
+ EntrySize =3D Entry->Len - sizeof Entry->Guid - sizeof Entry->Len;=0D
+ if (EntrySize !=3D SHA256_DIGEST_SIZE) {=0D
+ DEBUG ((DEBUG_ERROR, "%a: Hash has the wrong size %d !=3D %d\n",=0D
+ __FUNCTION__, EntrySize, SHA256_DIGEST_SIZE));=0D
+ return EFI_ACCESS_DENIED;=0D
+ }=0D
+=0D
+ //=0D
+ // Calculate the buffer's hash and verify that it is identical to the=
=0D
+ // expected hash table entry=0D
+ //=0D
+ Sha256HashAll (Buf, BufSize, Hash);=0D
+=0D
+ if (CompareMem (Entry->Data, Hash, EntrySize) =3D=3D 0) {=0D
+ Status =3D EFI_SUCCESS;=0D
+ DEBUG ((DEBUG_INFO, "%a: Hash comparison succeeded for \"%s\"\n",=0D
+ __FUNCTION__, BlobName));=0D
+ } else {=0D
+ Status =3D EFI_ACCESS_DENIED;=0D
+ DEBUG ((DEBUG_ERROR, "%a: Hash comparison failed for \"%s\"\n",=0D
+ __FUNCTION__, BlobName));=0D
+ }=0D
+ return Status;=0D
+ }=0D
+=0D
+ DEBUG ((DEBUG_ERROR, "%a: Hash GUID %g not found in table\n", __FUNCTION=
__,=0D
+ Guid));=0D
+ return EFI_ACCESS_DENIED;=0D
+}=0D
+=0D
+/**=0D
+ Locate the SEV hashes table.=0D
+=0D
+ This function always returns success, even if the table can't be found. =
The=0D
+ subsequent VerifyBlob calls will fail if no table was found.=0D
+=0D
+ @retval RETURN_SUCCESS The hashes table is set up correctly, or there =
is no=0D
+ hashes table=0D
+**/=0D
+RETURN_STATUS=0D
+EFIAPI=0D
+BlobVerifierLibSevHashesConstructor (=0D
+ VOID=0D
+ )=0D
+{=0D
+ HASH_TABLE *Ptr;=0D
+ UINT32 Size;=0D
+=0D
+ mHashesTable =3D NULL;=0D
+ mHashesTableSize =3D 0;=0D
+=0D
+ Ptr =3D (void *)(UINTN)FixedPcdGet64 (PcdQemuHashTableBase);=0D
+ Size =3D FixedPcdGet32 (PcdQemuHashTableSize);=0D
+=0D
+ if (Ptr =3D=3D NULL || Size < sizeof *Ptr ||=0D
+ !CompareGuid (&Ptr->Guid, &SEV_HASH_TABLE_GUID) ||=0D
+ Ptr->Len < sizeof *Ptr || Ptr->Len > Size) {=0D
+ return RETURN_SUCCESS;=0D
+ }=0D
+=0D
+ DEBUG ((DEBUG_INFO, "%a: Found injected hashes table in secure location\=
n",=0D
+ __FUNCTION__));=0D
+=0D
+ mHashesTable =3D (HASH_TABLE *)Ptr->Data;=0D
+ mHashesTableSize =3D Ptr->Len - sizeof Ptr->Guid - sizeof Ptr->Len;=0D
+=0D
+ DEBUG ((DEBUG_VERBOSE, "%a: mHashesTable=3D0x%p, Size=3D%u\n", __FUNCTIO=
N__,=0D
+ mHashesTable, mHashesTableSize));=0D
+=0D
+ return RETURN_SUCCESS;=0D
+}=0D
--=20
2.25.1


[PATCH v5 05/11] OvmfPkg: add BlobVerifierLibNull to DSC

Dov Murik
 

This prepares the ground for calling VerifyBlob() in
QemuKernelLoaderFsDxe.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/AmdSev/AmdSevX64.dsc | 6 +++++-
OvmfPkg/OvmfPkgIa32.dsc | 5 ++++-
OvmfPkg/OvmfPkgIa32X64.dsc | 5 ++++-
OvmfPkg/OvmfPkgX64.dsc | 5 ++++-
4 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index aefdcf881c99..db8bd59579b9 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -173,6 +173,7 @@ [LibraryClasses]
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf=0D
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/Customize=
dDisplayLib.inf=0D
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltL=
ib.inf=0D
+ BlobVerifierLib|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.=
inf=0D
=0D
!if $(SOURCE_DEBUG_ENABLE) =3D=3D TRUE=0D
PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDeb=
ug/PeCoffExtraActionLibDebug.inf=0D
@@ -693,7 +694,10 @@ [Components]
NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf=0D
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanc=
eManagerUiLib.inf=0D
}=0D
- OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf=0D
+ OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {=0D
+ <LibraryClasses>=0D
+ NULL|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf=0D
+ }=0D
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf=0D
OvmfPkg/Virtio10Dxe/Virtio10.inf=0D
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf=0D
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f53efeae7986..799a974cf21a 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -786,7 +786,10 @@ [Components]
NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf=0D
!endif=0D
}=0D
- OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf=0D
+ OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {=0D
+ <LibraryClasses>=0D
+ NULL|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf=0D
+ }=0D
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf=0D
OvmfPkg/Virtio10Dxe/Virtio10.inf=0D
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf=0D
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index b3662e17f256..66ad5dc70cee 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -800,7 +800,10 @@ [Components.X64]
NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf=0D
!endif=0D
}=0D
- OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf=0D
+ OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {=0D
+ <LibraryClasses>=0D
+ NULL|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf=0D
+ }=0D
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf=0D
OvmfPkg/Virtio10Dxe/Virtio10.inf=0D
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf=0D
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 0a237a905866..180565a100c5 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -798,7 +798,10 @@ [Components]
NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf=0D
!endif=0D
}=0D
- OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf=0D
+ OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {=0D
+ <LibraryClasses>=0D
+ NULL|OvmfPkg/Library/BlobVerifierLibNull/BlobVerifierLibNull.inf=0D
+ }=0D
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf=0D
OvmfPkg/Virtio10Dxe/Virtio10.inf=0D
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf=0D
--=20
2.25.1


[PATCH v5 03/11] OvmfPkg: PlatformBootManagerLibGrub: Allow executing kernel via fw_cfg

Dov Murik
 

From: James Bottomley <jejb@linux.ibm.com>

Support QEMU's -kernel option.

Create a QemuKernel.c for PlatformBootManagerLibGrub
which is an exact copy of the file
PlatformBootManagerLib/QemuKernel.c .

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
---
OvmfPkg/AmdSev/AmdSevX64.dsc =
| 1 +
OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf =
| 2 ++
OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h =
| 11 +++++++++++
OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c =
| 5 +++++
OvmfPkg/Library/{PlatformBootManagerLib =3D> PlatformBootManagerLibGrub}/Q=
emuKernel.c | 0
5 files changed, 19 insertions(+)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index a2f1324c40a6..aefdcf881c99 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -281,6 +281,7 @@ [LibraryClasses.common.PEIM]
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuE=
xceptionHandlerLib.inf=0D
MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf=0D
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf=
=0D
+ QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoad=
ImageLib.inf=0D
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf=0D
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf=0D
=0D
diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManager=
LibGrub.inf b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManage=
rLibGrub.inf
index 9a806d17ec45..5f6f73d18470 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub=
.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub=
.inf
@@ -23,6 +23,7 @@ [Defines]
=0D
[Sources]=0D
BdsPlatform.c=0D
+ QemuKernel.c=0D
PlatformData.c=0D
BdsPlatform.h=0D
=0D
@@ -46,6 +47,7 @@ [LibraryClasses]
BootLogoLib=0D
DevicePathLib=0D
PciLib=0D
+ QemuLoadImageLib=0D
UefiLib=0D
PlatformBmPrintScLib=0D
Tcg2PhysicalPresenceLib=0D
diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h b/Ovm=
fPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
index 748c63081920..f1d3a2906c00 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
@@ -172,4 +172,15 @@ PlatformInitializeConsole (
IN PLATFORM_CONSOLE_CONNECT_ENTRY *PlatformConsole=0D
);=0D
=0D
+/**=0D
+ Loads and boots UEFI Linux via the FwCfg interface.=0D
+=0D
+ @retval EFI_NOT_FOUND - The Linux kernel was not found=0D
+=0D
+**/=0D
+EFI_STATUS=0D
+TryRunningQemuKernel (=0D
+ VOID=0D
+ );=0D
+=0D
#endif // _PLATFORM_SPECIFIC_BDS_PLATFORM_H_=0D
diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c b/Ovm=
fPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
index 5c92d4fc2b09..7cceeea4879c 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
@@ -1315,6 +1315,11 @@ PlatformBootManagerAfterConsole (
//=0D
Tcg2PhysicalPresenceLibProcessRequest (NULL);=0D
=0D
+ //=0D
+ // Process QEMU's -kernel command line option=0D
+ //=0D
+ TryRunningQemuKernel ();=0D
+=0D
//=0D
// Perform some platform specific connect sequence=0D
//=0D
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c b/OvmfPkg/=
Library/PlatformBootManagerLibGrub/QemuKernel.c
similarity index 100%
copy from OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
copy to OvmfPkg/Library/PlatformBootManagerLibGrub/QemuKernel.c
--=20
2.25.1


[PATCH v5 07/11] OvmfPkg/QemuKernelLoaderFsDxe: call VerifyBlob after fetch from fw_cfg

Dov Murik
 

In QemuKernelLoaderFsDxeEntrypoint we use FetchBlob to read the content
of the kernel/initrd/cmdline from the QEMU fw_cfg interface. Insert a
call to VerifyBlob after fetching to allow BlobVerifierLib
implementations to add a verification step for these blobs.

This will allow confidential computing OVMF builds to add verification
mechanisms for these blobs that originate from an untrusted source
(QEMU).

The null implementation of BlobVerifierLib does nothing in VerifyBlob,
and therefore no functional change is expected.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Co-developed-by: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
---
OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c b/OvmfPk=
g/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
index c7ddd86f5c75..6832d563bcb0 100644
--- a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
+++ b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
@@ -17,6 +17,7 @@
#include <Guid/QemuKernelLoaderFsMedia.h>=0D
#include <Library/BaseLib.h>=0D
#include <Library/BaseMemoryLib.h>=0D
+#include <Library/BlobVerifierLib.h>=0D
#include <Library/DebugLib.h>=0D
#include <Library/DevicePathLib.h>=0D
#include <Library/MemoryAllocationLib.h>=0D
@@ -1039,6 +1040,14 @@ QemuKernelLoaderFsDxeEntrypoint (
if (EFI_ERROR (Status)) {=0D
goto FreeBlobs;=0D
}=0D
+ Status =3D VerifyBlob (=0D
+ CurrentBlob->Name,=0D
+ CurrentBlob->Data,=0D
+ CurrentBlob->Size=0D
+ );=0D
+ if (EFI_ERROR (Status)) {=0D
+ goto FreeBlobs;=0D
+ }=0D
mTotalBlobBytes +=3D CurrentBlob->Size;=0D
}=0D
KernelBlob =3D &mKernelBlob[KernelBlobTypeKernel];=0D
--=20
2.25.1


[PATCH v5 02/11] OvmfPkg/AmdSev: use GenericQemuLoadImageLib in AmdSev builds

Dov Murik
 

Newer kernels support efistub and therefore don't need all the legacy
stuff in X86QemuLoadImageLib, which are harder to secure. Specifically
the verification of kernel/initrd/cmdline blobs will be added only to
the GenericQemuLoadImageLib implementation, so use that for SEV builds.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ashish Kalra <ashish.kalra@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3457
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
---
OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index 1d487befae08..a2f1324c40a6 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -368,7 +368,7 @@ [LibraryClasses.common.DXE_DRIVER]
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf=0D
MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf=0D
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf=
=0D
- QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib=
.inf=0D
+ QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoad=
ImageLib.inf=0D
!if $(TPM_ENABLE) =3D=3D TRUE=0D
Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibTcg/Tpm12DeviceLibTcg.i=
nf=0D
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.in=
f=0D
--=20
2.25.1


[PATCH v2 3/3] OvmfPkg/ResetVector: add the macro to request guest termination

Brijesh Singh
 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275

The upcoming SEV-SNP support will need to make a few additional guest
termination requests depending on the failure type. Let's move the logic
to request the guest termination into a macro to keep the code readable.

Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
OvmfPkg/ResetVector/Ia32/AmdSev.asm | 87 +++++++++++++++--------------
1 file changed, 45 insertions(+), 42 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
index 93ba917f36d2..aa95d06eaddb 100644
--- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -38,6 +38,13 @@ BITS 32
%define SEV_GHCB_MSR 0xc0010130
%define SEV_STATUS_MSR 0xc0010131

+; The #VC was not for CPUID
+%define TERM_VC_NOT_CPUID 1
+
+; The unexpected response code
+%define TERM_UNEXPECTED_RESP_CODE 2
+
+
; Macro is used to issue the MSR protocol based VMGEXIT. The caller is
; responsible to populate values in the EDX:EAX registers. After the vmmcall
; returns, it verifies that the response code matches with the expected
@@ -73,6 +80,43 @@ BITS 32
jne SevEsUnexpectedRespTerminate
%endmacro

+; Macro to terminate the guest using the VMGEXIT.
+; arg 1: reason code
+%macro TerminateVmgExit 1
+ mov eax, %1
+ ;
+ ; Use VMGEXIT to request termination. At this point the reason code is
+ ; located in EAX, so shift it left 16 bits to the proper location.
+ ;
+ ; EAX[11:0] => 0x100 - request termination
+ ; EAX[15:12] => 0x1 - OVMF
+ ; EAX[23:16] => 0xXX - REASON CODE
+ ;
+ shl eax, 16
+ or eax, 0x1100
+ xor edx, edx
+ mov ecx, SEV_GHCB_MSR
+ wrmsr
+ ;
+ ; Issue VMGEXIT - NASM doesn't support the vmmcall instruction in 32-bit
+ ; mode, so work around this by temporarily switching to 64-bit mode.
+ ;
+BITS 64
+ rep vmmcall
+BITS 32
+
+ ;
+ ; We shouldn't come back from the VMGEXIT, but if we do, just loop.
+ ;
+%%TerminateHlt:
+ hlt
+ jmp %%TerminateHlt
+%endmacro
+
+; Terminate the guest due to unexpected response code.
+SevEsUnexpectedRespTerminate:
+ TerminateVmgExit TERM_UNEXPECTED_RESP_CODE
+
; Check if Secure Encrypted Virtualization (SEV) features are enabled.
;
; Register usage is tight in this routine, so multiple calls for the
@@ -227,48 +271,7 @@ SevEsDisabled:
;

SevEsIdtNotCpuid:
- ;
- ; Use VMGEXIT to request termination.
- ; 1 - #VC was not for CPUID
- ;
- mov eax, 1
- jmp SevEsIdtTerminate
-
-SevEsUnexpectedRespTerminate:
- ;
- ; Use VMGEXIT to request termination.
- ; 2 - Unexpected Response is received
- ;
- mov eax, 2
-
-SevEsIdtTerminate:
- ;
- ; Use VMGEXIT to request termination. At this point the reason code is
- ; located in EAX, so shift it left 16 bits to the proper location.
- ;
- ; EAX[11:0] => 0x100 - request termination
- ; EAX[15:12] => 0x1 - OVMF
- ; EAX[23:16] => 0xXX - REASON CODE
- ;
- shl eax, 16
- or eax, 0x1100
- xor edx, edx
- mov ecx, SEV_GHCB_MSR
- wrmsr
- ;
- ; Issue VMGEXIT - NASM doesn't support the vmmcall instruction in 32-bit
- ; mode, so work around this by temporarily switching to 64-bit mode.
- ;
-BITS 64
- rep vmmcall
-BITS 32
-
- ;
- ; We shouldn't come back from the VMGEXIT, but if we do, just loop.
- ;
-SevEsIdtHlt:
- hlt
- jmp SevEsIdtHlt
+ TerminateVmgExit TERM_VC_NOT_CPUID
iret

;
--
2.17.1


[PATCH v2 2/3] OvmfPkg/ResetVector: add the macro to invoke MSR protocol based VMGEXIT

Brijesh Singh
 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275

The upcoming SEV-SNP support will need to make a few additional MSR
protocol based VMGEXIT's. Add a macro that wraps the common setup and
response validation logic in one place to keep the code readable.

While at it, define SEV_STATUS_MSR that will be used to get the SEV STATUS
MSR instead of open coding it.

Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
OvmfPkg/ResetVector/Ia32/AmdSev.asm | 71 +++++++++++++++++++----------
1 file changed, 47 insertions(+), 24 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
index 2c9d990af55f..93ba917f36d2 100644
--- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -35,6 +35,44 @@ BITS 32
%define CPUID_INSN_LEN 2


+%define SEV_GHCB_MSR 0xc0010130
+%define SEV_STATUS_MSR 0xc0010131
+
+; Macro is used to issue the MSR protocol based VMGEXIT. The caller is
+; responsible to populate values in the EDX:EAX registers. After the vmmcall
+; returns, it verifies that the response code matches with the expected
+; code. If it does not match then terminate the guest. The result of request
+; is returned in the EDX:EAX.
+;
+; args 1:Request code, 2: Response code
+%macro VmgExit 2
+ ;
+ ; Add request code:
+ ; GHCB_MSR[11:0] = Request code
+ or eax, %1
+
+ mov ecx, SEV_GHCB_MSR
+ wrmsr
+
+ ; Issue VMGEXIT - NASM doesn't support the vmmcall instruction in 32-bit
+ ; mode, so work around this by temporarily switching to 64-bit mode.
+ ;
+BITS 64
+ rep vmmcall
+BITS 32
+
+ mov ecx, SEV_GHCB_MSR
+ rdmsr
+
+ ;
+ ; Verify the reponse code, if it does not match then request to terminate
+ ; GHCB_MSR[11:0] = Response code
+ mov ecx, eax
+ and ecx, 0xfff
+ cmp ecx, %2
+ jne SevEsUnexpectedRespTerminate
+%endmacro
+
; Check if Secure Encrypted Virtualization (SEV) features are enabled.
;
; Register usage is tight in this routine, so multiple calls for the
@@ -84,7 +122,7 @@ CheckSevFeatures:

; Check if SEV memory encryption is enabled
; MSR_0xC0010131 - Bit 0 (SEV enabled)
- mov ecx, 0xc0010131
+ mov ecx, SEV_STATUS_MSR
rdmsr
bt eax, 0
jnc NoSev
@@ -99,7 +137,7 @@ CheckSevFeatures:

; Check if SEV-ES is enabled
; MSR_0xC0010131 - Bit 1 (SEV-ES enabled)
- mov ecx, 0xc0010131
+ mov ecx, SEV_STATUS_MSR
rdmsr
bt eax, 1
jnc GetSevEncBit
@@ -196,10 +234,10 @@ SevEsIdtNotCpuid:
mov eax, 1
jmp SevEsIdtTerminate

-SevEsIdtNoCpuidResponse:
+SevEsUnexpectedRespTerminate:
;
; Use VMGEXIT to request termination.
- ; 2 - GHCB_CPUID_RESPONSE not received
+ ; 2 - Unexpected Response is received
;
mov eax, 2

@@ -215,7 +253,7 @@ SevEsIdtTerminate:
shl eax, 16
or eax, 0x1100
xor edx, edx
- mov ecx, 0xc0010130
+ mov ecx, SEV_GHCB_MSR
wrmsr
;
; Issue VMGEXIT - NASM doesn't support the vmmcall instruction in 32-bit
@@ -275,7 +313,7 @@ SevEsIdtVmmComm:
mov [esp + VC_CPUID_REQUEST_REGISTER], eax

; Save current GHCB MSR value
- mov ecx, 0xc0010130
+ mov ecx, SEV_GHCB_MSR
rdmsr
mov [esp + VC_GHCB_MSR_EAX], eax
mov [esp + VC_GHCB_MSR_EDX], edx
@@ -292,31 +330,16 @@ NextReg:
jge VmmDone

shl eax, GHCB_CPUID_REGISTER_SHIFT
- or eax, GHCB_CPUID_REQUEST
mov edx, [esp + VC_CPUID_FUNCTION]
- mov ecx, 0xc0010130
- wrmsr

- ;
- ; Issue VMGEXIT - NASM doesn't support the vmmcall instruction in 32-bit
- ; mode, so work around this by temporarily switching to 64-bit mode.
- ;
-BITS 64
- rep vmmcall
-BITS 32
+ VmgExit GHCB_CPUID_REQUEST, GHCB_CPUID_RESPONSE

;
- ; Read GHCB MSR
+ ; Response GHCB MSR
; GHCB_MSR[63:32] = CPUID register value
; GHCB_MSR[31:30] = CPUID register
; GHCB_MSR[11:0] = CPUID response protocol
;
- mov ecx, 0xc0010130
- rdmsr
- mov ecx, eax
- and ecx, 0xfff
- cmp ecx, GHCB_CPUID_RESPONSE
- jne SevEsIdtNoCpuidResponse

; Save returned value
shr eax, GHCB_CPUID_REGISTER_SHIFT
@@ -334,7 +357,7 @@ VmmDone:
;
mov eax, [esp + VC_GHCB_MSR_EAX]
mov edx, [esp + VC_GHCB_MSR_EDX]
- mov ecx, 0xc0010130
+ mov ecx, SEV_GHCB_MSR
wrmsr

mov eax, [esp + VC_CPUID_RESULT_EAX]
--
2.17.1


[PATCH v2 1/3] OvmfPkg/ResetVector: move SEV specific code in a separate file

Brijesh Singh
 

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275

The PageTables64.asm was created to provide routines to set the CR3
register for 64-bit paging. During the SEV support, it grew to include a
lot of the SEV stuff. Before adding more SEV features, let's move all
the SEV-specific routines into a separate file.

No functionality change intended.

Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
.../Ia32/{PageTables64.asm => AmdSev.asm} | 145 +------
OvmfPkg/ResetVector/Ia32/PageTables64.asm | 391 ------------------
OvmfPkg/ResetVector/ResetVector.nasmb | 1 +
3 files changed, 3 insertions(+), 534 deletions(-)
copy OvmfPkg/ResetVector/Ia32/{PageTables64.asm => AmdSev.asm} (70%)

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
similarity index 70%
copy from OvmfPkg/ResetVector/Ia32/PageTables64.asm
copy to OvmfPkg/ResetVector/Ia32/AmdSev.asm
index 5fae8986d9da..2c9d990af55f 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -1,42 +1,14 @@
;------------------------------------------------------------------------------
; @file
-; Sets the CR3 register for 64-bit paging
+; Provide the functions to check whether SEV and SEV-ES is enabled.
;
-; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
-; Copyright (c) 2017 - 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
+; Copyright (c) 2017 - 2021, Advanced Micro Devices, Inc. All rights reserved.<BR>
; SPDX-License-Identifier: BSD-2-Clause-Patent
;
;------------------------------------------------------------------------------

BITS 32

-%define PAGE_PRESENT 0x01
-%define PAGE_READ_WRITE 0x02
-%define PAGE_USER_SUPERVISOR 0x04
-%define PAGE_WRITE_THROUGH 0x08
-%define PAGE_CACHE_DISABLE 0x010
-%define PAGE_ACCESSED 0x020
-%define PAGE_DIRTY 0x040
-%define PAGE_PAT 0x080
-%define PAGE_GLOBAL 0x0100
-%define PAGE_2M_MBO 0x080
-%define PAGE_2M_PAT 0x01000
-
-%define PAGE_4K_PDE_ATTR (PAGE_ACCESSED + \
- PAGE_DIRTY + \
- PAGE_READ_WRITE + \
- PAGE_PRESENT)
-
-%define PAGE_2M_PDE_ATTR (PAGE_2M_MBO + \
- PAGE_ACCESSED + \
- PAGE_DIRTY + \
- PAGE_READ_WRITE + \
- PAGE_PRESENT)
-
-%define PAGE_PDP_ATTR (PAGE_ACCESSED + \
- PAGE_READ_WRITE + \
- PAGE_PRESENT)
-
;
; SEV-ES #VC exception handler support
;
@@ -213,119 +185,6 @@ IsSevEsEnabled:
SevEsDisabled:
OneTimeCallRet IsSevEsEnabled

-;
-; Modified: EAX, EBX, ECX, EDX
-;
-SetCr3ForPageTables64:
-
- OneTimeCall CheckSevFeatures
- xor edx, edx
- test eax, eax
- jz SevNotActive
-
- ; If SEV is enabled, C-bit is always above 31
- sub eax, 32
- bts edx, eax
-
-SevNotActive:
-
- ;
- ; For OVMF, build some initial page tables at
- ; PcdOvmfSecPageTablesBase - (PcdOvmfSecPageTablesBase + 0x6000).
- ;
- ; This range should match with PcdOvmfSecPageTablesSize which is
- ; declared in the FDF files.
- ;
- ; At the end of PEI, the pages tables will be rebuilt into a
- ; more permanent location by DxeIpl.
- ;
-
- mov ecx, 6 * 0x1000 / 4
- xor eax, eax
-clearPageTablesMemoryLoop:
- mov dword[ecx * 4 + PT_ADDR (0) - 4], eax
- loop clearPageTablesMemoryLoop
-
- ;
- ; Top level Page Directory Pointers (1 * 512GB entry)
- ;
- mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDP_ATTR
- mov dword[PT_ADDR (4)], edx
-
- ;
- ; Next level Page Directory Pointers (4 * 1GB entries => 4GB)
- ;
- mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + PAGE_PDP_ATTR
- mov dword[PT_ADDR (0x1004)], edx
- mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) + PAGE_PDP_ATTR
- mov dword[PT_ADDR (0x100C)], edx
- mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) + PAGE_PDP_ATTR
- mov dword[PT_ADDR (0x1014)], edx
- mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) + PAGE_PDP_ATTR
- mov dword[PT_ADDR (0x101C)], edx
-
- ;
- ; Page Table Entries (2048 * 2MB entries => 4GB)
- ;
- mov ecx, 0x800
-pageTableEntriesLoop:
- mov eax, ecx
- dec eax
- shl eax, 21
- add eax, PAGE_2M_PDE_ATTR
- mov [ecx * 8 + PT_ADDR (0x2000 - 8)], eax
- mov [(ecx * 8 + PT_ADDR (0x2000 - 8)) + 4], edx
- loop pageTableEntriesLoop
-
- OneTimeCall IsSevEsEnabled
- test eax, eax
- jz SetCr3
-
- ;
- ; The initial GHCB will live at GHCB_BASE and needs to be un-encrypted.
- ; This requires the 2MB page for this range be broken down into 512 4KB
- ; pages. All will be marked encrypted, except for the GHCB.
- ;
- mov ecx, (GHCB_BASE >> 21)
- mov eax, GHCB_PT_ADDR + PAGE_PDP_ATTR
- mov [ecx * 8 + PT_ADDR (0x2000)], eax
-
- ;
- ; Page Table Entries (512 * 4KB entries => 2MB)
- ;
- mov ecx, 512
-pageTableEntries4kLoop:
- mov eax, ecx
- dec eax
- shl eax, 12
- add eax, GHCB_BASE & 0xFFE0_0000
- add eax, PAGE_4K_PDE_ATTR
- mov [ecx * 8 + GHCB_PT_ADDR - 8], eax
- mov [(ecx * 8 + GHCB_PT_ADDR - 8) + 4], edx
- loop pageTableEntries4kLoop
-
- ;
- ; Clear the encryption bit from the GHCB entry
- ;
- mov ecx, (GHCB_BASE & 0x1F_FFFF) >> 12
- mov [ecx * 8 + GHCB_PT_ADDR + 4], strict dword 0
-
- mov ecx, GHCB_SIZE / 4
- xor eax, eax
-clearGhcbMemoryLoop:
- mov dword[ecx * 4 + GHCB_BASE - 4], eax
- loop clearGhcbMemoryLoop
-
-SetCr3:
- ;
- ; Set CR3 now that the paging structures are available
- ;
- mov eax, PT_ADDR (0)
- mov cr3, eax
-
- OneTimeCallRet SetCr3ForPageTables64
-
-;
; Start of #VC exception handling routines
;

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 5fae8986d9da..eacdb69ddb9f 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -37,182 +37,6 @@ BITS 32
PAGE_READ_WRITE + \
PAGE_PRESENT)

-;
-; SEV-ES #VC exception handler support
-;
-; #VC handler local variable locations
-;
-%define VC_CPUID_RESULT_EAX 0
-%define VC_CPUID_RESULT_EBX 4
-%define VC_CPUID_RESULT_ECX 8
-%define VC_CPUID_RESULT_EDX 12
-%define VC_GHCB_MSR_EDX 16
-%define VC_GHCB_MSR_EAX 20
-%define VC_CPUID_REQUEST_REGISTER 24
-%define VC_CPUID_FUNCTION 28
-
-; #VC handler total local variable size
-;
-%define VC_VARIABLE_SIZE 32
-
-; #VC handler GHCB CPUID request/response protocol values
-;
-%define GHCB_CPUID_REQUEST 4
-%define GHCB_CPUID_RESPONSE 5
-%define GHCB_CPUID_REGISTER_SHIFT 30
-%define CPUID_INSN_LEN 2
-
-
-; Check if Secure Encrypted Virtualization (SEV) features are enabled.
-;
-; Register usage is tight in this routine, so multiple calls for the
-; same CPUID and MSR data are performed to keep things simple.
-;
-; Modified: EAX, EBX, ECX, EDX, ESP
-;
-; If SEV is enabled then EAX will be at least 32.
-; If SEV is disabled then EAX will be zero.
-;
-CheckSevFeatures:
- ; Set the first byte of the workarea to zero to communicate to the SEC
- ; phase that SEV-ES is not enabled. If SEV-ES is enabled, the CPUID
- ; instruction will trigger a #VC exception where the first byte of the
- ; workarea will be set to one or, if CPUID is not being intercepted,
- ; the MSR check below will set the first byte of the workarea to one.
- mov byte[SEV_ES_WORK_AREA], 0
-
- ;
- ; Set up exception handlers to check for SEV-ES
- ; Load temporary RAM stack based on PCDs (see SevEsIdtVmmComm for
- ; stack usage)
- ; Establish exception handlers
- ;
- mov esp, SEV_ES_VC_TOP_OF_STACK
- mov eax, ADDR_OF(Idtr)
- lidt [cs:eax]
-
- ; Check if we have a valid (0x8000_001F) CPUID leaf
- ; CPUID raises a #VC exception if running as an SEV-ES guest
- mov eax, 0x80000000
- cpuid
-
- ; This check should fail on Intel or Non SEV AMD CPUs. In future if
- ; Intel CPUs supports this CPUID leaf then we are guranteed to have exact
- ; same bit definition.
- cmp eax, 0x8000001f
- jl NoSev
-
- ; Check for SEV memory encryption feature:
- ; CPUID Fn8000_001F[EAX] - Bit 1
- ; CPUID raises a #VC exception if running as an SEV-ES guest
- mov eax, 0x8000001f
- cpuid
- bt eax, 1
- jnc NoSev
-
- ; Check if SEV memory encryption is enabled
- ; MSR_0xC0010131 - Bit 0 (SEV enabled)
- mov ecx, 0xc0010131
- rdmsr
- bt eax, 0
- jnc NoSev
-
- ; Check for SEV-ES memory encryption feature:
- ; CPUID Fn8000_001F[EAX] - Bit 3
- ; CPUID raises a #VC exception if running as an SEV-ES guest
- mov eax, 0x8000001f
- cpuid
- bt eax, 3
- jnc GetSevEncBit
-
- ; Check if SEV-ES is enabled
- ; MSR_0xC0010131 - Bit 1 (SEV-ES enabled)
- mov ecx, 0xc0010131
- rdmsr
- bt eax, 1
- jnc GetSevEncBit
-
- ; Set the first byte of the workarea to one to communicate to the SEC
- ; phase that SEV-ES is enabled.
- mov byte[SEV_ES_WORK_AREA], 1
-
-GetSevEncBit:
- ; Get pte bit position to enable memory encryption
- ; CPUID Fn8000_001F[EBX] - Bits 5:0
- ;
- and ebx, 0x3f
- mov eax, ebx
-
- ; The encryption bit position is always above 31
- sub ebx, 32
- jns SevSaveMask
-
- ; Encryption bit was reported as 31 or below, enter a HLT loop
-SevEncBitLowHlt:
- cli
- hlt
- jmp SevEncBitLowHlt
-
-SevSaveMask:
- xor edx, edx
- bts edx, ebx
-
- mov dword[SEV_ES_WORK_AREA_ENC_MASK], 0
- mov dword[SEV_ES_WORK_AREA_ENC_MASK + 4], edx
- jmp SevExit
-
-NoSev:
- ;
- ; Perform an SEV-ES sanity check by seeing if a #VC exception occurred.
- ;
- cmp byte[SEV_ES_WORK_AREA], 0
- jz NoSevPass
-
- ;
- ; A #VC was received, yet CPUID indicates no SEV-ES support, something
- ; isn't right.
- ;
-NoSevEsVcHlt:
- cli
- hlt
- jmp NoSevEsVcHlt
-
-NoSevPass:
- xor eax, eax
-
-SevExit:
- ;
- ; Clear exception handlers and stack
- ;
- push eax
- mov eax, ADDR_OF(IdtrClear)
- lidt [cs:eax]
- pop eax
- mov esp, 0
-
- OneTimeCallRet CheckSevFeatures
-
-; Check if Secure Encrypted Virtualization - Encrypted State (SEV-ES) feature
-; is enabled.
-;
-; Modified: EAX
-;
-; If SEV-ES is enabled then EAX will be non-zero.
-; If SEV-ES is disabled then EAX will be zero.
-;
-IsSevEsEnabled:
- xor eax, eax
-
- ; During CheckSevFeatures, the SEV_ES_WORK_AREA was set to 1 if
- ; SEV-ES is enabled.
- cmp byte[SEV_ES_WORK_AREA], 1
- jne SevEsDisabled
-
- mov eax, 1
-
-SevEsDisabled:
- OneTimeCallRet IsSevEsEnabled
-
;
; Modified: EAX, EBX, ECX, EDX
;
@@ -324,218 +148,3 @@ SetCr3:
mov cr3, eax

OneTimeCallRet SetCr3ForPageTables64
-
-;
-; Start of #VC exception handling routines
-;
-
-SevEsIdtNotCpuid:
- ;
- ; Use VMGEXIT to request termination.
- ; 1 - #VC was not for CPUID
- ;
- mov eax, 1
- jmp SevEsIdtTerminate
-
-SevEsIdtNoCpuidResponse:
- ;
- ; Use VMGEXIT to request termination.
- ; 2 - GHCB_CPUID_RESPONSE not received
- ;
- mov eax, 2
-
-SevEsIdtTerminate:
- ;
- ; Use VMGEXIT to request termination. At this point the reason code is
- ; located in EAX, so shift it left 16 bits to the proper location.
- ;
- ; EAX[11:0] => 0x100 - request termination
- ; EAX[15:12] => 0x1 - OVMF
- ; EAX[23:16] => 0xXX - REASON CODE
- ;
- shl eax, 16
- or eax, 0x1100
- xor edx, edx
- mov ecx, 0xc0010130
- wrmsr
- ;
- ; Issue VMGEXIT - NASM doesn't support the vmmcall instruction in 32-bit
- ; mode, so work around this by temporarily switching to 64-bit mode.
- ;
-BITS 64
- rep vmmcall
-BITS 32
-
- ;
- ; We shouldn't come back from the VMGEXIT, but if we do, just loop.
- ;
-SevEsIdtHlt:
- hlt
- jmp SevEsIdtHlt
- iret
-
- ;
- ; Total stack usage for the #VC handler is 44 bytes:
- ; - 12 bytes for the exception IRET (after popping error code)
- ; - 32 bytes for the local variables.
- ;
-SevEsIdtVmmComm:
- ;
- ; If we're here, then we are an SEV-ES guest and this
- ; was triggered by a CPUID instruction
- ;
- ; Set the first byte of the workarea to one to communicate that
- ; a #VC was taken.
- mov byte[SEV_ES_WORK_AREA], 1
-
- pop ecx ; Error code
- cmp ecx, 0x72 ; Be sure it was CPUID
- jne SevEsIdtNotCpuid
-
- ; Set up local variable room on the stack
- ; CPUID function : + 28
- ; CPUID request register : + 24
- ; GHCB MSR (EAX) : + 20
- ; GHCB MSR (EDX) : + 16
- ; CPUID result (EDX) : + 12
- ; CPUID result (ECX) : + 8
- ; CPUID result (EBX) : + 4
- ; CPUID result (EAX) : + 0
- sub esp, VC_VARIABLE_SIZE
-
- ; Save the CPUID function being requested
- mov [esp + VC_CPUID_FUNCTION], eax
-
- ; The GHCB CPUID protocol uses the following mapping to request
- ; a specific register:
- ; 0 => EAX, 1 => EBX, 2 => ECX, 3 => EDX
- ;
- ; Set EAX as the first register to request. This will also be used as a
- ; loop variable to request all register values (EAX to EDX).
- xor eax, eax
- mov [esp + VC_CPUID_REQUEST_REGISTER], eax
-
- ; Save current GHCB MSR value
- mov ecx, 0xc0010130
- rdmsr
- mov [esp + VC_GHCB_MSR_EAX], eax
- mov [esp + VC_GHCB_MSR_EDX], edx
-
-NextReg:
- ;
- ; Setup GHCB MSR
- ; GHCB_MSR[63:32] = CPUID function
- ; GHCB_MSR[31:30] = CPUID register
- ; GHCB_MSR[11:0] = CPUID request protocol
- ;
- mov eax, [esp + VC_CPUID_REQUEST_REGISTER]
- cmp eax, 4
- jge VmmDone
-
- shl eax, GHCB_CPUID_REGISTER_SHIFT
- or eax, GHCB_CPUID_REQUEST
- mov edx, [esp + VC_CPUID_FUNCTION]
- mov ecx, 0xc0010130
- wrmsr
-
- ;
- ; Issue VMGEXIT - NASM doesn't support the vmmcall instruction in 32-bit
- ; mode, so work around this by temporarily switching to 64-bit mode.
- ;
-BITS 64
- rep vmmcall
-BITS 32
-
- ;
- ; Read GHCB MSR
- ; GHCB_MSR[63:32] = CPUID register value
- ; GHCB_MSR[31:30] = CPUID register
- ; GHCB_MSR[11:0] = CPUID response protocol
- ;
- mov ecx, 0xc0010130
- rdmsr
- mov ecx, eax
- and ecx, 0xfff
- cmp ecx, GHCB_CPUID_RESPONSE
- jne SevEsIdtNoCpuidResponse
-
- ; Save returned value
- shr eax, GHCB_CPUID_REGISTER_SHIFT
- mov [esp + eax * 4], edx
-
- ; Next register
- inc word [esp + VC_CPUID_REQUEST_REGISTER]
-
- jmp NextReg
-
-VmmDone:
- ;
- ; At this point we have all CPUID register values. Restore the GHCB MSR,
- ; set the return register values and return.
- ;
- mov eax, [esp + VC_GHCB_MSR_EAX]
- mov edx, [esp + VC_GHCB_MSR_EDX]
- mov ecx, 0xc0010130
- wrmsr
-
- mov eax, [esp + VC_CPUID_RESULT_EAX]
- mov ebx, [esp + VC_CPUID_RESULT_EBX]
- mov ecx, [esp + VC_CPUID_RESULT_ECX]
- mov edx, [esp + VC_CPUID_RESULT_EDX]
-
- add esp, VC_VARIABLE_SIZE
-
- ; Update the EIP value to skip over the now handled CPUID instruction
- ; (the CPUID instruction has a length of 2)
- add word [esp], CPUID_INSN_LEN
- iret
-
-ALIGN 2
-
-Idtr:
- dw IDT_END - IDT_BASE - 1 ; Limit
- dd ADDR_OF(IDT_BASE) ; Base
-
-IdtrClear:
- dw 0 ; Limit
- dd 0 ; Base
-
-ALIGN 16
-
-;
-; The Interrupt Descriptor Table (IDT)
-; This will be used to determine if SEV-ES is enabled. Upon execution
-; of the CPUID instruction, a VMM Communication Exception will occur.
-; This will tell us if SEV-ES is enabled. We can use the current value
-; of the GHCB MSR to determine the SEV attributes.
-;
-IDT_BASE:
-;
-; Vectors 0 - 28 (No handlers)
-;
-%rep 29
- dw 0 ; Offset low bits 15..0
- dw 0x10 ; Selector
- db 0 ; Reserved
- db 0x8E ; Gate Type (IA32_IDT_GATE_TYPE_INTERRUPT_32)
- dw 0 ; Offset high bits 31..16
-%endrep
-;
-; Vector 29 (VMM Communication Exception)
-;
- dw (ADDR_OF(SevEsIdtVmmComm) & 0xffff) ; Offset low bits 15..0
- dw 0x10 ; Selector
- db 0 ; Reserved
- db 0x8E ; Gate Type (IA32_IDT_GATE_TYPE_INTERRUPT_32)
- dw (ADDR_OF(SevEsIdtVmmComm) >> 16) ; Offset high bits 31..16
-;
-; Vectors 30 - 31 (No handlers)
-;
-%rep 2
- dw 0 ; Offset low bits 15..0
- dw 0x10 ; Selector
- db 0 ; Reserved
- db 0x8E ; Gate Type (IA32_IDT_GATE_TYPE_INTERRUPT_32)
- dw 0 ; Offset high bits 31..16
-%endrep
-IDT_END:
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/ResetVector.nasmb
index 5fbacaed5f9d..8a3269cfc212 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -77,6 +77,7 @@
%define SEV_ES_WORK_AREA_ENC_MASK (FixedPcdGet32 (PcdSevEsWorkAreaBase) + 16)
%define SEV_ES_VC_TOP_OF_STACK (FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) + FixedPcdGet32 (PcdOvmfSecPeiTempRamSize))
%include "Ia32/Flat32ToFlat64.asm"
+%include "Ia32/AmdSev.asm"
%include "Ia32/PageTables64.asm"
%endif

--
2.17.1


[PATCH v2 0/3] Move the SEV specific changes in ResetVector in separate file

Brijesh Singh
 

The PageTable64.asm was created to build the initial page table,
but over the time it grew to include bunch of the SEV specific code
which does not directly manipulates the pagetable. Before adding more
to it, let's move all the SEV-specific routines into a separate file.

The series is taken from SNP RFCv4. And there is no functionality change
intended. Its just moving the code from one place to another.

Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>

The full branch is available at:
https://github.com/AMDESE/ovmf/pull/new/refactor-reset-vector

Changelog:
- fix the copyright header in AmdSev.asm

Brijesh Singh (3):
OvmfPkg/ResetVector: move SEV specific code in a separate file
OvmfPkg/ResetVector: add the macro to invoke MSR protocol based
VMGEXIT
OvmfPkg/ResetVector: add the macro to request guest termination

.../Ia32/{PageTables64.asm => AmdSev.asm} | 297 ++++---------
OvmfPkg/ResetVector/Ia32/PageTables64.asm | 391 ------------------
OvmfPkg/ResetVector/ResetVector.nasmb | 1 +
3 files changed, 92 insertions(+), 597 deletions(-)
copy OvmfPkg/ResetVector/Ia32/{PageTables64.asm => AmdSev.asm} (66%)

--
2.17.1

7701 - 7720 of 85885