Re: [edk2-devel] [PATCH RFC v3 04/22] OvmfPkg/MemEncryptSevLib: extend Es Workarea to include hv features

[Lendacky, Thomas via groups.io]

On 6/8/21 3:49 AM, Laszlo Ersek wrote:
> On 06/07/21 15:37, Brijesh Singh wrote:
> 
> 
...

> ... But maybe I just need to accept that we have to repurpose
> SEC_SEV_ES_WORK_AREA, considering it a super-early "HOB list" of sorts.
> Same as the PEI phase is considered the "HOB producer phase", outputting
> a bunch of disparate bits of info, we could consider the SEV-ES parts of
> the Reset Vector such an "early info bits" producer phase. I think this
> is a very big conceptual step away from the original purpose of
> SEC_SEV_ES_WORK_AREA (note the *name* of the structure: "work area"!
> HOBs are not "work areas", they are effectively read-only, once
> produced). But perhaps this is what we need (and then with proper
> documentation).
> 
> NB however that HOBs have types, GUIDed HOBs have GUIDs, the HOB types
> are specified in PI, and GUIDs are expressly declared to stand for
> various purposes at least in edk2 DEC files. All that helps with
> discerning the information flow. So... I'd still prefer keeping
> SEC_SEV_ES_WORK_AREA as minimal as possible.
> 
> Tom, any comments?

The purpose of the work area was originally two-fold. It is used in the
reset vector code to set the SevEsEnabled bit so that we could keep the
original behavior in SecCoreStartupWithStack() - no initialization of the
exception handlers or early enabling of processor cache. The second use is
for initial AP startup, where we had a known memory address at build time
that could be used to set the initial CS:IP of APs for the first boot.

We expanded the use for the security mitigations, used by the reset vector
code and again in SEC. At the start of PEI, PCDs are then set.

So, yes, if the information can be obtained later, and in this case we're
not talking about CPUID information which would need re-validation, then
there's no need to keep it in the work area and we can keep the size and
information stored in the work area to a minimum.

Thanks,
Tom

> 
> Thank you Brijesh for raising great points!
> Laszlo
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76236): https://edk2.groups.io/g/devel/message/76236
Mute This Topic: https://groups.io/mt/83113765/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] OvmfPkgIa32X64.dsc is broken: OvmfPkg/Sec/SecMain.inf NOT found in DSC file; Is it really a binary module?

[Lendacky, Thomas via groups.io]

On 6/16/21 11:15 PM, Rebecca Cran via groups.io wrote:
> Is OvmfPkg/OvmfPkgIa32X64.dsc still supposed to work after the recent
> changes in OvmfPkg? I realized it's currently broken.
> 
> 
> bcran@photon:~/src/uefi/edk2> build -p OvmfPkg/OvmfPkgIa32X64.dsc -a X64

You need to also have "-a IA32" when building this version of the DSC.

Thanks,
Tom



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76774): https://edk2.groups.io/g/devel/message/76774
Mute This Topic: https://groups.io/mt/83597788/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 4/4] OvmfPkg/PlatformDxe: Add support for SEV live migration.

[Lendacky, Thomas via groups.io]

On 6/21/21 8:57 AM, Ashish Kalra wrote:
> From: Ashish Kalra 
> 
> Detect for KVM hypervisor and check for SEV live migration
> feature support via KVM_FEATURE_CPUID, if detected setup a new
> UEFI enviroment variable to indicate OVMF support for SEV
> live migration.
> 
> Signed-off-by: Ashish Kalra 
> ---
>  OvmfPkg/Include/Guid/MemEncryptLib.h |  20 
>  OvmfPkg/OvmfPkg.dec  |   1 +
>  OvmfPkg/PlatformDxe/AmdSev.c | 108 
>  OvmfPkg/PlatformDxe/Platform.c   |   5 +
>  OvmfPkg/PlatformDxe/Platform.inf |   2 +
>  OvmfPkg/PlatformDxe/PlatformConfig.h |   5 +
>  6 files changed, 141 insertions(+)
> 
> diff --git a/OvmfPkg/Include/Guid/MemEncryptLib.h 
> b/OvmfPkg/Include/Guid/MemEncryptLib.h
> new file mode 100644
> index 00..4c046ba439
> --- /dev/null
> +++ b/OvmfPkg/Include/Guid/MemEncryptLib.h
> @@ -0,0 +1,20 @@
> +/** @file
> +
> +  AMD Memory Encryption GUID, define a new GUID for defining
> +  new UEFI enviroment variables assocaiated with SEV Memory Encryption.
> +
> +  Copyright (c) 2020, AMD Inc. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef __MEMENCRYPT_LIB_H__
> +#define __MEMENCRYPT_LIB_H__
> +
> +#define MEMENCRYPT_GUID \
> +{0x0cf29b71, 0x9e51, 0x433a, {0xa3, 0xb7, 0x81, 0xf3, 0xab, 0x16, 0xb8, 
> 0x75}}
> +
> +extern EFI_GUID gMemEncryptGuid;
> +
> +#endif
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 6ae733f6e3..e452dc8494 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -122,6 +122,7 @@
>gQemuKernelLoaderFsMediaGuid  = {0x1428f772, 0xb64a, 0x441e, 
> {0xb8, 0xc3, 0x9e, 0xbd, 0xd7, 0xf8, 0x93, 0xc7}}
>gGrubFileGuid = {0xb5ae312c, 0xbc8a, 0x43b1, 
> {0x9c, 0x62, 0xeb, 0xb8, 0x26, 0xdd, 0x5d, 0x07}}
>gConfidentialComputingSecretGuid  = {0xadf956ad, 0xe98c, 0x484c, 
> {0xae, 0x11, 0xb5, 0x1c, 0x7d, 0x33, 0x64, 0x47}}
> +  gMemEncryptGuid   = {0x0cf29b71, 0x9e51, 0x433a, 
> {0xa3, 0xb7, 0x81, 0xf3, 0xab, 0x16, 0xb8, 0x75}}
>  
>  [Ppis]
># PPI whose presence in the PPI database signals that the TPM base address
> diff --git a/OvmfPkg/PlatformDxe/AmdSev.c b/OvmfPkg/PlatformDxe/AmdSev.c
> new file mode 100644
> index 00..3dbf17a8cd
> --- /dev/null
> +++ b/OvmfPkg/PlatformDxe/AmdSev.c

Can this be done in OvmfPkg/AmdSevDxe/AmdSevDxe.c or is that too early?

> @@ -0,0 +1,108 @@
> +/**@file
> +  Detect KVM hypervisor support for SEV live migration and if
> +  detected, setup a new UEFI enviroment variable indicating
> +  OVMF support for SEV live migration.
> +
> +  Copyright (c) 2020, Advanced Micro Devices. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +//
> +// The package level header files this module uses
> +//
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define KVM_FEATURE_MIGRATION_CONTROL   17

BIT17

> +
> +/**
> +  Figures out if we are running inside KVM HVM and
> +  KVM HVM supports SEV Live Migration feature.
> +
> +  @retval TRUE   KVM was detected and Live Migration supported
> +  @retval FALSE  KVM was not detected or Live Migration not supported
> +
> +**/
> +BOOLEAN
> +KvmDetectSevLiveMigrationFeature(
> +  VOID
> +  )
> +{
> +  UINT8 Signature[13];
> +  UINT32 mKvmLeaf = 0;
> +  UINT32 RegEax, RegEbx, RegEcx, RegEdx;
> +
> +  Signature[12] = '\0';
> +  for (mKvmLeaf = 0x4000; mKvmLeaf < 0x4001; mKvmLeaf += 0x100) {

What's the reason for the loop? I would think that just checking
0x4000 would be enough, so a comment seems to be warranted.

> +AsmCpuid (mKvmLeaf,
> +  NULL,
> +  (UINT32 *) [0],
> +  (UINT32 *) [4],
> +  (UINT32 *) [8]);
> +
> +if (!AsciiStrCmp ((CHAR8 *) Signature, "KVMKVMKVM\0\0\0")) {
> +  DEBUG ((
> +DEBUG_ERROR,

DEBUG_INFO, it doesn't seem like an error.

> +"%a: KVM Detected, signature = %s\n",
> +__FUNCTION__,
> +Signature
> +));
> +> +  RegEax = 0x4001;

Should this be mKvmLeaf + 1? It is confusing that you may check 0x4100
and then not do 0x4101.

> +  RegEcx = 0;
> +  AsmCpuid (0x4001, , , , );
> +  if (RegEax & (1 << KVM_FEATURE_MIGRATION_CONTROL)) {

This needs to be (assuming BIT17 is used above):

  if ((RegEax & KVM_FEATURE_MIGRATION_CONTROL) != 0) {

You must use an actual comparison if the variable is not a boolean.

> +DEBUG ((
> +  DEBUG_ERROR,
> +  "%a: Live Migration feature supported\n",

DEBUG_INFO again.

> +  __FUNCTION__
> +  ));
> +return TRUE;
> +  }
> +}
> +  }
> +
> +  return FALSE;
> +}
> +
> +/**
> +
> +  Function checks if SEV Live Migration support is available, if present 
> then it sets
> +  a UEFI enviroment variable to be queried later using Runtime services.
> +
> +  **/
> +VOID
> +AmdSevSetConfig(

Kind of a 

Re: [edk2-devel] [PATCH v4 1/4] OvmfPkg/MemEncryptHypercallLib: add library to support SEV hypercalls.

[Lendacky, Thomas via groups.io]

On 6/21/21 8:56 AM, Ashish Kalra wrote:
> From: Ashish Kalra 
> 
> Add SEV and SEV-ES hypercall abstraction library to support SEV Page
> encryption/deceryption status hypercalls for SEV and SEV-ES guests.

Does this have to be a new library? It's just a single function and so I
would think it could live in the BaseMemEncryptSevLib library where the
change to the c-bit is being done anyway.

> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> 
> Signed-off-by: Ashish Kalra 
> ---
>  Maintainers.txt  |   2 +
>  OvmfPkg/Include/Library/MemEncryptHypercallLib.h |  43 
> 
>  OvmfPkg/Library/MemEncryptHypercallLib/Ia32/MemEncryptHypercallLib.c |  37 
> +++
>  OvmfPkg/Library/MemEncryptHypercallLib/MemEncryptHypercallLib.inf|  42 
> 
>  OvmfPkg/Library/MemEncryptHypercallLib/X64/AsmHelperStub.nasm|  28 
> ++
>  OvmfPkg/Library/MemEncryptHypercallLib/X64/MemEncryptHypercallLib.c  | 105 
> 
>  OvmfPkg/OvmfPkgIa32.dsc  |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc   |   1 +
>  OvmfPkg/OvmfPkgX64.dsc   |   1 +
>  OvmfPkg/OvmfXen.dsc  |   1 +
>  10 files changed, 261 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index ea54e0b7e9..8ecc8464ba 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -449,8 +449,10 @@ F: OvmfPkg/AmdSev/
>  F: OvmfPkg/AmdSevDxe/
>  F: OvmfPkg/Include/Guid/ConfidentialComputingSecret.h
>  F: OvmfPkg/Include/Library/MemEncryptSevLib.h
> +F: OvmfPkg/Include/Library/MemEncryptHypercallLib.h
>  F: OvmfPkg/IoMmuDxe/AmdSevIoMmu.*
>  F: OvmfPkg/Library/BaseMemEncryptSevLib/
> +F: OvmfPkg/Library/MemEncryptHypercallLib/
>  F: OvmfPkg/Library/PlatformBootManagerLibGrub/
>  F: OvmfPkg/Library/VmgExitLib/
>  F: OvmfPkg/PlatformPei/AmdSev.c
> diff --git a/OvmfPkg/Include/Library/MemEncryptHypercallLib.h 
> b/OvmfPkg/Include/Library/MemEncryptHypercallLib.h
> new file mode 100644
> index 00..b241a189b6
> --- /dev/null
> +++ b/OvmfPkg/Include/Library/MemEncryptHypercallLib.h
> @@ -0,0 +1,43 @@
> +/** @file
> +
> +  Define Secure Encrypted Virtualization (SEV) hypercall library.
> +
> +  Copyright (c) 2020, AMD Incorporated. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef _MEM_ENCRYPT_HYPERCALL_LIB_H_
> +#define _MEM_ENCRYPT_HYPERCALL_LIB_H_
> +
> +#include 
> +
> +#define KVM_HC_MAP_GPA_RANGE   12
> +#define KVM_MAP_GPA_RANGE_PAGE_SZ_4K0

> +#define KVM_MAP_GPA_RANGE_PAGE_SZ_2M(1 << 0)

Use the BIT0 define, e.g.:
#define KVM_MAP_GPA_RANGE_PAGE_SZ_2M  BIT0

> +#define KVM_MAP_GPA_RANGE_PAGE_SZ_1G(1 << 1)

BIT1

Also, where are these used? Are they supposed to be part of the "Mode"
parameter, in which case the comment for Mode below is incorrect.

> +#define KVM_MAP_GPA_RANGE_ENC_STAT(n)   ((n) << 4)
> +#define KVM_MAP_GPA_RANGE_ENCRYPTED KVM_MAP_GPA_RANGE_ENC_STAT(1)
> +#define KVM_MAP_GPA_RANGE_DECRYPTED KVM_MAP_GPA_RANGE_ENC_STAT(0)
> +
> +/**
> + This hyercall is used to notify hypervisor when a page is marked as
> + 'decrypted' (i.e C-bit removed).
> +
> + @param[in]   PhysicalAddress   The physical address that is the start 
> address
> +of a memory region.
> + @param[in]   LengthThe length of memory region
> + @param[in]   Mode  SetCBit or ClearCBit
> +
> +**/
> +
> +VOID
> +EFIAPI
> +SetMemoryEncDecHypercall3 (
> +  IN  UINTN PhysicalAddress,
> +  IN  UINTN Length,
> +  IN  UINTN Mode
> +  );
> +
> +#endif
> diff --git 
> a/OvmfPkg/Library/MemEncryptHypercallLib/Ia32/MemEncryptHypercallLib.c 
> b/OvmfPkg/Library/MemEncryptHypercallLib/Ia32/MemEncryptHypercallLib.c
> new file mode 100644
> index 00..2e73d47ee6
> --- /dev/null
> +++ b/OvmfPkg/Library/MemEncryptHypercallLib/Ia32/MemEncryptHypercallLib.c
> @@ -0,0 +1,37 @@
> +/** @file
> +
> +  Secure Encrypted Virtualization (SEV) hypercall helper library
> +
> +  Copyright (c) 2020, AMD Incorporated. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> + This hyercall is used to notify hypervisor when a page is marked as
> + 'decrypted' (i.e C-bit removed).
> +
> + @param[in]   PhysicalAddress   The physical address that is the start 
> address
> +of a memory region.
> + @param[in]   LengthThe length of memory region
> + @param[in]   Mode  SetCBit or ClearCBit

This isn't actually SetCBit or ClearCBit based on how I see it used below.

> +
> +**/
> +
> +VOID
> +EFIAPI
> +SetMemoryEncDecHypercall3 (
> +  IN PHYSICAL_ADDRESS PhysicalAddress,
> +  IN UINTNPages,

This doesn't match 

Re: [edk2-devel] [PATCH v4 2/4] OvmfPkg/BaseMemEncryptLib: Support to issue unencrypted hypercall

[Lendacky, Thomas via groups.io]

On 6/21/21 8:57 AM, Ashish Kalra wrote:
> From: Brijesh Singh 
> 
> By default all the SEV guest memory regions are considered encrypted,
> if a guest changes the encryption attribute of the page (e.g mark a
> page as decrypted) then notify hypervisor. Hypervisor will need to
> track the unencrypted pages. The information will be used during
> guest live migration, guest page migration and guest debugging.
> 
> Invoke hypercall via the new hypercall library.
> 
> This hypercall is used to notify hypervisor when a page is marked as
> 'decrypted' (i.e C-bit removed).
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> 
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Ashish Kalra 
> ---
>  OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf   |  1 +
>  OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf   |  1 +
>  OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c | 22 
> 
>  3 files changed, 24 insertions(+)
> 
> diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf 
> b/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf
> index f2e162d680..aefcd7c0f7 100644
> --- a/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf
> +++ b/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf
> @@ -49,6 +49,7 @@
>DebugLib
>MemoryAllocationLib
>PcdLib
> +  MemEncryptHypercallLib
>  
>  [FeaturePcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf 
> b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf
> index 03a78c32df..7503f56a0b 100644
> --- a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf
> +++ b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf
> @@ -49,6 +49,7 @@
>DebugLib
>MemoryAllocationLib
>PcdLib
> +  MemEncryptHypercallLib
>  
>  [FeaturePcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c 
> b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c
> index c696745f9d..12b3a9fcfb 100644
> --- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c
> +++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "VirtualMemory.h"
>  
> @@ -585,6 +586,9 @@ SetMemoryEncDec (
>UINT64 AddressEncMask;
>BOOLEANIsWpEnabled;
>RETURN_STATUS  Status;
> +  UINTN  Size;
> +  BOOLEANCBitChanged;
> +  PHYSICAL_ADDRESS   OrigPhysicalAddress;
>  
>//
>// Set PageMapLevel4Entry to suppress incorrect compiler/analyzer warnings.
> @@ -636,6 +640,10 @@ SetMemoryEncDec (
>  
>Status = EFI_SUCCESS;
>  
> +  Size = Length;
> +  CBitChanged = FALSE;
> +  OrigPhysicalAddress = PhysicalAddress;
> +
>while (Length != 0)
>{
>  //
> @@ -695,6 +703,7 @@ SetMemoryEncDec (
>));
>  PhysicalAddress += BIT30;
>  Length -= BIT30;
> +CBitChanged = TRUE;
>} else {
>  //
>  // We must split the page
> @@ -749,6 +758,7 @@ SetMemoryEncDec (
>SetOrClearCBit (>Uint64, Mode);
>PhysicalAddress += BIT21;
>Length -= BIT21;
> +  CBitChanged = TRUE;
>  } else {
>//
>// We must split up this page into 4K pages
> @@ -791,6 +801,7 @@ SetMemoryEncDec (
>  SetOrClearCBit (>Uint64, Mode);
>  PhysicalAddress += EFI_PAGE_SIZE;
>  Length -= EFI_PAGE_SIZE;
> +CBitChanged = TRUE;
>}
>  }
>}
> @@ -808,6 +819,17 @@ SetMemoryEncDec (
>//
>CpuFlushTlb();
>  
> +  //
> +  // Notify Hypervisor on C-bit status
> +  //
> +  if (CBitChanged) {
> +SetMemoryEncDecHypercall3 (
> +  OrigPhysicalAddress,
> +  EFI_SIZE_TO_PAGES(Size),
> +  KVM_MAP_GPA_RANGE_ENC_STAT(!Mode)
> +  );
> +  }

Maybe add a comment here that the "Mode" doesn't care whether the change
was for 4k vs 2mb vs 1gb. It is just tracking the total number of pages
changed (should you just remove those #defines for the page sizes then?)
which can be done by calculating everything at the 4k level.

Thanks,
Tom

> +
>  Done:
>//
>// Restore page table write protection, if any.
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76868): https://edk2.groups.io/g/devel/message/76868
Mute This Topic: https://groups.io/mt/8363/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 1/6] OvmfPkg/BaseMemEncryptLib: Detect SEV live migration feature.

[Lendacky, Thomas via groups.io]

On 8/2/21 7:31 AM, Ashish Kalra wrote:
> From: Ashish Kalra 
> 
> Add support to check if we are running inside KVM HVM and
> KVM HVM supports SEV Live Migration feature.
> 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Signed-off-by: Ashish Kalra 
> ---
>  OvmfPkg/Include/Library/MemEncryptSevLib.h| 27 
> ++
>  OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c| 39 
> +++
>  OvmfPkg/Library/BaseMemEncryptSevLib/PeiDxeMemEncryptSevLibInternal.c | 52 
> 
>  OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c| 39 
> +++
>  OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c| 18 
> +++
>  5 files changed, 175 insertions(+)
> 
> diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h 
> b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> index 76d06c206c..59f694fb8a 100644
> --- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
> +++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> @@ -90,6 +90,18 @@ MemEncryptSevIsEnabled (
>VOID
>);
>  
> +/**
> +  Returns a boolean to indicate whether SEV live migration is enabled.
> +
> +  @retval TRUE   SEV live migration is enabled
> +  @retval FALSE  SEV live migration is not enabled
> +**/
> +BOOLEAN
> +EFIAPI
> +MemEncryptSevLiveMigrationIsEnabled (
> +  VOID
> +  );
> +
>  /**
>This function clears memory encryption bit for the memory region specified 
> by
>BaseAddress and NumPages from the current page table context.
> @@ -222,4 +234,19 @@ MemEncryptSevClearMmioPageEncMask (
>IN UINTNNumPages
>);
>  
> +#define KVM_FEATURE_MIGRATION_CONTROL   BIT17
> +
> +/**
> +  Figures out if we are running inside KVM HVM and
> +  KVM HVM supports SEV Live Migration feature.
> +
> +  @retval TRUE   SEV live migration is supported.
> +  @retval FALSE  SEV live migration is not supported.
> +**/
> +BOOLEAN
> +EFIAPI
> +KvmDetectSevLiveMigrationFeature(
> +  VOID
> +  );
> +

I don't think KvmDetectSevLiveMigrationFeature() should be in
OvmfPkg/Include/Library/MemEncryptSevLib.h since it isn't called except as
a helper by InternalDetectSevLiveMigrationFeature(). You should probably
create a new PeiDxeMemEncryptSevLibInternal.h header file for that
function that lives in OvmfPkg/Library/BaseMemEncryptSevLib.

>  #endif // _MEM_ENCRYPT_SEV_LIB_H_
> diff --git 
> a/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c 
> b/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
> index 2816f859a0..ead754cd7b 100644
> --- a/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
> +++ b/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
> @@ -20,6 +20,8 @@
>  STATIC BOOLEAN mSevStatus = FALSE;
>  STATIC BOOLEAN mSevEsStatus = FALSE;
>  STATIC BOOLEAN mSevStatusChecked = FALSE;
> +STATIC BOOLEAN mSevLiveMigrationStatus = FALSE;
> +STATIC BOOLEAN mSevLiveMigrationStatusChecked = FALSE;
>  
>  STATIC UINT64  mSevEncryptionMask = 0;
>  STATIC BOOLEAN mSevEncryptionMaskSaved = FALSE;
> @@ -87,6 +89,24 @@ InternalMemEncryptSevStatus (
>mSevStatusChecked = TRUE;
>  }
>  
> +/**
> +  Figures out if we are running inside KVM HVM and
> +  KVM HVM supports SEV Live Migration feature.
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +InternalDetectSevLiveMigrationFeature(
> +  VOID
> +  )
> +{
> +  if (KvmDetectSevLiveMigrationFeature()) {

Add a space before the "()"

> +mSevLiveMigrationStatus = TRUE;
> +  }
> +
> +  mSevLiveMigrationStatusChecked = TRUE;
> +}
> +
>  /**
>Returns a boolean to indicate whether SEV-ES is enabled.
>  
> @@ -125,6 +145,25 @@ MemEncryptSevIsEnabled (
>return mSevStatus;
>  }
>  
> +/**
> +  Returns a boolean to indicate whether SEV live migration is enabled.
> +
> +  @retval TRUE   SEV live migration is enabled
> +  @retval FALSE  SEV live migration is not enabled
> +**/
> +BOOLEAN
> +EFIAPI
> +MemEncryptSevLiveMigrationIsEnabled (
> +  VOID
> +  )
> +{
> +  if (!mSevLiveMigrationStatusChecked) {
> +InternalDetectSevLiveMigrationFeature ();
> +  }
> +
> +  return mSevLiveMigrationStatus;
> +}
> +
>  /**
>Returns the SEV encryption mask.
>  
> diff --git 
> a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiDxeMemEncryptSevLibInternal.c 
> b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiDxeMemEncryptSevLibInternal.c
> index b4a9f464e2..d7fc973134 100644
> --- a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiDxeMemEncryptSevLibInternal.c
> +++ b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiDxeMemEncryptSevLibInternal.c
> @@ -61,3 +61,55 @@ MemEncryptSevLocateInitialSmramSaveStateMapPages (
>  
>return RETURN_SUCCESS;
>  }
> +
> +/**
> +  Figures out if we are running inside KVM HVM and
> +  KVM HVM supports SEV Live Migration feature.
> +
> +  @retval TRUE   SEV live migration is supported.
> +  @retval FALSE  SEV live migration is not supported.
> +**/
> +BOOLEAN
> +EFIAPI
> 

Re: [edk2-devel] [PATCH v6 6/6] OvmfPkg/AmdSevDxe: Add support for SEV live migration.

[Lendacky, Thomas via groups.io]

On 8/2/21 7:33 AM, Ashish Kalra wrote:
> From: Ashish Kalra 
> 
> Check for SEV live migration feature support, if detected
> setup a new UEFI enviroment variable to indicate OVMF
> support for SEV live migration.
> 
> The new runtime UEFI environment variable is set via the
> notification function registered for the
> EFI_END_OF_DXE_EVENT_GROUP_GUID event in AmdSevDxe driver.
> 
> AmdSevDxe module is an apriori driver so it gets loaded between PEI
> and DXE phases and the SetVariable call will fail at the driver's
> entry point as the Variable DXE module is still not loaded yet.
> So we need to wait for an event notification which is signaled
> after the Variable DXE module is loaded, hence, using the
> EndOfDxe event notification to make this call.
> 
> Signed-off-by: Ashish Kalra 
> ---
>  OvmfPkg/AmdSevDxe/AmdSevDxe.c  | 64 
>  OvmfPkg/AmdSevDxe/AmdSevDxe.inf|  4 ++
>  OvmfPkg/Include/Guid/AmdSevMemEncryptLib.h | 20 ++
>  OvmfPkg/OvmfPkg.dec|  1 +
>  4 files changed, 89 insertions(+)
> 
> diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> index c66c4e9b92..bfad71b9c6 100644
> --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> @@ -15,10 +15,47 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  
> +STATIC
> +VOID
> +EFIAPI
> +AmdSevDxeOnEndOfDxe (
> +  IN EFI_EVENT Event,
> +  IN VOID  *EventToSignal
> +  )
> +{
> +  EFI_STATUS Status;
> +  BOOLEAN SevLiveMigrationEnabled;
> +
> +  SevLiveMigrationEnabled = MemEncryptSevLiveMigrationIsEnabled();
> +
> +  if (SevLiveMigrationEnabled) {
> +Status = gRT->SetVariable (
> +   L"SevLiveMigrationEnabled",
> +   ,
> +   EFI_VARIABLE_NON_VOLATILE |
> +   EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +   EFI_VARIABLE_RUNTIME_ACCESS,
> +   sizeof SevLiveMigrationEnabled,
> +   
> +   );
> +
> +DEBUG ((
> +  DEBUG_INFO,
> +  "%a: Setting SevLiveMigrationEnabled variable, status = %lx\n",
> +  __FUNCTION__,
> +  Status
> +  ));
> +  }
> +}
> +
>  EFI_STATUS
>  EFIAPI
>  AmdSevDxeEntryPoint (
> @@ -30,6 +67,7 @@ AmdSevDxeEntryPoint (
>EFI_GCD_MEMORY_SPACE_DESCRIPTOR  *AllDescMap;
>UINTNNumEntries;
>UINTNIndex;
> +  EFI_EVENTEvent;
>  
>//
>// Do nothing when SEV is not enabled
> @@ -130,5 +168,31 @@ AmdSevDxeEntryPoint (
>  }
>}
>  
> +  //
> +  // AmdSevDxe module is an apriori driver so it gets loaded between PEI
> +  // and DXE phases and the SetVariable call will fail at the driver's
> +  // entry point as the Variable DXE module is still not loaded yet.
> +  // So we need to wait for an event notification which is signaled
> +  // after the Variable DXE module is loaded, hence, using the
> +  // EndOfDxe event notification to make this call.
> +  //
> +  // Register EFI_END_OF_DXE_EVENT_GROUP_GUID event.
> +  // The notification function sets the runtime variable indicating OVMF
> +  // support for SEV live migration.
> +  //
> +  Status = gBS->CreateEventEx (
> +  EVT_NOTIFY_SIGNAL,
> +  TPL_CALLBACK,
> +  AmdSevDxeOnEndOfDxe,
> +  NULL,
> +  ,
> +  
> +  );
> +
> +  if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_INFO, "%a: CreateEventEx(): %r\n",

DEBUG_ERROR?

> +__FUNCTION__, Status));

Should there be an "ASSERT_EFI_ERROR (Status)" after the DEBUG call?

Thanks,
Tom

> +  }
> +
>return EFI_SUCCESS;
>  }
> diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> index 0676fcc5b6..2ad1fb8632 100644
> --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
> @@ -45,3 +45,7 @@
>  
>  [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
> +
> +[Guids]
> +  gAmdSevMemEncryptGuid
> +  gEfiEndOfDxeEventGroupGuid ## CONSUMES   ## Event
> diff --git a/OvmfPkg/Include/Guid/AmdSevMemEncryptLib.h 
> b/OvmfPkg/Include/Guid/AmdSevMemEncryptLib.h
> new file mode 100644
> index 00..8ab283860b
> --- /dev/null
> +++ b/OvmfPkg/Include/Guid/AmdSevMemEncryptLib.h
> @@ -0,0 +1,20 @@
> +/** @file
> +
> +  AMD Memory Encryption GUID, define a new GUID for defining
> +  new UEFI environment variables assocaiated with SEV Memory Encryption.
> +
> +  Copyright (c) 2021, AMD Inc. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef __AMD_SEV_MEMENCRYPT_LIB_H__
> +#define __AMD_SEV_MEMENCRYPT_LIB_H__
> +
> +#define AMD_SEV_MEMENCRYPT_GUID \
> +{0x0cf29b71, 0x9e51, 0x433a, {0xa3, 0xb7, 0x81, 0xf3, 0xab, 0x16, 0xb8, 
> 0x75}}
> +
> +extern EFI_GUID gAmdSevMemEncryptGuid;
> +
> +#endif
> diff --git a/OvmfPkg/OvmfPkg.dec 

Re: [edk2-devel] [PATCH v6 2/6] OvmfPkg/BaseMemEncryptLib: Hypercall API for page encryption state change

[Lendacky, Thomas via groups.io]

On 8/2/21 7:31 AM, Ashish Kalra wrote:
> From: Ashish Kalra 
> 
> Add API to issue hypercall on page encryption state change.
> 
> By default all the SEV guest memory regions are considered encrypted,
> if a guest changes the encryption attribute of the page (e.g mark a
> page as decrypted) then notify hypervisor. Hypervisor will need to
> track the unencrypted pages. The information will be used during
> guest live migration, guest page migration and guest debugging.
> 
> This hypercall is used to notify hypervisor when the page's
> encryption state changes.
> 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Ashish Kalra 
> ---
>  OvmfPkg/Include/Library/MemEncryptSevLib.h | 43 
> +
>  OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf   |  1 +
>  OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c   | 27 
> +
>  OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf   |  1 +
>  OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c | 20 
> ++
>  OvmfPkg/Library/BaseMemEncryptSevLib/X64/AsmHelperStub.nasm| 33 
> ++
>  OvmfPkg/Library/BaseMemEncryptSevLib/X64/MemEncryptSevLib.c| 64 
> 
>  7 files changed, 189 insertions(+)
> 
> diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h 
> b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> index 59f694fb8a..56cc7bb958 100644
> --- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
> +++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> @@ -249,4 +249,47 @@ KvmDetectSevLiveMigrationFeature(
>VOID
>);
>  
> +/**
> + This hypercall is used to notify hypervisor when the page's encryption
> + state changes.
> +
> + @param[in]   PhysicalAddress   The physical address that is the start 
> address
> +of a memory region.
> + @param[in]   Pages Number of pages in memory region.
> + @param[in]   IsEncrypted   Encrypted or Decrypted.
> +
> + @retval RETURN_SUCCESS Hypercall returned success.
> + @retval RETURN_UNSUPPORTED Hypercall not supported.
> + @retval RETURN_NO_MAPPING  Hypercall returned error.
> +**/
> +RETURN_STATUS
> +EFIAPI
> +SetMemoryEncDecHypercall3 (
> +  IN  UINTN PhysicalAddress,
> +  IN  UINTN Pages,
> +  IN  BOOLEAN   IsEncrypted
> +  );
> +
> +#define KVM_HC_MAP_GPA_RANGE   12
> +#define KVM_MAP_GPA_RANGE_PAGE_SZ_4K0
> +#define KVM_MAP_GPA_RANGE_PAGE_SZ_2MBIT0
> +#define KVM_MAP_GPA_RANGE_PAGE_SZ_1GBIT1
> +#define KVM_MAP_GPA_RANGE_ENC_STAT(n)   ((n) << 4)

s/STAT/STATE/ ?

> +#define KVM_MAP_GPA_RANGE_ENCRYPTED KVM_MAP_GPA_RANGE_ENC_STAT(1)
> +#define KVM_MAP_GPA_RANGE_DECRYPTED KVM_MAP_GPA_RANGE_ENC_STAT(0)
> +
> +/**
> +  Interface exposed by the ASM implementation of the core hypercall

Need to put the function parameters in the comment here.

> +
> +  @retval Hypercall returned status.
> +**/
> +UINTN
> +EFIAPI
> +SetMemoryEncDecHypercall3AsmStub (
> +  IN  UINTN  HypercallNum,
> +  IN  UINTN  PhysicalAddress,
> +  IN  UINTN  Pages,
> +  IN  UINTN  Attributes
> +  );
> +
>  #endif // _MEM_ENCRYPT_SEV_LIB_H_
> diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf 
> b/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf
> index f2e162d680..0c28afadee 100644
> --- a/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf
> +++ b/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf
> @@ -38,6 +38,7 @@
>X64/PeiDxeVirtualMemory.c
>X64/VirtualMemory.c
>X64/VirtualMemory.h
> +  X64/AsmHelperStub.nasm
>  
>  [Sources.IA32]
>Ia32/MemEncryptSevLib.c
> diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c 
> b/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c
> index be260e0d10..516d639489 100644
> --- a/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c
> +++ b/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c
> @@ -136,3 +136,30 @@ MemEncryptSevClearMmioPageEncMask (
>//
>return RETURN_UNSUPPORTED;
>  }
> +
> +/**
> + This hyercall is used to notify hypervisor when the page's encryption
> + state changes.
> +
> + @param[in]   PhysicalAddress   The physical address that is the start 
> address
> +of a memory region.
> + @param[in]   Pages Number of Pages in the memory region.
> + @param[in]   IsEncrypted   Encrypted or Decrypted.
> +
> + @retval RETURN_SUCCESS Hypercall returned success.
> + @retval RETURN_UNSUPPORTED Hypercall not supported.
> + @retval RETURN_NO_MAPPING  Hypercall returned error.
> +**/
> +RETURN_STATUS
> +EFIAPI
> +SetMemoryEncDecHypercall3 (
> +  IN  UINTN PhysicalAddress,
> +  IN  UINTN Pages,
> +  IN  BOOLEAN   IsEncrypted
> +  )
> +{
> +  //
> +  // Memory encryption bit is not accessible in 32-bit mode
> +  //
> +  return 

Re: [edk2-devel] [PATCH 1/3] OvmfPkg: introduce a common work area

[Lendacky, Thomas via groups.io]

On 8/4/21 3:20 PM, Brijesh Singh wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> Both the TDX and SEV support needs to reserve a page in MEMFD as a work
> area. The page will contain meta data specific to the guest type.
> Currently, the SEV-ES support reserves a page in MEMFD
> (PcdSevEsWorkArea) for the work area. This page can be reused as a TDX
> work area when Intel TDX is enabled.
> 
> Based on the discussion [1], it was agreed to rename the SevEsWorkArea
> to the OvmfWorkArea, and add a header that can be used to indicate the
> work area type.
> 
> [1] https://edk2.groups.io/g/devel/message/78262?p=,,,20,0,0,0::\
> created,0,SNP,20,2,0,84476064
> 
> Cc: James Bottomley 
> Cc: Min Xu 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: Erdem Aktas 
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/OvmfPkg.dec|  6 +++
>  OvmfPkg/OvmfPkgX64.fdf |  9 +++-
>  OvmfPkg/PlatformPei/PlatformPei.inf|  4 +-
>  OvmfPkg/Include/Library/MemEncryptSevLib.h | 21 +
>  OvmfPkg/Include/WorkArea.h | 53 ++
>  OvmfPkg/PlatformPei/MemDetect.c| 32 ++---
>  6 files changed, 85 insertions(+), 40 deletions(-)
>  create mode 100644 OvmfPkg/Include/WorkArea.h
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 2ab27f0c73c2..9d31ec45c78a 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -330,6 +330,12 @@ [PcdsFixedAtBuild]
>gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|0x0|UINT32|0x47
>gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize|0x0|UINT32|0x48
>  
> +  ## The base address and size of the work area used during the SEC
> +  # phase by the SEV and TDX supports.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase|0|UINT32|0x49
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize|0|UINT32|0x50
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaHeaderSize|4|UINT32|0x51
> +
>  [PcdsDynamic, PcdsDynamicEx]
>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index 5fa8c0895808..418e0ea5add4 100644
> --- a/OvmfPkg/OvmfPkgX64.fdf
> +++ b/OvmfPkg/OvmfPkgX64.fdf
> @@ -83,7 +83,7 @@ [FD.MEMFD]
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
>  
>  0x00B000|0x001000
> -gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
> +gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize
>  
>  0x00C000|0x001000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize
> @@ -99,6 +99,13 @@ [FD.MEMFD]
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
>  FV = DXEFV
>  
> +##
> +# SEV specific PCD settings
> +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaHeaderSize = 0x4
> +SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) + 
>  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + 
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaHeaderSize
> +SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = 
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - 
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaHeaderSize
> +##
> +
>  
> 
>  
>  [FV.SECFV]
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index 89d1f7636870..67eb7aa7166b 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -116,8 +116,8 @@ [FixedPcd]
>gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize
> -  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
> -  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize
>  
>  [FeaturePcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable
> diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h 
> b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> index 76d06c206c8b..adc490e466ec 100644
> --- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
> +++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> @@ -12,6 +12,7 @@
>  #define _MEM_ENCRYPT_SEV_LIB_H_
>  
>  #include 
> +#include 
>  
>  //
>  // Define the maximum number of #VCs allowed (e.g. the level of nesting
> @@ -36,26 +37,6 @@ typedef struct {
>VOID*GhcbBackupPages;
>  } SEV_ES_PER_CPU_DATA;
>  
> -//
> -// Internal structure for holding SEV-ES 

Re: [edk2-devel] [PATCH 2/3] OvmfPkg/ResetVector: update SEV support to use new work area format

[Lendacky, Thomas via groups.io]

On 8/4/21 3:20 PM, Brijesh Singh wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> Update the SEV support to switch to using the newer work area format.
> 
> Cc: James Bottomley 
> Cc: Min Xu 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: Erdem Aktas 
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/ResetVector/ResetVector.inf   |  1 +
>  OvmfPkg/Sec/SecMain.inf   |  1 +
>  OvmfPkg/Sec/SecMain.c | 25 ++-
>  OvmfPkg/ResetVector/Ia32/AmdSev.asm   |  8 
>  OvmfPkg/ResetVector/Ia32/PageTables64.asm |  4 
>  OvmfPkg/ResetVector/ResetVector.nasmb |  1 +
>  6 files changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
> b/OvmfPkg/ResetVector/ResetVector.inf
> index d028c92d8cfa..6ec9cca40c3a 100644
> --- a/OvmfPkg/ResetVector/ResetVector.inf
> +++ b/OvmfPkg/ResetVector/ResetVector.inf
> @@ -34,6 +34,7 @@ [BuildOptions]
> *_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
>  
>  [Pcd]
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase

Laszlo was trying to keep things sorted, so you should move this down to
the end of the list.

>gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
> diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
> index 7f78dcee2772..82910dcbd5c2 100644
> --- a/OvmfPkg/Sec/SecMain.inf
> +++ b/OvmfPkg/Sec/SecMain.inf
> @@ -56,6 +56,7 @@ [Ppis]
>gEfiTemporaryRamSupportPpiGuid# PPI ALWAYS_PRODUCED
>  
>  [Pcd]
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase

Ditto here, even though the list isn't truly sorted to begin with.

>gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
> index 9db67e17b2aa..dda572c7ad7d 100644
> --- a/OvmfPkg/Sec/SecMain.c
> +++ b/OvmfPkg/Sec/SecMain.c
> @@ -807,6 +807,29 @@ SevEsProtocolCheck (
>Ghcb->GhcbUsage = GHCB_STANDARD_USAGE;
>  }
>  
> +/**
> + Determine if the SEV is active.
> +
> + During the early booting, GuestType is set in the work area. Verify that it
> + is an SEV guest.
> +
> + @retval TRUE   SEV is enabled
> + @retval FALSE  SEV is not enabled
> +
> +**/
> +STATIC
> +BOOLEAN
> +IsSevGuest (
> +  VOID
> +  )
> +{
> +  OVMF_WORK_AREA *WorkArea;
> +
> +  WorkArea = (OVMF_WORK_AREA *) FixedPcdGet32 (PcdOvmfWorkAreaBase);
> +
> +  return ((WorkArea != NULL) && (WorkArea->GuestType == GUEST_TYPE_AMD_SEV));
> +}
> +
>  /**
>Determine if SEV-ES is active.
>  
> @@ -828,7 +851,7 @@ SevEsIsEnabled (
>  
>SevEsWorkArea = (SEC_SEV_ES_WORK_AREA *) FixedPcdGet32 
> (PcdSevEsWorkAreaBase);
>  
> -  return ((SevEsWorkArea != NULL) && (SevEsWorkArea->SevEsEnabled != 0));
> +  return (((IsSevGuest()) && SevEsWorkArea != NULL) && 
> (SevEsWorkArea->SevEsEnabled != 0));

The IsSevGuest() function checks for a NULL work area, so there's no need
to check for SevEsWorkArea being non-NULL now. I think it would read
better, though, to do:

if (!IsSevGuest ()) {
  return FALSE;
}

SevEsWorkArea = ...

return (SevEsWorkArea->SevEsEnabled != 0);

>  }
>  
>  VOID
> diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
> b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
> index aa95d06eaddb..87d81b01e263 100644
> --- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
> +++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
> @@ -171,6 +171,9 @@ CheckSevFeatures:
>  bteax, 0
>  jnc   NoSev
>  
> +; Set the work area header to indicate that the SEV is enabled

s/the SEV/SEV/

> +mov byte[WORK_AREA_GUEST_TYPE], 1

The "1" should probably be defined in ResetVector.nasmb as a %define.

> +
>  ; 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
> @@ -257,6 +260,11 @@ SevExit:
>  IsSevEsEnabled:
>  xor   eax, eax
>  
> +; During CheckSevFeatures, the WORK_AREA_GUEST_TYPE is set
> +; to 1 if SEV is enabled.
> +cmp   byte[WORK_AREA_GUEST_TYPE], 1
> +jne   SevEsDisabled
> +
>  ; During CheckSevFeatures, the SEV_ES_WORK_AREA was set to 1 if
>  ; SEV-ES is enabled.
>  cmp   byte[SEV_ES_WORK_AREA], 1
> diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
> b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> index eacdb69ddb9f..f688909f1c7d 100644
> --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> +++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> @@ -42,6 +42,10 @@ BITS32
>  ;
>  SetCr3ForPageTables64:
>  
> +; Clear the WorkArea header. The SEV probe routines will populate the

How about:
; Initialize the WorkArea header to indicate a legacy guest. The ...

> +; work area when detected.
> +mov 

Re: [edk2-devel] [PATCH 3/3] OvmfPkg/ResetVector: move the GHCB page setup in AmdSev.asm

[Lendacky, Thomas via groups.io]

On 8/4/21 3:20 PM, Brijesh Singh wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> While build the initial page table, the SetCr3ForPageTables64 checks
> whether SEV-ES is enabled. If so, clear the page encryption mask from the
> GHCB page. Move the logic to clear the page encryption mask in the
> AmdSev.asm.
> 
> Cc: James Bottomley 
> Cc: Min Xu 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: Erdem Aktas 
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/ResetVector/Ia32/AmdSev.asm   | 113 +-
>  OvmfPkg/ResetVector/Ia32/PageTables64.asm |  53 ++
>  2 files changed, 94 insertions(+), 72 deletions(-)
> 
> diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
> b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
> index 87d81b01e263..fd2e6abcd4a0 100644
> --- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
> +++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
> @@ -44,6 +44,27 @@ BITS32
>  ; The unexpected response code
>  %define TERM_UNEXPECTED_RESP_CODE   2
>  
> +%define PAGE_PRESENT0x01
> +%define PAGE_READ_WRITE 0x02
> +%define PAGE_USER_SUPERVISOR0x04
> +%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_MBO0x080
> +%define PAGE_2M_PAT  0x01000
> +
> +%define PAGE_4K_PDE_ATTR (PAGE_ACCESSED + \
> +  PAGE_DIRTY + \
> +  PAGE_READ_WRITE + \
> +  PAGE_PRESENT)
> +
> +%define PAGE_PDP_ATTR (PAGE_ACCESSED + \
> +   PAGE_READ_WRITE + \
> +   PAGE_PRESENT)
> +
>  
>  ; 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
> @@ -117,6 +138,72 @@ BITS32
>  SevEsUnexpectedRespTerminate:
>  TerminateVmgExitTERM_UNEXPECTED_RESP_CODE
>  
> +; If SEV-ES is enabled then initialize the make the GHCB page shared

s/the make/and make/ ?

> +SevClearPageEncMaskFromGHCBPage:

Just a nit, maybe SevClearPageEncMaskForGhcbPage?

> +; Check if SEV is enabled
> +cmp   byte[WORK_AREA_GUEST_TYPE], 1
> +jnz   SevClearPageEncMaskFromGHCBPageExit
> +
> +; Check if SEV-ES is enabled
> +cmp   byte[SEV_ES_WORK_AREA], 1
> +jnz   SevClearPageEncMaskFromGHCBPageExit
> +
> +;
> +; 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_
> +add eax, PAGE_4K_PDE_ATTR
> +mov [ecx * 8 + GHCB_PT_ADDR - 8], eax
> +mov [(ecx * 8 + GHCB_PT_ADDR - 8) + 4], edx
> +looppageTableEntries4kLoop
> +
> +;
> +; Clear the encryption bit from the GHCB entry
> +;
> +mov ecx, (GHCB_BASE & 0x1F_) >> 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
> +loopclearGhcbMemoryLoop
> +
> +SevClearPageEncMaskFromGHCBPageExit:
> +OneTimeCallRet SevClearPageEncMaskFromGHCBPage
> +
> +; Check if SEV is enabled, and get the C-bit mask above 31.
> +; Modified: EDX
> +;
> +; The value is returned in the EDX
> +GetSevCBitMaskAbove31:
> +; Check if SEV is enabled
> +cmp   byte[WORK_AREA_GUEST_TYPE], 1
> +jnz   NoCbitValue
> +
> +mov   edx, dword[SEV_ES_WORK_AREA_ENC_MASK + 4]
> +jmp   GetSevCBitMaskAbove31Exit
> +
> +NoCbitValue:
> +xor   edx, edx

How about moving the xor as the first line of this routine and jumping to
GetSevCBitMaskAbove31Exit if the first cmp is non-zero. Then you can just
do the move from SEV_ES_WORK_AREA_ENC_MASK + 4 and eliminate the extra jmp
statement and NoCbitValue label.

Thanks,
Tom

> +
> +GetSevCBitMaskAbove31Exit:
> +OneTimeCallRet GetSevCBitMaskAbove31
> +
>  ; Check if Secure Encrypted Virtualization (SEV) features are enabled.
>  ;
>  ; Register usage is tight in this routine, so multiple calls for the
> @@ -249,32 +336,6 @@ SevExit:
>  
>  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 

Re: [edk2-devel] [PATCH v6 6/6] OvmfPkg/AmdSevDxe: Add support for SEV live migration.

[Lendacky, Thomas via groups.io]

On 8/10/21 6:13 AM, Ashish Kalra wrote:
> Hello Tom,
> 
> On Mon, Aug 09, 2021 at 09:29:29AM -0500, Tom Lendacky wrote:
>> On 8/2/21 7:33 AM, Ashish Kalra wrote:
>>
>> Should there be an "ASSERT_EFI_ERROR (Status)" after the DEBUG call?
>>
> 
> I don't think we should do an assert here and abort booting, failure
> here will simply disable live migration support but i don't think that
> it is such a fatal error that we should abort booting because of that.
> 
> OTOH, if there is a failure when doing page encryption status hypercalls
> then aborting boot makes sense as guest page encryption status tracking
> may be critical for multiple guest operations and not only live
> migration.

Makes sense.

Thanks,
Tom

> 
> Thanks,
> Ashish
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79029): https://edk2.groups.io/g/devel/message/79029
Mute This Topic: https://groups.io/mt/84609858/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 1/6] OvmfPkg/BaseMemEncryptLib: Detect SEV live migration feature.

[Lendacky, Thomas via groups.io]

On 8/10/21 1:05 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>>> I still really don't understand the need for the CPUID loop. KVM only ever
>>> programs CPUID function 0x4000, right?
> 
> Nope.  When you enable hyper-v emulation features you'll go find the kvm
> cpuid @ 0x4000 and the hyper-v cpuid @ 0x4100 (or the other way
> around, not sure).

Ah, thanks. I just saw the comment above get_out_of_range_cpuid_entry() in
arch/x86/kvm/cpuid.c where HyperV would get the 0x4000-0x40ff
range and KVM would then get the 0x4100-0x41ff range (basically
each hypervisor class gets their own 0x100 range).

Thanks,
Tom

> 
> take care,
>   Gerd
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79028): https://edk2.groups.io/g/devel/message/79028
Mute This Topic: https://groups.io/mt/84609830/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V9 2/4] OvmfPkg: Clear WORK_AREA_GUEST_TYPE in Main.asm

[Lendacky, Thomas via groups.io]

On 10/11/21 9:37 PM, Min Xu wrote:

RFC： 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3429data=04%7C01%7Cthomas.lendacky%40amd.com%7Cc4c4ac9654a940ada92308d98d2994d0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637696032012206979%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1SVRKXztfFcaVVer1AYOhLIhs6sVW%2BwtYQNxuuHHbTE%3Dreserved=0

Previously WORK_AREA_GUEST_TYPE was cleared in SetCr3ForPageTables64.
This is workable for Legacy guest and SEV guest. But it doesn't work
after Intel TDX is introduced. It is because all TDX CPUs (BSP and APs)
start to run from 0xfff0, thus WORK_AREA_GUEST_TYPE will be cleared
multi-times if it is TDX guest. So the clearance of WORK_AREA_GUEST_TYPE
is moved to Main16 entry point in Main.asm.
Note: WORK_AREA_GUEST_TYPE is only defined for ARCH_X64.

For Intel TDX, its corresponding entry point is Main32 (which will be
introduced in next commit in this patch-set). WORK_AREA_GUEST_TYPE will
be cleared there.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 4 
  OvmfPkg/ResetVector/Main.asm  | 8 
  2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 07b6ca070909..02528221e560 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -42,10 +42,6 @@ BITS32
  ;
  SetCr3ForPageTables64:
  
-; Clear the WorkArea header. The SEV probe routines will populate the

-; work area when detected.
-mov byte[WORK_AREA_GUEST_TYPE], 0
-
  ; Check whether the SEV is active and populate the SevEsWorkArea
  OneTimeCall   CheckSevFeatures
  
diff --git a/OvmfPkg/ResetVector/Main.asm b/OvmfPkg/ResetVector/Main.asm

index ae90a148fce7..a501fbe880f2 100644
--- a/OvmfPkg/ResetVector/Main.asm
+++ b/OvmfPkg/ResetVector/Main.asm
@@ -36,6 +36,14 @@ Main16:
  
  BITS32
  
+%ifdef ARCH_X64


A regular SEV guest can be built in the hybrid IA32 and X64 configuration, 
so this will break existing SEV firmwares built in that manner. Only 
SEV-ES and SEV-SNP require the full X64 confguration.


Thanks,
Tom


+
+; Clear the WorkArea header. The SEV probe routines will populate the
+; work area when detected.
+mov byte[WORK_AREA_GUEST_TYPE], 0
+
+%endif
+
  ;
  ; Search for the Boot Firmware Volume (BFV)
  ;




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81830): https://edk2.groups.io/g/devel/message/81830
Mute This Topic: https://groups.io/mt/86253724/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg/MemEncryptSevLib: check CPUID when read msr during PEI phase

[Lendacky, Thomas via groups.io]

On 11/25/21 7:12 AM, qi zhou wrote:

 From 5b10265fa5c7b5ca728b4f18488089de6535ed28 Mon Sep 17 00:00:00 2001
From: Qi Zhou 
Date: Thu, 25 Nov 2021 20:25:55 +0800
Subject: [PATCH] OvmfPkg/MemEncryptSevLib: check CPUID when read msr during
  PEI phase

Tested on Intel Platform, It is like 'SEV-ES work area' can be modified by
os(Windows etc), and will not restored on reboot, the
SevEsWorkArea->EncryptionMask may have a random value after reboot. then it
may casue fail on reboot. The msr bits already cached by mSevStatusChecked,
there is no need to try cache again in PEI phase.

Signed-off-by: Qi Zhou 
---
  .../PeiMemEncryptSevLibInternal.c | 55 +++
  1 file changed, 19 insertions(+), 36 deletions(-)

diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
index e2fd109d12..0819f50669 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c
@@ -38,49 +38,32 @@ InternalMemEncryptSevStatus (
UINT32RegEax;
MSR_SEV_STATUS_REGISTER   Msr;
CPUID_MEMORY_ENCRYPTION_INFO_EAX  Eax;
-  BOOLEAN   ReadSevMsr;
-  SEC_SEV_ES_WORK_AREA  *SevEsWorkArea;
  
-  ReadSevMsr = FALSE;

-
-  SevEsWorkArea = (SEC_SEV_ES_WORK_AREA *) FixedPcdGet32 
(PcdSevEsWorkAreaBase);
-  if (SevEsWorkArea != NULL && SevEsWorkArea->EncryptionMask != 0) {
-//
-// The MSR has been read before, so it is safe to read it again and avoid
-// having to validate the CPUID information.
+  //
+  // Check if memory encryption leaf exist
+  //
+  AsmCpuid (CPUID_EXTENDED_FUNCTION, , NULL, NULL, NULL);
+  if (RegEax >= CPUID_MEMORY_ENCRYPTION_INFO) {


This now defeats the purpose of the workarea the already validated CPUID 
information. This CPUID information will now require validating.


Wouldn't the best thing be to clear the workarea in the early boot code?

Thanks,
Tom


  //
-ReadSevMsr = TRUE;
-  } else {
+// CPUID Fn8000_001F[EAX] Bit 1 (Sev supported)
  //
-// Check if memory encryption leaf exist
-//
-AsmCpuid (CPUID_EXTENDED_FUNCTION, , NULL, NULL, NULL);
-if (RegEax >= CPUID_MEMORY_ENCRYPTION_INFO) {
+AsmCpuid (CPUID_MEMORY_ENCRYPTION_INFO, , NULL, NULL, NULL);
+
+if (Eax.Bits.SevBit) {
//
-  // CPUID Fn8000_001F[EAX] Bit 1 (Sev supported)
+  // Check MSR_0xC0010131 Bit 0 (Sev Enabled)
//
-  AsmCpuid (CPUID_MEMORY_ENCRYPTION_INFO, , NULL, NULL, NULL);
-
-  if (Eax.Bits.SevBit) {
-ReadSevMsr = TRUE;
+  Msr.Uint32 = AsmReadMsr32 (MSR_SEV_STATUS);
+  if (Msr.Bits.SevBit) {
+mSevStatus = TRUE;
}
-}
-  }
-
-  if (ReadSevMsr) {
-//
-// Check MSR_0xC0010131 Bit 0 (Sev Enabled)
-//
-Msr.Uint32 = AsmReadMsr32 (MSR_SEV_STATUS);
-if (Msr.Bits.SevBit) {
-  mSevStatus = TRUE;
-}
  
-//

-// Check MSR_0xC0010131 Bit 1 (Sev-Es Enabled)
-//
-if (Msr.Bits.SevEsBit) {
-  mSevEsStatus = TRUE;
+  //
+  // Check MSR_0xC0010131 Bit 1 (Sev-Es Enabled)
+  //
+  if (Msr.Bits.SevEsBit) {
+mSevEsStatus = TRUE;
+  }
  }
}
  




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84133): https://edk2.groups.io/g/devel/message/84133
Mute This Topic: https://groups.io/mt/87301748/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] OvmfPkg/OvmfPkgX64: Add SEV launch secret and hashes table areas to MEMFD

[Lendacky, Thomas via groups.io]

On 11/2/21 8:53 AM, Dov Murik wrote:



On 02/11/2021 15:29, Gerd Hoffmann wrote:

   Hi,


I'm wondering whenever you actually tried to boot a sev guest
in microvm?


No I haven't tried.  Do you want Microvm to be able to boot SEV guests,
or do you intentionally want to keep functionality out so it stays small?


Need to look at it on a case by case base.  It is clearly not a
priority, but if it makes sense we can discuss adding it.

microvm has no support for SMM mode, and that is unlikely to change,
so anything requiring SMM mode is not going to work, thats why I dropped
SMM + secure boot + TPM bits for the initial patch series.

Having support for tpm makes sense even without secure boot, so we might
bring that back, but it'll also require some (small) changes on the host
side so qemu allows creating a tpm, generates acpi tables for the tpm etc.

Does SEV need and/or use SMM mode?  Looking through AmdSevX64.dsc
doesn't give a clear answer, on one hand there is a
LibraryClasses.common.SMM_CORE section, but on the other hand it uses
the non-SMM variable driver stack.


I think SEV doesn't work with SMM.  James - can you please give a more
definitive answer here?


SEV works with SMM, but SEV-ES (and likely SEV-SNP) doesn't work with SMM 
because of the fact that the hypervisor wants to change the guest register 
state to enter SMM, which isn't allowed and results in a VMRUN failure.


It might be possible to get SMM to work by having separate VMSAs for the 
SMM state, but it is not anything that really has been investigated too 
deeply.


Thanks,
Tom



-Dov




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#83136): https://edk2.groups.io/g/devel/message/83136
Mute This Topic: https://groups.io/mt/86761214/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 12/28] UefiCpuPkg/CpuExceptionHandler: Add base support for the #VE exception

[Lendacky, Thomas via groups.io]

On 10/28/21 10:52 AM, Yao, Jiewen wrote:

Thanks Brijesh.

We can merge SNP patches at first, then decide next step. Not a problem.

TEE is just my initial thought. And I am open to change if we have a better 
name.

We already have EFI_TEE_MEASUREMENT_PROTOCOL. I did not see your feedback on 
that. So I assume you agree with that.

If you have different idea, please feedback to this patch. I hope we have one 
name.

COCO seems weird to me, btw. :(


Like Brijesh, I worry about confusion with the ARM TEE feature. Maybe just 
CC then?


Thanks,
Tom



Thank you
Yao Jiewen


-Original Message-
From: Brijesh Singh 
Sent: Thursday, October 28, 2021 11:35 PM
To: Yao, Jiewen ; kra...@redhat.com; Xu, Min M

Cc: brijesh.si...@amd.com; devel@edk2.groups.io; Erdem Aktas
; James Bottomley ; Tom
Lendacky ; Dong, Eric ; Ni,
Ray ; Kumar, Rahul1 
Subject: Re: [edk2-devel] [PATCH V2 12/28] UefiCpuPkg/CpuExceptionHandler:
Add base support for the #VE exception



On 10/27/21 8:59 PM, Yao, Jiewen wrote:

Hi Gerd
I tend to agree with you on the direction to use one TEE specific Exception lib.

However, I have naming concern.
The VMG is very SEV specific term. I don't believe it is a right name to cover

the TEE exception lib.


If Brijesh agree to merge, I think we should rename it to a neutral name, such

as TeeExitLib.


What do you think, Brijesh?


I am good with merging both the TDX and SEV feature into one library but
I am not sure about the "TEE" name in it. TEE generally is used on the
ARM. In Linux kernel and everywhere else we have been using the COCO
(Confidential Computing), so something along that line makes much more
sense.

We can rename the library after the SNP patches are merged. I would
prefer to avoid renaming because all of the SNP patches are Ack-ed.

-Brijesh


Thank you
Yao Jiewen



-Original Message-
From: kra...@redhat.com 
Sent: Wednesday, October 27, 2021 3:20 PM
To: Xu, Min M 
Cc: Brijesh Singh ; Yao, Jiewen
; devel@edk2.groups.io; Erdem Aktas
; James Bottomley ; Tom
Lendacky ; Dong, Eric ;

Ni,

Ray ; Kumar, Rahul1 
Subject: Re: [edk2-devel] [PATCH V2 12/28]

UefiCpuPkg/CpuExceptionHandler:

Add base support for the #VE exception

Hi,


How about adding the tdx exception handler to the existing library, so we

don't

have the churn of adding a new library everywhere *again*?



Do you mean add the VmTdExitVeHandler.c/VmTdExitLibNull.c in

CpuExceptionHandlerLib, then include the corresponding source file in each
*CpuExceptionHandlerLib.inf?

No, I mean extend the existing VmgExitLib instead of adding a new
VmTdExitLib, i.e. place the tdx handler in
OvmfPkg/Library/VmgExitLib/TdxExitHandler.c

take care,
Gerd





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#82818): https://edk2.groups.io/g/devel/message/82818
Mute This Topic: https://groups.io/mt/86085742/21656
Mute #ve:https://edk2.groups.io/g/devel/mutehashtag/ve
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3 14/29] UefiCpuPkg: Enable Tdx support in MpInitLib

[Lendacky, Thomas via groups.io]

On 11/4/21 3:10 AM, Gerd Hoffmann wrote:

On Wed, Nov 03, 2021 at 12:57:37PM +, Xu, Min M wrote:

On November 3, 2021 2:09 PM, Gerd Hoffmann wrote:

+++ b/UefiCpuPkg/Library/MpInitLib/X64/IntelTdcall.nasm
@@ -0,0 +1,120 @@
+;
+--
+;*
+;* Copyright (c) 2020 - 2021, Intel Corporation. All rights
+reserved.
+;* SPDX-License-Identifier: BSD-2-Clause-Patent
+;*
+;*
+;
+--
+
+DEFAULT REL
+SECTION .text
+
+%macro tdcall 0
+db 0x66,0x0f,0x01,0xcc
+%endmacro


Hmm, could you just use TdxLib instead of bringing your own copy of the
assembler code?



My initial thought was to include TdxLib in the .dsc as little as
possible. For example, DxeMpInitLib is included in
OvmfPkg/Microvm/MicrovmX64.dsc. If TdxLib is used by DxeMpInitLib,
then it has to be included in MicrovmX64.dsc as well.


Hmm, yes.  Adding a TdxLib dependency has its downsides indeed.


So I copy the assemble code in MpInitLib.


The problem with copying code is that long-term maintenance becomes
harder.  When a bug is found you have to find and fix all the copies of
that code.  That's why I strongly prefer to avoid code copy
Sometimes there is no easy way around creating a copy though.


Can't you create something in MdePkg/Library/Baselib and then use it 
everywhere it's needed?


Thanks,
Tom



take care,
   Gerd




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#83349): https://edk2.groups.io/g/devel/message/83349
Mute This Topic: https://groups.io/mt/86739862/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 08/11] OvmfPkg/AmdSev/SecretPei: build hob for full page

[Lendacky, Thomas via groups.io]

On 7/20/21 3:03 AM, Dov Murik wrote:
> 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 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Signed-off-by: Dov Murik 

Reviewed-by: Tom Lendacky 

> ---
>  OvmfPkg/AmdSev/SecretPei/SecretPei.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77974): https://edk2.groups.io/g/devel/message/77974
Mute This Topic: https://groups.io/mt/84328282/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 07/11] OvmfPkg/QemuKernelLoaderFsDxe: call VerifyBlob after fetch from fw_cfg

[Lendacky, Thomas via groups.io]

On 7/20/21 3:03 AM, Dov Murik wrote:
> 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 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Co-developed-by: James Bottomley 
> Signed-off-by: James Bottomley 
> Signed-off-by: Dov Murik 

Reviewed-by: Tom Lendacky 

> Reviewed-by: Brijesh Singh 
> ---
>  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c | 9 +
>  1 file changed, 9 insertions(+)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77973): https://edk2.groups.io/g/devel/message/77973
Mute This Topic: https://groups.io/mt/84328260/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 10/11] OvmfPkg: add BlobVerifierLibSevHashes

[Lendacky, Thomas via groups.io]

On 7/20/21 3:04 AM, Dov Murik wrote:
> 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 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Co-developed-by: James Bottomley 
> Signed-off-by: James Bottomley 
> Signed-off-by: Dov Murik 

A comment about the use of INT32 in the for loop to protect against a
large entry length value would be useful. I don't think it's worth another
version, but if you have to make any updates it would be nice to add.

Reviewed-by: Tom Lendacky 

> ---
>  OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf |  37 
>  OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c  | 200 
> 
>  2 files changed, 237 insertions(+)
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77979): https://edk2.groups.io/g/devel/message/77979
Mute This Topic: https://groups.io/mt/84328241/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 05/11] OvmfPkg: add BlobVerifierLibNull to DSC

[Lendacky, Thomas via groups.io]

On 7/20/21 3:03 AM, Dov Murik wrote:
> This prepares the ground for calling VerifyBlob() in
> QemuKernelLoaderFsDxe.
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Signed-off-by: Dov Murik 

Reviewed-by: Tom Lendacky 

> ---
>  OvmfPkg/AmdSev/AmdSevX64.dsc | 6 +-
>  OvmfPkg/OvmfPkgIa32.dsc  | 5 -
>  OvmfPkg/OvmfPkgIa32X64.dsc   | 5 -
>  OvmfPkg/OvmfPkgX64.dsc   | 5 -
>  4 files changed, 17 insertions(+), 4 deletions(-)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77972): https://edk2.groups.io/g/devel/message/77972
Mute This Topic: https://groups.io/mt/84328243/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 11/11] OvmfPkg/AmdSev: Enforce hash verification of kernel blobs

[Lendacky, Thomas via groups.io]

On 7/20/21 3:04 AM, Dov Murik wrote:
> 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 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Signed-off-by: Dov Murik 

Reviewed-by: Tom Lendacky 

> ---
>  OvmfPkg/AmdSev/AmdSevX64.dsc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77980): https://edk2.groups.io/g/devel/message/77980
Mute This Topic: https://groups.io/mt/84328242/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 00/11] Measured SEV boot with kernel/initrd/cmdline

[Lendacky, Thomas via groups.io]

On 7/20/21 3:03 AM, Dov Murik wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3457

I believe the convention is that this line be in the individual patch
commit messages just like this (i.e. with the BZ: tag and the first line),
not as a Ref: tag at the end of the commit message.

I'll let Ard decide on that, though.

Thanks,
Tom

> 
> 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-dovmu...@linux.ibm.com/
> 
> Code is at
> https://github.com/confidential-containers-demo/edk2/tree/sev-hashes-v3
> 
> 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 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen 

Re: [edk2-devel] [PATCH v3 04/11] OvmfPkg: add library class BlobVerifierLib with null implementation

[Lendacky, Thomas via groups.io]

On 7/20/21 3:03 AM, Dov Murik wrote:
> 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 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Signed-off-by: Dov Murik 

Reviewed-by: Tom Lendacky 

> ---
>  OvmfPkg/OvmfPkg.dec |  3 ++
>  OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf | 24 +
>  OvmfPkg/Include/Library/BlobVerifierLib.h   | 38 
> 
>  OvmfPkg/Library/BlobVerifierLib/BlobVerifierNull.c  | 33 
> +
>  4 files changed, 98 insertions(+)
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77971): https://edk2.groups.io/g/devel/message/77971
Mute This Topic: https://groups.io/mt/84328238/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 03/11] OvmfPkg: PlatformBootManagerLibGrub: Allow executing kernel via fw_cfg

[Lendacky, Thomas via groups.io]

On 7/6/21 3:54 AM, Dov Murik wrote:
> From: James Bottomley 
> 
> Support QEMU's -kernel option.
> 
> OvmfPkg/Library/PlatformBootManagerLibGrub/QemuKernel.c is an exact copy
> of OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c .

Just a nit, but this confused me initially. Maybe it should say something
along the lines of create a QemuKernel.c for PlatformBootManagerLibGrub
that is an exact copy of the file from PlatformBootManagerLib.

Is there any way that the two libraries can use the same file rather than
making an exact copy?

Thanks,
Tom

> 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Signed-off-by: James Bottomley 
> ---
>  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 => 
> PlatformBootManagerLibGrub}/QemuKernel.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/PeiCpuExceptionHandlerLib.inf
>MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
>QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
> +  
> QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf
>  
> diff --git 
> a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf 
> b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf
> index 9a806d17ec45..5f6f73d18470 100644
> --- 
> a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf
> +++ 
> b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf
> @@ -23,6 +23,7 @@ [Defines]
>  
>  [Sources]
>BdsPlatform.c
> +  QemuKernel.c
>PlatformData.c
>BdsPlatform.h
>  
> @@ -46,6 +47,7 @@ [LibraryClasses]
>BootLogoLib
>DevicePathLib
>PciLib
> +  QemuLoadImageLib
>UefiLib
>PlatformBmPrintScLib
>Tcg2PhysicalPresenceLib
> diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h 
> b/OvmfPkg/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
>);
>  
> +/**
> +  Loads and boots UEFI Linux via the FwCfg interface.
> +
> +  @retvalEFI_NOT_FOUND - The Linux kernel was not found
> +
> +**/
> +EFI_STATUS
> +TryRunningQemuKernel (
> +  VOID
> +  );
> +
>  #endif // _PLATFORM_SPECIFIC_BDS_PLATFORM_H_
> diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c 
> b/OvmfPkg/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 (
>//
>Tcg2PhysicalPresenceLibProcessRequest (NULL);
>  
> +  //
> +  // Process QEMU's -kernel command line option
> +  //
> +  TryRunningQemuKernel ();
> +
>//
>// Perform some platform specific connect sequence
>//
> 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
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77901): https://edk2.groups.io/g/devel/message/77901
Mute This Topic: https://groups.io/mt/84016356/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 08/11] OvmfPkg/AmdSev/SecretPei: build hob for full page

[Lendacky, Thomas via groups.io]

On 7/6/21 3:54 AM, Dov Murik wrote:
> 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: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Signed-off-by: Dov Murik 
> ---
>  OvmfPkg/AmdSev/SecretPei/SecretPei.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/AmdSev/SecretPei/SecretPei.c 
> b/OvmfPkg/AmdSev/SecretPei/SecretPei.c
> index ad491515dd5d..db4267428e5a 100644
> --- a/OvmfPkg/AmdSev/SecretPei/SecretPei.c
> +++ b/OvmfPkg/AmdSev/SecretPei/SecretPei.c
> @@ -15,9 +15,16 @@ InitializeSecretPei (
>IN CONST EFI_PEI_SERVICES **PeiServices
>)
>  {
> +  UINT64 RoundedSize;
> +
> +  RoundedSize = PcdGet32 (PcdSevLaunchSecretSize);

Can you just unconditionally perform:

  RoundedSize = ALIGN_VALUE (RoundedSize, EFI_PAGE_SIZE);

Or use ALIGN_VALUE () in the if statement if you don't want to do it
unconditionally?

Or even use ALIGN_VALUE on size value in the BuildMemoryAllocationHob()
call below.

Thanks,
Tom

> +  if (RoundedSize % EFI_PAGE_SIZE != 0) {
> +RoundedSize = (RoundedSize / EFI_PAGE_SIZE + 1) * EFI_PAGE_SIZE;
> +  }
> +
>BuildMemoryAllocationHob (
>  PcdGet32 (PcdSevLaunchSecretBase),
> -PcdGet32 (PcdSevLaunchSecretSize),
> +RoundedSize,
>  EfiBootServicesData
>  );
>  
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77908): https://edk2.groups.io/g/devel/message/77908
Mute This Topic: https://groups.io/mt/84016362/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 04/11] OvmfPkg: add library class BlobVerifierLib with null implementation

[Lendacky, Thomas via groups.io]

On 7/6/21 3:54 AM, Dov Murik wrote:
> 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 NullBlobVerifierLib treats all blobs as valid.
> 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Signed-off-by: Dov Murik 
> ---
>  OvmfPkg/OvmfPkg.dec |  3 ++
>  OvmfPkg/Library/BlobVerifierLib/NullBlobVerifierLib.inf | 27 ++
>  OvmfPkg/Include/Library/BlobVerifierLib.h   | 38 
> 
>  OvmfPkg/Library/BlobVerifierLib/NullBlobVerifier.c  | 34 
> ++
>  4 files changed, 102 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.
>BhyveFwCtlLib|Include/Library/BhyveFwCtlLib.h
>  
> +  ##  @libraryclass  Verify blobs read from the VMM
> +  BlobVerifierLib|Include/Library/BlobVerifierLib.h
> +
>##  @libraryclass  Loads and boots a Linux kernel image
>#
>LoadLinuxLib|Include/Library/LoadLinuxLib.h
> diff --git a/OvmfPkg/Library/BlobVerifierLib/NullBlobVerifierLib.inf 
> b/OvmfPkg/Library/BlobVerifierLib/NullBlobVerifierLib.inf
> new file mode 100644
> index ..c8942ad05d96
> --- /dev/null
> +++ b/OvmfPkg/Library/BlobVerifierLib/NullBlobVerifierLib.inf
> @@ -0,0 +1,27 @@
> +## @file
> +#
> +#  Null implementation of the blob verifier library.
> +#
> +#  Copyright (C) 2021, IBM Corp
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005

You can specify the INF_VERSION using x.y format now, and I believe the
latest is 1.29.

> +  BASE_NAME  = NullBlobVerifierLib

Typically, the NULL libraries would be named BlobVerifierLibNull.

> +  FILE_GUID  = b1b5533e-e01a-43bb-9e54-414f00ca036e
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = BlobVerifierLib
> +
> +[Sources]
> +  NullBlobVerifier.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  OvmfPkg/OvmfPkg.dec
> +
> +[LibraryClasses]
> +  DebugLib

Is this library (and associated include below) needed?

> diff --git a/OvmfPkg/Include/Library/BlobVerifierLib.h 
> b/OvmfPkg/Include/Library/BlobVerifierLib.h
> new file mode 100644
> index ..667024766681
> --- /dev/null
> +++ b/OvmfPkg/Include/Library/BlobVerifierLib.h
> @@ -0,0 +1,38 @@
> +/** @file
> +
> +  Blob verification library
> +
> +  This library class allows verifiying whether blobs from external sources
> +  (such as QEMU's firmware config) are trusted.
> +
> +  Copyright (C) 2021, IBM Corporation
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#ifndef BLOB_VERIFIER_LIB_H__
> +#define BLOB_VERIFIER_LIB_H__
> +
> +#include 
> +#include 
> +
> +/**
> +  Verify blob from an external source.
> +
> +  @param BlobName   The name of the blob

I believe this is supposed to be @param[in]

> +  @param BufThe data of the blob
> +  @param BufSizeThe size of the blob in bytes
> +
> +  @retval EFI_SUCCESS   The blob was verified successfully.
> +  @retval EFI_ACCESS_DENIED The blob could not be verified, and therefore
> +should be considered non-secure.
> +**/
> +EFI_STATUS
> +EFIAPI
> +VerifyBlob (
> +  IN  CONST CHAR16*BlobName,
> +  IN  CONST VOID  *Buf,
> +  UINT32  BufSize

Missing "IN" here (same below for these).

Thanks,
Tom

> +  );
> +
> +#endif
> diff --git a/OvmfPkg/Library/BlobVerifierLib/NullBlobVerifier.c 
> b/OvmfPkg/Library/BlobVerifierLib/NullBlobVerifier.c
> new file mode 100644
> index ..7b31b6ec767d
> --- /dev/null
> +++ b/OvmfPkg/Library/BlobVerifierLib/NullBlobVerifier.c
> @@ -0,0 +1,34 @@
> +/** @file
> +
> +  Null implementation of the blob verifier library.
> +
> +  Copyright (C) 2021, IBM Corporation
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> +  Verify blob from an external source.
> +
> +  @param BlobName   The name of the blob
> +  @param BufThe data of the blob
> +  @param BufSizeThe size of the blob in bytes
> +
> +  @retval EFI_SUCCESS   The blob was verified successfully.
> +  @retval EFI_ACCESS_DENIED The blob could not be verified, and therefore
> +should be considered non-secure.
> +**/
> +EFI_STATUS
> +EFIAPI
> +VerifyBlob (
> +  IN  

Re: [edk2-devel] [PATCH v2 00/11] Measured SEV boot with kernel/initrd/cmdline

[Lendacky, Thomas via groups.io]

On 7/6/21 3:54 AM, Dov Murik wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3457

This BZ link should be part of all the commit messages in the series.

Thanks,
Tom

> 
> 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
> theses hashes are part of the SEV measurement (which has to be approved
> by the Guest Owner for secret injection, for example).  Note that this
> requires QEMU support [1].
> 
> OVMF parses the table of hashes populated by QEMU (patch 5), and as it
> reads the fw_cfg blobs from QEMU, it will verify each one against the
> expected hash (kernel and initrd verifiers are introduced in patch 6,
> and command-line verifier is introduced in patches 7+8).  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:
> 
>   ...
>   SevHashesBlobVerifierLibConstructor: 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 entry '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 entry '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 entry '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 SevHashesBlobVerifierLib and use it in
>AmdSevX64 builds.
> 
> [1] 
> https://lore.kernel.org/qemu-devel/20210624102040.2015280-1-dovmu...@linux.ibm.com/
> 
> Code is at
> https://github.com/confidential-containers-demo/edk2/tree/sev-hashes-v2
> 
> 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: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Cc: Leif Lindholm 
> Cc: Sami Mujawar 
> 
> Dov Murik (8):
>   OvmfPkg/AmdSev: use GenericQemuLoadImageLib in AmdSev builds
>   OvmfPkg: add library class BlobVerifierLib with null implementation
>   OvmfPkg: add NullBlobVerifierLib to DSC
>   ArmVirtPkg: add NullBlobVerifierLib to DSC
>   OvmfPkg/QemuKernelLoaderFsDxe: call VerifyBlob after fetch from fw_cfg
>   OvmfPkg/AmdSev/SecretPei: build hob for full page
>   OvmfPkg: add SevHashesBlobVerifierLib
>   OvmfPkg/AmdSev: Enforce hash verification of kernel blobs
> 
> James Bottomley (3):
>   OvmfPkg/AmdSev/SecretDxe: fix header comment to generic 

Re: [edk2-devel] [PATCH v2 09/11] OvmfPkg/AmdSev: reserve MEMFD space for for firmware config hashes

[Lendacky, Thomas via groups.io]

On 7/6/21 3:54 AM, Dov Murik wrote:
> From: James Bottomley 
> 
> 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: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Co-developed-by: Dov Murik 
> Signed-off-by: Dov Murik 
> Signed-off-by: James Bottomley 

Reviewed by: Tom Lendacky 

> ---
>  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
>gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize|0x0|UINT32|0x43
>  
> +  ## The base address and size of a hash table confirming allowed
> +  #  parameters to be passed in via the Qemu firmware configuration
> +  #  device
> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|0x0|UINT32|0x47
> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize|0x0|UINT32|0x48
> +
>  [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 9977b0f00a18..0a89749700c3 100644
> --- a/OvmfPkg/AmdSev/AmdSevX64.fdf
> +++ b/OvmfPkg/AmdSev/AmdSevX64.fdf
> @@ -59,9 +59,12 @@ [FD.MEMFD]
>  0x00B000|0x001000
>  
> gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
>  
> -0x00C000|0x001000
> +0x00C000|0x000C00
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
>  
> +0x00CC00|0x000400
> +gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
> +
>  0x00D000|0x001000
>  
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize
>  
> diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
> b/OvmfPkg/ResetVector/ResetVector.inf
> index dc38f68919cd..d028c92d8cfa 100644
> --- a/OvmfPkg/ResetVector/ResetVector.inf
> +++ b/OvmfPkg/ResetVector/ResetVector.inf
> @@ -47,3 +47,5 @@ [Pcd]
>  [FixedPcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase
>gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase
> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm 
> b/OvmfPkg/ResetVector/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
>  ;
>  guidedStructureStart:
>  
> +; SEV Hash Table Block
>  ;
> +; This describes the guest ram area where the hypervisor should
> +; install a table describing the hashes of certain firmware configuration
> +; device files that would otherwise be passed in unchecked.  The current
> +; use is for the kernel, initrd and command line values, but others may be
> +; added.  The data format is:
> +;
> +; base physical address (32 bit word)
> +; table length (32 bit word)
> +;
> +; GUID (SEV FW config hash block): 7255371f-3a3b-4b04-927b-1da6efa8d454
> +;
> +sevFwHashBlockStart:
> +DD  SEV_FW_HASH_BLOCK_BASE
> +DD  SEV_FW_HASH_BLOCK_SIZE
> +DW  sevFwHashBlockEnd - sevFwHashBlockStart
> +DB  0x1f, 0x37, 0x55, 0x72, 0x3b, 0x3a, 0x04, 0x4b
> +DB  0x92, 0x7b, 0x1d, 0xa6, 0xef, 0xa8, 0xd4, 0x54
> +sevFwHashBlockEnd:
> +
>  ; SEV Secret block
>  ;
>  ; This describes the guest ram area where the hypervisor should
> diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
> b/OvmfPkg/ResetVector/ResetVector.nasmb
> index 5fbacaed5f9d..8d0bab02f8cb 100644
> --- a/OvmfPkg/ResetVector/ResetVector.nasmb
> +++ b/OvmfPkg/ResetVector/ResetVector.nasmb
> @@ -88,5 +88,7 @@
>%define 

Re: [edk2-devel] [PATCH v2 10/11] OvmfPkg: add SevHashesBlobVerifierLib

[Lendacky, Thomas via groups.io]

On 7/6/21 3:55 AM, Dov Murik wrote:
> 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: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Co-developed-by: James Bottomley 
> Signed-off-by: James Bottomley 
> Signed-off-by: Dov Murik 
> ---
>  OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifierLib.inf |  36 
>  OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifier.c  | 199 
> 
>  2 files changed, 235 insertions(+)
> 
> diff --git a/OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifierLib.inf 
> b/OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifierLib.inf
> new file mode 100644
> index ..b060d6a1b545
> --- /dev/null
> +++ b/OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifierLib.inf
> @@ -0,0 +1,36 @@
> +## @file
> +#
> +#  Blob verifier library that uses SEV hashes table.
> +#
> +#  Copyright (C) 2021, IBM Corp
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +

Same comments here as were made on the Null library instance.

> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = SevHashesBlobVerifierLib
> +  FILE_GUID  = 59e713b5-eff3-46a7-8d8b-46f4c004ad7b
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = BlobVerifierLib
> +  CONSTRUCTOR= SevHashesBlobVerifierLibConstructor
> +
> +[Sources]
> +  SevHashesBlobVerifier.c
> +
> +[Packages]
> +  CryptoPkg/CryptoPkg.dec
> +  MdePkg/MdePkg.dec
> +  OvmfPkg/OvmfPkg.dec
> +
> +[LibraryClasses]
> +  BaseCryptLib
> +  BaseMemoryLib
> +  DebugLib
> +  PcdLib
> +
> +[FixedPcd]
> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase
> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
> diff --git a/OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifier.c 
> b/OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifier.c
> new file mode 100644
> index ..961ee29f5df3
> --- /dev/null
> +++ b/OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifier.c
> @@ -0,0 +1,199 @@
> +/** @file
> +
> +  Blob verifier library that uses SEV hashes table.
> +
> +  Copyright (C) 2021, IBM Corporation
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> +  The SEV Hashes table must be in encrypted memory and has the table
> +  and its entries described by
> +
> +  |UINT16 |
> +
> +  With the whole table GUID being 9438d606-4f22-4cc9-b479-a793d411fd21
> +
> +  The current possible table entries are for the kernel, the initrd
> +  and the cmdline:
> +
> +  4de79437-abd2-427f-b835-d5b172d2045b  kernel
> +  44baf731-3a2f-4bd7-9af1-41e29169781d  initrd
> +  97d02dd8-bd20-4c94-aa78-e7714d36ab2a  cmdline
> +
> +  The size of the entry is used to identify the hash, but the
> +  expectation is that it will be 32 bytes of SHA-256.
> +**/
> +
> +#define SEV_HASH_TABLE_GUID \
> +  (GUID) { 0x9438d606, 0x4f22, 0x4cc9, { 0xb4, 0x79, 0xa7, 0x93, 0xd4, 0x11, 
> 0xfd, 0x21 } }
> +#define SEV_KERNEL_HASH_GUID \
> +  (GUID) { 0x4de79437, 0xabd2, 0x427f, { 0xb8, 0x35, 0xd5, 0xb1, 0x72, 0xd2, 
> 0x04, 0x5b } }
> +#define SEV_INITRD_HASH_GUID \
> +  (GUID) { 0x44baf731, 0x3a2f, 0x4bd7, { 0x9a, 0xf1, 0x41, 0xe2, 0x91, 0x69, 
> 0x78, 0x1d } }
> +#define SEV_CMDLINE_HASH_GUID \
> +  (GUID) { 0x97d02dd8, 0xbd20, 0x4c94, { 0xaa, 0x78, 0xe7, 0x71, 0x4d, 0x36, 
> 0xab, 0x2a } }
> +
> +STATIC CONST EFI_GUID mSevKernelHashGuid = SEV_KERNEL_HASH_GUID;
> +STATIC CONST EFI_GUID mSevInitrdHashGuid = SEV_INITRD_HASH_GUID;
> +STATIC CONST EFI_GUID mSevCmdlineHashGuid = SEV_CMDLINE_HASH_GUID;
> +
> +#pragma pack (1)
> +typedef struct {
> +  GUID   Guid;
> +  UINT16 Len;
> +  UINT8  Data[];
> +} HASH_TABLE;
> +#pragma pack ()
> +
> +STATIC HASH_TABLE *mHashesTable;
> +STATIC UINT16 mHashesTableSize;
> +
> +STATIC
> +CONST GUID*
> +FindBlobEntryGuid (
> +  IN  CONST CHAR16*BlobName
> +  )
> +{
> +  if (StrCmp (BlobName, L"kernel") == 0) {
> +return 
> +  } else if (StrCmp (BlobName, L"initrd") == 0) {
> +return 
> +  } else if (StrCmp (BlobName, L"cmdline") == 0) {
> +return 
> +  } else {
> +return NULL;
> +  }
> +}
> +
> +/**
> +  Verify blob from an external source.
> +
> +  @param BlobName   The name of the blob
> +  @param BufThe data of the blob
> +  @param BufSizeThe size of the blob in bytes
> +
> +  @retval EFI_SUCCESS   The 

Re: [edk2-devel] [PATCH v2 07/11] OvmfPkg/QemuKernelLoaderFsDxe: call VerifyBlob after fetch from fw_cfg

[Lendacky, Thomas via groups.io]

On 7/6/21 3:54 AM, Dov Murik wrote:
> 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: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Co-developed-by: James Bottomley 
> Signed-off-by: James Bottomley 
> Signed-off-by: Dov Murik 
> ---
>  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c 
> b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
> index c7ddd86f5c75..b43330d23b80 100644
> --- a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
> +++ b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1039,6 +1040,14 @@ QemuKernelLoaderFsDxeEntrypoint (
>  if (EFI_ERROR (Status)) {
>goto FreeBlobs;
>  }
> +Status = VerifyBlob (
> +   CurrentBlob->Name,
> +   CurrentBlob->Data,
> +   CurrentBlob->Size
> + );

Just a nit, but the ");" should be under the "C" in CurrentBlob.

Thanks,
Tom

> +if (EFI_ERROR (Status)) {
> +  goto FreeBlobs;
> +}
>  mTotalBlobBytes += CurrentBlob->Size;
>}
>KernelBlob  = [KernelBlobTypeKernel];
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77906): https://edk2.groups.io/g/devel/message/77906
Mute This Topic: https://groups.io/mt/84016359/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 11/11] OvmfPkg/AmdSev: Enforce hash verification of kernel blobs

[Lendacky, Thomas via groups.io]

On 7/6/21 3:55 AM, Dov Murik wrote:
> In the AmdSevX86 build, use SevHashesBlobVerifierLib 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: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Signed-off-by: Dov Murik 

Reviewed-by: Tom Lendacky 

> ---
>  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 8b260df114e3..d1ed0abbd0fb 100644
> --- a/OvmfPkg/AmdSev/AmdSevX64.dsc
> +++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
> @@ -173,7 +173,7 @@ [LibraryClasses]
>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
> -  BlobVerifierLib|OvmfPkg/Library/BlobVerifierLib/NullBlobVerifierLib.inf
> +  
> BlobVerifierLib|OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifierLib.inf
>  
>  !if $(SOURCE_DEBUG_ENABLE) == TRUE
>
> PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf
> @@ -696,7 +696,7 @@ [Components]
>}
>OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
>  
> -  NULL|OvmfPkg/Library/BlobVerifierLib/NullBlobVerifierLib.inf
> +  NULL|OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifierLib.inf
>}
>OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>OvmfPkg/Virtio10Dxe/Virtio10.inf
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77913): https://edk2.groups.io/g/devel/message/77913
Mute This Topic: https://groups.io/mt/84016365/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte Page Granularity

[Lendacky, Thomas via groups.io]

On 7/19/21 2:09 AM, Ard Biesheuvel via groups.io wrote:
> On Mon, 19 Jul 2021 at 05:14, Ni, Ray  wrote:
>>
>> This change generates the reset vector binary which only contains 1G page 
>> table. If a platform doesn't support 1G page table, this will cause system 
>> hang.
>>
>> To Ard and Jordan,
>> Can you evaluate whether this change impacts OVMF?
>>
> 
> I don't have a clue, sorry, and I wouldn't know where to begin looking.
> 
> Brijesh, Dov, James, Erdem: after Laszlo's sudden departure, I will be
> needing help reviewing OVMF patches that are highly specific to
> SEV/SNP or x86 in general.
> 
> Please take a look.

I think this is OK for Ovmf (others on the email, please double check me).
Ovmf includes its own version of ResetVector.nasmb (in place of
Vtf0.nasmb) which includes its own version of Ia32/PageTables64.asm and
never does an include for X64/PageTables.asm.

Thanks,
Tom

> 
> 
>> To Prince,
>> Can you evaluate whether this change impacts SimicsOpenBoardPkg?
>>
>> Thanks,
>> Ray
>>
>> -Original Message-
>> From: S, Ashraf Ali 
>> Sent: Friday, July 2, 2021 8:25 PM
>> To: devel@edk2.groups.io
>> Cc: S, Ashraf Ali ; Ni, Ray ; 
>> Kumar, Rahul1 ; De, Debkumar 
>> ; Han, Harry ; West, Catharine 
>> ; V, Sangeetha 
>> Subject: [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte Page 
>> Granularity
>>
>> REF:https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3473data=04%7C01%7Cthomas.lendacky%40amd.com%7Ccf73602f1b224340970a08d94a84399d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637622754052197154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8gFLRyPEvbfwNN6BDimRe0spZfrNkMFdl6J9fYIe4RE%3Dreserved=0
>>
>> X64 Reset Vector Code can access the memory range till 4GB using the 
>> Linear-Address Translation to a 2-MByte Page, when user wants to use more 
>> than 4G using 2M Page it will leads to use more number of Page table 
>> entries. using the 1-GByte Page table user can use more than 4G Memory by 
>> reducing the page table entries using 1-GByte Page, this patch attached can 
>> access memory range till 512GByte.
>> Build Scrips for Reset Vector currently based on Python 2 which is already 
>> EOL, needs to modify the build script based on Python 3, update the Binary 
>> accordingly.
>>
>> Cc: Ray Ni 
>> Cc: Rahul Kumar 
>> Cc: Debkumar De 
>> Cc: Harry Han 
>> Cc: Catharine West 
>> Cc: Sangeetha V 
>> Signed-off-by: Ashraf Ali S 
>> ---
>>  .../Vtf0/Bin/ResetVector.ia32.port80.raw  | Bin 516 -> 484 bytes
>>  .../ResetVector/Vtf0/Bin/ResetVector.ia32.raw | Bin 484 -> 468 bytes
>>  .../Vtf0/Bin/ResetVector.ia32.serial.raw  | Bin 884 -> 868 bytes
>>  .../Vtf0/Bin/ResetVector.x64.port80.raw   | Bin 28676 -> 12292 bytes
>>  .../ResetVector/Vtf0/Bin/ResetVector.x64.raw  | Bin 28676 -> 12292 bytes
>>  .../Vtf0/Bin/ResetVector.x64.serial.raw   | Bin 28676 -> 12292 bytes
>>  UefiCpuPkg/ResetVector/Vtf0/Build.py  |  11 +--
>>  .../ResetVector/Vtf0/Ia32/PageTables64.asm|   2 +-
>>  UefiCpuPkg/ResetVector/Vtf0/ReadMe.txt|   2 +-
>>  .../Vtf0/Tools/FixupForRawSection.py  |   4 +-
>>  UefiCpuPkg/ResetVector/Vtf0/Vtf0.nasmb|   4 +-
>>  .../ResetVector/Vtf0/X64/1GPageTables.asm |  64 ++
>>  .../X64/{PageTables.asm => 2MPageTables.asm}  |   0
>>  13 files changed, 77 insertions(+), 10 deletions(-)  create mode 100644 
>> UefiCpuPkg/ResetVector/Vtf0/X64/1GPageTables.asm
>>  rename UefiCpuPkg/ResetVector/Vtf0/X64/{PageTables.asm => 2MPageTables.asm} 
>> (100%)
>>
>> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw 
>> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
>> index 
>> 2c6ff655ded2a5855ca8f4428d559a7727eb6983..79b23c047bdc6e552d77d5c9e9aeae21ff04d91d
>>  100644 GIT binary patch delta 410
>> zcmZo+dBQ9-0SF8a=rRZ}FxWCMF#Invo+zYJ-&~=>PEYMB8#X*^*s
>> zI*-2o*Lifq#%B#L{TUe;3~zVd>wJ;c9c#dNqsaO-vqOwyxZ<^$|Sx+*`qBE-KP
>> zRw#MZ?IF_m@c;k+44fxR?lK-MVJf=bP$9%z%Jy2m^*||G=ZV*+3=ec3YyDQrw
>> zhLV39>OTT4_yTke(6spG0}_@eiX$2-m<39tfuvB0QMW|nV~~MBTOFDYFc(>?{CR!5
>> z`2b5=qlIr@Ka2ph)3jn)CK3=F06%+4CG<$;o!=g(0n4LMA4`}djk7m=n
>> z@tSo9&>Du9B|zggh&^lgwVUBX-))iIZU6Ps_!-61b|^D2IPfbSNPCqzIiFFU^R?Xs
>> zd4>r<#gi8>%0vL2z`!uOpJBgKz-zAkjsdS((>jm5W_tbeb@R)JfB*l#TmvLJAN+p?
>> a3S}hl`Z9zAvN|lpjbXxs*L#qpCjbB+6v6TU
>>
>> delta 442
>> zcmX9)O-lk%6n)b;mb6f61Fgs7G?G=i3EW`h#0jTXjjt=xN`<_@e*RfKhRH@
>> zRthehQp> z2#|b@Yi!yt8wAow*Da-71;Y*UMJdG%{oGQ>0fSK3#P_%@6n3VVmKY~2sF%gXydlkT
>> zz2J+}fsf;~_pRoa+J(fR`Ut;~>qat}3#muERkA!QyT~Xg^M>rg%^bM|McBYs`8V0A
>> zcP(O;ogKlFmCBIg5bqJ
>> zBhR=?>3OE6Mw4r>-vk>Al5t4>DR50tqp6HM5M^V1To7n?Y1=u`A{@A7c!=ymHGRlZ
>> zJ}anuVpcRdDYzN0P#%MY-J^!^vR_OvBRp9GvF1f*Ah$29X~lhJI8j|qcKWL;$
>> mb+{6FrzA&7=!a5r41gb~Ws5tejhbe+Ol`#xF!g`tAAbQ#M!vED
>>
>> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw 
>> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw
>> index 
>> 

Re: [edk2-devel] [PATCH v2 10/11] OvmfPkg: add SevHashesBlobVerifierLib

[Lendacky, Thomas via groups.io]

On 7/19/21 2:47 PM, Dov Murik wrote:
> On 19/07/2021 20:28, Tom Lendacky wrote:
>> On 7/6/21 3:55 AM, Dov Murik wrote:
> 
>>> +[Defines]
>>> +  INF_VERSION= 0x00010005
>>> +  BASE_NAME  = SevHashesBlobVerifierLib
> 
> But is this BASE_NAME okay?
> 
> Or should it be BlobVerifierLibSevHashes ?

I guess that it should probably be BlobVerifierLibSevHashes just for
consistency, but I'm not sure whether there's a convention for BASE_NAME.

Thanks,
Tom

> 
> 
>>> +  FILE_GUID  = 59e713b5-eff3-46a7-8d8b-46f4c004ad7b
>>> +  MODULE_TYPE= BASE
>>> +  VERSION_STRING = 1.0
>>> +  LIBRARY_CLASS  = BlobVerifierLib
>>> +  CONSTRUCTOR= SevHashesBlobVerifierLibConstructor
>>> +
>>> +[Sources]
>>> +  SevHashesBlobVerifier.c
>>> +
>>> +[Packages]
>>> +  CryptoPkg/CryptoPkg.dec
>>> +  MdePkg/MdePkg.dec
>>> +  OvmfPkg/OvmfPkg.dec
>>> +
>>> +[LibraryClasses]
>>> +  BaseCryptLib
>>> +  BaseMemoryLib
>>> +  DebugLib
>>> +  PcdLib
>>> +
>>> +[FixedPcd]
>>> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase
>>> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
>>> diff --git a/OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifier.c 
>>> b/OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifier.c
>>> new file mode 100644
>>> index ..961ee29f5df3
>>> --- /dev/null
>>> +++ b/OvmfPkg/Library/BlobVerifierLib/SevHashesBlobVerifier.c
>>> @@ -0,0 +1,199 @@
>>> +/** @file
>>> +
>>> +  Blob verifier library that uses SEV hashes table.
>>> +
>>> +  Copyright (C) 2021, IBM Corporation
>>> +
>>> +  SPDX-License-Identifier: BSD-2-Clause-Patent
>>> +**/
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +/**
>>> +  The SEV Hashes table must be in encrypted memory and has the table
>>> +  and its entries described by
>>> +
>>> +  |UINT16 |
>>> +
>>> +  With the whole table GUID being 9438d606-4f22-4cc9-b479-a793d411fd21
>>> +
>>> +  The current possible table entries are for the kernel, the initrd
>>> +  and the cmdline:
>>> +
>>> +  4de79437-abd2-427f-b835-d5b172d2045b  kernel
>>> +  44baf731-3a2f-4bd7-9af1-41e29169781d  initrd
>>> +  97d02dd8-bd20-4c94-aa78-e7714d36ab2a  cmdline
>>> +
>>> +  The size of the entry is used to identify the hash, but the
>>> +  expectation is that it will be 32 bytes of SHA-256.
>>> +**/
>>> +
>>> +#define SEV_HASH_TABLE_GUID \
>>> +  (GUID) { 0x9438d606, 0x4f22, 0x4cc9, { 0xb4, 0x79, 0xa7, 0x93, 0xd4, 
>>> 0x11, 0xfd, 0x21 } }
>>> +#define SEV_KERNEL_HASH_GUID \
>>> +  (GUID) { 0x4de79437, 0xabd2, 0x427f, { 0xb8, 0x35, 0xd5, 0xb1, 0x72, 
>>> 0xd2, 0x04, 0x5b } }
>>> +#define SEV_INITRD_HASH_GUID \
>>> +  (GUID) { 0x44baf731, 0x3a2f, 0x4bd7, { 0x9a, 0xf1, 0x41, 0xe2, 0x91, 
>>> 0x69, 0x78, 0x1d } }
>>> +#define SEV_CMDLINE_HASH_GUID \
>>> +  (GUID) { 0x97d02dd8, 0xbd20, 0x4c94, { 0xaa, 0x78, 0xe7, 0x71, 0x4d, 
>>> 0x36, 0xab, 0x2a } }
>>> +
>>> +STATIC CONST EFI_GUID mSevKernelHashGuid = SEV_KERNEL_HASH_GUID;
>>> +STATIC CONST EFI_GUID mSevInitrdHashGuid = SEV_INITRD_HASH_GUID;
>>> +STATIC CONST EFI_GUID mSevCmdlineHashGuid = SEV_CMDLINE_HASH_GUID;
>>> +
>>> +#pragma pack (1)
>>> +typedef struct {
>>> +  GUID   Guid;
>>> +  UINT16 Len;
>>> +  UINT8  Data[];
>>> +} HASH_TABLE;
>>> +#pragma pack ()
>>> +
>>> +STATIC HASH_TABLE *mHashesTable;
>>> +STATIC UINT16 mHashesTableSize;
>>> +
>>> +STATIC
>>> +CONST GUID*
>>> +FindBlobEntryGuid (
>>> +  IN  CONST CHAR16*BlobName
>>> +  )
>>> +{
>>> +  if (StrCmp (BlobName, L"kernel") == 0) {
>>> +return 
>>> +  } else if (StrCmp (BlobName, L"initrd") == 0) {
>>> +return 
>>> +  } else if (StrCmp (BlobName, L"cmdline") == 0) {
>>> +return 
>>> +  } else {
>>> +return NULL;
>>> +  }
>>> +}
>>> +
>>> +/**
>>> +  Verify blob from an external source.
>>> +
>>> +  @param BlobName   The name of the blob
>>> +  @param BufThe data of the blob
>>> +  @param BufSizeThe size of the blob in bytes
>>> +
>>> +  @retval EFI_SUCCESS   The blob was verified successfully.
>>> +  @retval EFI_ACCESS_DENIED The blob could not be verified, and 
>>> therefore
>>> +should be considered non-secure.
>>> +**/
>>> +EFI_STATUS
>>> +EFIAPI
>>> +VerifyBlob (
>>> +  IN  CONST CHAR16*BlobName,
>>> +  IN  CONST VOID  *Buf,
>>> +  UINT32  BufSize
>>> +  )
>>> +{
>>> +  CONST GUID *Guid;
>>> +  INT32 Len;
>>
>> Any reason for this not to be a UINT16 like the struct or mHashesTableSize?
>>
> 
> Detect overflows in the `for` loop below?
> 
> If a (bad) Entry->Len is 0x, then adding it to Len will overflow the
> UINT16 and the Len < mHashesTableSize condition is still true.
> 
> 
>>> +  HASH_TABLE *Entry;
>>> +  UINT8 Hash[SHA256_DIGEST_SIZE];
>>> +
>>> +  if (mHashesTable == NULL || mHashesTableSize == 0) {
>>> +DEBUG ((DEBUG_ERROR,
>>> +  "%a: Verifier called but no hashes table discoverd in 

Re: [edk2-devel] [PATCH V2 4/4] OvmfPkg/ResetVector: Update ResetVector to support Tdx

[Lendacky, Thomas via groups.io]

On 7/22/21 12:52 AM, Min Xu wrote:
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> In Tdx all CPUs "reset" to run on 32-bit protected mode with flat
> descriptor (paging disabled). But in Non-Td guest the initial state of
> CPUs is 16-bit real mode. To resolve this conflict, BITS 16/32 is used
> in the very beginning of ResetVector. It will check the 32-bit protected
> mode or 16-bit real mode, then jump to the corresponding entry point.
> This is done in OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm.
> 
> ReloadFlat32.asm load the GDT and set the CR0, then jump to Flat-32 mode.
> 
> InitTdx.asm is called to record the Tdx signature ('TDXG') and other tdx
> information in a TDX_WORK_AREA which can be used by the other routines in
> ResetVector.
> 
> Init32.asm is 32-bit initialization code in OvmfPkg. It puts above
> ReloadFlat32 and InitTdx together to do the initializaiton for Tdx.
> 
> After that Tdx jumps to 64-bit long mode by doing following tasks:
> 1. SetCr3ForPageTables64
>For OVMF, some initial page tables is built at:
>  PcdOvmfSecPageTablesBase - (PcdOvmfSecPageTablesBase + 0x6000)
>This page table supports the 4-level page table.
>But Tdx support 4-level and 5-level page table based on the CPU GPA width.
>48bit is 4-level paging, 52-bit is 5-level paging.
>If 5-level page table is supported (GPAW is 52), then a top level
>page directory pointers (1 * 256TB entry) is generated in the
>TdxPageTable.
> 2. Set Cr4
>Enable PAE.
> 3. Adjust Cr3
>If GPAW is 48, then Cr3 is PT_ADDR (0). If GPAW is 52, then Cr3 is
>TDX_PT_ADDR (0).
> 
> Tdx MailBox [0x10, 0x800] is reserved for OS. So we initialize piece of this
> area ([0x10, 0x20]) to record the Tdx flag ('TDXG') and other Tdx info so that
> they can be used in the following flow.
> 
> After all above is successfully done, Tdx jump to SecEntry.
> 
> Cc: Ard Biesheuvel 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Signed-off-by: Min Xu 
> ---
>  OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 21 
>  OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm  | 47 
>  OvmfPkg/ResetVector/Ia32/Init32.asm  | 34 
>  OvmfPkg/ResetVector/Ia32/InitTdx.asm | 57 
>  OvmfPkg/ResetVector/Ia32/PageTables64.asm| 41 ++
>  OvmfPkg/ResetVector/Ia32/ReloadFlat32.asm| 44 +++
>  OvmfPkg/ResetVector/ResetVector.nasmb| 18 +++
>  7 files changed, 262 insertions(+)
>  create mode 100644 OvmfPkg/ResetVector/Ia32/Init32.asm
>  create mode 100644 OvmfPkg/ResetVector/Ia32/InitTdx.asm
>  create mode 100644 OvmfPkg/ResetVector/Ia32/ReloadFlat32.asm
> 
> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm 
> b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> index ac86ce69ebe8..a390ed81d021 100644
> --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> @@ -155,10 +155,31 @@ resetVector:
>  ;
>  ; This is where the processor will begin execution
>  ;
> +; In IA32 we follow the standard reset vector flow. While in X64, Td guest
> +; may be supported. Td guest requires the startup mode to be 32-bit
> +; protected mode but the legacy VM startup mode is 16-bit real mode.
> +; To make NASM generate such shared entry code that behaves correctly in
> +; both 16-bit and 32-bit mode, more BITS directives are added.
> +;
> +%ifdef ARCH_IA32
> +
>  nop
>  nop
>  jmp EarlyBspInitReal16
>  
> +%else
> +
> +smswax
> +testal, 1
> +jz  .Real
> +BITS 32
> +jmp Main32
> +BITS 16
> +.Real:
> +jmp EarlyBspInitReal16
> +
> +%endif
> +
>  ALIGN   16
>  
>  fourGigabytes:
> diff --git a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm 
> b/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> index c6d0d898bcd1..2206ca719593 100644
> --- a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> +++ b/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> @@ -17,6 +17,9 @@ Transition32FlatTo64Flat:
>  
>  OneTimeCall SetCr3ForPageTables64
>  
> +cmp dword[TDX_WORK_AREA], 0x47584454 ; 'TDXG'
> +jz  TdxTransition32FlatTo64Flat
> +

Is the memory area guaranteed to be zeroed for legacy guests? Hopefully,
this won't trip up a non-TDX guest with a false match (highly unlikely,
though).

>  mov eax, cr4
>  bts eax, 5  ; enable PAE
>  mov cr4, eax
> @@ -65,10 +68,54 @@ EnablePaging:
>  bts eax, 31 ; set PG
>  mov cr0, eax; enable paging
>  
> +jmp _jumpTo64Bit
> +
> +;
> +; Tdx Transition from 32Flat to 64Flat
> +;
> +TdxTransition32FlatTo64Flat:
> +
> +mov eax, cr4
> +bts eax, 5  ; enable PAE
> +
> +;
> +; byte[TDX_WORK_AREA_PAGELEVEL5] holds the indicator whether 52bit is 
> supported.
> +; if it is the case, need to set LA57 and use 5-level 

Re: [edk2-devel] [PATCH v5 2/4] OvmfPkg/VmgExitLib: Add support for hypercalls with SEV-ES.

[Lendacky, Thomas via groups.io]

On 7/8/21 9:08 AM, Ashish Kalra wrote:
> From: Ashish Kalra 
> 

The subject isn't correct since the #VC handler already supports
hypercalls. It should say something like "Make the #VC handler aware of
the encryption state change hypercall" or "Update the #VC handler to
support the encryption state change hypercall" or something like that.

> Make the VC handler hypercall aware by adding support
> to compare the hypercall number and add the additional
> register values used by hypercall in the GHCB.
> 
> Also mark the SEC GHCB page (that is mapped as
> unencrypted in ResetVector code) in the hypervisor
> guest page status tracking.

This part of the commit message shoudn't be here any more.

> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Ashish Kalra 
> ---
>  OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
> b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
> index 41b0c8cc53..7f69bfab5f 100644
> --- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
> +++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
> @@ -1171,6 +1171,15 @@ VmmCallExit (
>Ghcb->SaveArea.Cpl = (UINT8) (Regs->Cs & 0x3);
>VmgSetOffsetValid (Ghcb, GhcbCpl);
>  

Add a comment that this hypercall requires these extra registers so you
are explicitly adding them.

Thanks,
Tom

> +  if (Regs->Rax == KVM_HC_MAP_GPA_RANGE) {
> +Ghcb->SaveArea.Rbx = Regs->Rbx;
> +VmgSetOffsetValid (Ghcb, GhcbRbx);
> +Ghcb->SaveArea.Rcx = Regs->Rcx;
> +VmgSetOffsetValid (Ghcb, GhcbRcx);
> +Ghcb->SaveArea.Rdx = Regs->Rdx;
> +VmgSetOffsetValid (Ghcb, GhcbRdx);
> +  }
> +
>Status = VmgExit (Ghcb, SVM_EXIT_VMMCALL, 0, 0);
>if (Status != 0) {
>  return Status;
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77829): https://edk2.groups.io/g/devel/message/77829
Mute This Topic: https://groups.io/mt/84068349/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 3/4] OvmfPkg/PlatformPei: Mark SEC GHCB page as unencrypted via hypercall

[Lendacky, Thomas via groups.io]

On 7/8/21 9:08 AM, Ashish Kalra wrote:
> From: Ashish Kalra 
> 
> Mark the SEC GHCB page (that is mapped as unencrypted in
> ResetVector code) in the hypervisor page status tracking.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Ashish Kalra 
> ---
>  OvmfPkg/PlatformPei/AmdSev.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
> index a8bf610022..1ec0de48fe 100644
> --- a/OvmfPkg/PlatformPei/AmdSev.c
> +++ b/OvmfPkg/PlatformPei/AmdSev.c
> @@ -52,6 +52,15 @@ AmdSevEsInitialize (
>PcdStatus = PcdSetBoolS (PcdSevEsIsEnabled, TRUE);
>ASSERT_RETURN_ERROR (PcdStatus);
>  
> +  //
> +  // GHCB_BASE setup during reset-vector needs to be marked as

s/GHCB_BASE/The SEC Ghcb/

> +  // decrypted in the hypervisor page encryption bitmap.

Is the "hypervisor page encryption bitmap" valid anymore? This gets passed
up to userspace now, right?

You should go through all the patches to be sure you aren't talking about
a bitmap anymore and just state that you're updating the encryption state
with the hypervisor.

> +  //
> +  SetMemoryEncDecHypercall3 (FixedPcdGet32 (PcdOvmfSecGhcbBase),

The first argument needs to be moved down to a line of its own and
indented like the following arguments.

> +EFI_SIZE_TO_PAGES(FixedPcdGet32 (PcdOvmfSecGhcbSize)),
> +KVM_MAP_GPA_RANGE_DECRYPTED

Ah, now I see this #define used, but you should be passing a 0 or 1,
right? This happens to evaluate to 0, but it's the wrong way to call this
function.

Thanks,
Tom

> +);
> +
>//
>// Allocate GHCB and per-CPU variable pages.
>//   Since the pages must survive across the UEFI to OS transition
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77830): https://edk2.groups.io/g/devel/message/77830
Mute This Topic: https://groups.io/mt/84068365/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v5 1/4] OvmfPkg/BaseMemEncryptLib: Support to issue unencrypted hypercall

[Lendacky, Thomas via groups.io]

On 7/8/21 9:07 AM, Ashish Kalra wrote:
> From: Ashish Kalra 
> 

The patch subject is a bit confusing. Something more like "Add API to
issue hypercall on page encryption state change" or similar, since this is
issued for changes to shared and private, not just shared.

> By default all the SEV guest memory regions are considered encrypted,
> if a guest changes the encryption attribute of the page (e.g mark a
> page as decrypted) then notify hypervisor. Hypervisor will need to
> track the unencrypted pages. The information will be used during
> guest live migration, guest page migration and guest debugging.
> 
> This hypercall is used to notify hypervisor when the page's
> encryption state changes.

This is a large patch. It looks like this should be split into a few patches.
- one patch for the MemEncryptSevLiveMigrationIsEnabled() API
- one patch for the SetMemoryEncDecHypercall3() API
- one patch to make use of the SetMemoryEncDecHypercall3() API.

> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Brijesh Singh 
> Signed-off-by: Ashish Kalra 
> ---
>  OvmfPkg/Include/Library/MemEncryptSevLib.h| 69 
> 
>  OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf  |  1 +
>  OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c| 39 
> +++
>  OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c  | 27 
> 
>  OvmfPkg/Library/BaseMemEncryptSevLib/PeiDxeMemEncryptSevLibInternal.c | 51 
> +++
>  OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLib.inf  |  1 +
>  OvmfPkg/Library/BaseMemEncryptSevLib/PeiMemEncryptSevLibInternal.c| 39 
> +++
>  OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLibInternal.c| 38 
> +++
>  OvmfPkg/Library/BaseMemEncryptSevLib/X64/AsmHelperStub.nasm   | 33 
> ++
>  OvmfPkg/Library/BaseMemEncryptSevLib/X64/MemEncryptSevLib.c   | 54 
> +++
>  OvmfPkg/Library/BaseMemEncryptSevLib/X64/PeiDxeVirtualMemory.c| 22 
> ++-
>  11 files changed, 373 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h 
> b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> index 76d06c206c..c2b2a99a08 100644
> --- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
> +++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
> @@ -90,6 +90,18 @@ MemEncryptSevIsEnabled (
>VOID
>);
>  
> +/**
> +  Returns a boolean to indicate whether SEV live migration is enabled.
> +
> +  @retval TRUE   SEV live migration is enabled
> +  @retval FALSE  SEV live migration is not enabled
> +**/
> +BOOLEAN
> +EFIAPI
> +MemEncryptSevLiveMigrationIsEnabled (
> +  VOID
> +  );
> +
>  /**
>This function clears memory encryption bit for the memory region specified 
> by
>BaseAddress and NumPages from the current page table context.
> @@ -222,4 +234,61 @@ MemEncryptSevClearMmioPageEncMask (
>IN UINTNNumPages
>);
>  
> +/**
> + This hypercall is used to notify hypervisor when the page's encryption
> + state changes.
> +
> + @param[in]   PhysicalAddress   The physical address that is the start 
> address
> +of a memory region. The PhysicalAddress 
> is
> +expected to be PAGE_SIZE aligned.
> + @param[in]   Pages Number of pages in memory region.
> + @param[in]   StatusEncrypted(1) or Decrypted(0).
> +
> +@retval RETURN_SUCCESS  Hypercall returned success.

It looks like RETURN_UNSUPPORTED is also possible.

> +**/
> +RETURN_STATUS
> +EFIAPI
> +SetMemoryEncDecHypercall3 (
> +  IN  UINTN PhysicalAddress,
> +  IN  UINTN Pages,
> +  IN  UINTN Status
> +  );
> +
> +#define KVM_HC_MAP_GPA_RANGE   12
> +#define KVM_MAP_GPA_RANGE_PAGE_SZ_4K0
> +#define KVM_MAP_GPA_RANGE_PAGE_SZ_2MBIT0
> +#define KVM_MAP_GPA_RANGE_PAGE_SZ_1GBIT1
> +#define KVM_MAP_GPA_RANGE_ENC_STAT(n)   ((n) << 4)
> +#define KVM_MAP_GPA_RANGE_ENCRYPTED KVM_MAP_GPA_RANGE_ENC_STAT(1)
> +#define KVM_MAP_GPA_RANGE_DECRYPTED KVM_MAP_GPA_RANGE_ENC_STAT(0)

You define these but don't use them (and you should).

> +
> +#define KVM_FEATURE_MIGRATION_CONTROL   BIT17
> +
> +/**
> +  Figures out if we are running inside KVM HVM and
> +  KVM HVM supports SEV Live Migration feature.
> +
> +  @retval TRUE   SEV live migration is supported.
> +  @retval FALSE  SEV live migration is not supported.
> +**/
> +BOOLEAN
> +EFIAPI
> +KvmDetectSevLiveMigrationFeature(
> +  VOID
> +  );
> +
> +/**
> +  Interface exposed by the ASM implementation of the core hypercall
> +
> +  @retval Hypercall returned status.
> +**/
> +UINTN
> +EFIAPI
> +SetMemoryEncDecHypercall3AsmStub (
> +  IN  UINTN  HypercallNum,
> +  IN  UINTN  PhysicalAddress,
> +  IN  UINTN  Pages,
> +  IN  UINTN  Attributes
> +  );
> +
>  #endif // _MEM_ENCRYPT_SEV_LIB_H_
> 

Re: [edk2-devel] [PATCH V2 4/4] OvmfPkg/ResetVector: Update ResetVector to support Tdx

[Lendacky, Thomas via groups.io]

On 7/22/21 5:58 PM, Xu, Min M wrote:
> On July 23, 2021 1:08 AM, Tom Lendacky wrote:
>> On 7/22/21 12:52 AM, Min Xu wrote:
>>> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
>>>
>>> diff --git a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
>>> b/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
>>> index c6d0d898bcd1..2206ca719593 100644
>>> --- a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
>>> +++ b/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
>>> @@ -17,6 +17,9 @@ Transition32FlatTo64Flat:
>>>
>>>  OneTimeCall SetCr3ForPageTables64
>>>
>>> +cmp dword[TDX_WORK_AREA], 0x47584454 ; 'TDXG'
>>> +jz  TdxTransition32FlatTo64Flat
>>> +
>>
>> Is the memory area guaranteed to be zeroed for legacy guests? Hopefully,
>> this won't trip up a non-TDX guest with a false match (highly unlikely, 
>> though).
>>
> TDX_WORK_AREA is piece of TdxMailbox which is located in the MEMFD started
> from PcdOvmfSecGhcbBackupBase. In Td guest, this memory region is initialized
> to all-0 by host VMM. In legacy guests, I am not sure what's the initialized 
> value
> it is. So 'TDXG' is checked to guarantee it is Td-guest or not. 
> Since Tdx re-use the memory region (PcdOvmfSecGhcbBackupBase) as the
> TDX_WORK_AREA, and @Tom Lendacky you should be the original owner of
> PcdOvmfSecGhcbBackupBase, can this area be cleared in the beginning of
> ResetVector in legacy guests? Or I should better create a TDX specific work
> area in MEMFD to guarantee the Td And Non-Td check?

I believe PcdOvmfSecGhcbBackupBase can be cleared early. For SEV-ES, it
isn't shared with the hypervisor, so clearing it before activating the
pagetables can be done (it will be treated as encrypted before paging is
enabled and mapped as encrypted after paging is enabled) and for a legacy
guest the mapping doesn't matter. It isn't required to be cleared today,
so if you do add something, be sure to put a comment in there about why
it's being done. No need for a new area.

The possibility of random data being there that matches 'TDXG' is
extremely low. But better safe than sorry, I guess.

Thanks,
Tom

>>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78131): https://edk2.groups.io/g/devel/message/78131
Mute This Topic: https://groups.io/mt/84373830/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/3] OvmfPkg/ResetVector: move SEV specific code in a separate file

[Lendacky, Thomas via groups.io]

On 7/27/21 6:16 AM, Brijesh Singh wrote:
> 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 
> Cc: Min Xu 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 
> Cc: Erdem Aktas 
> Suggested-by: Laszlo Ersek 
> Signed-off-by: Brijesh Singh 
> ---
>  .../Ia32/{PageTables64.asm => AmdSev.asm} | 140 ---
>  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 391 --
>  OvmfPkg/ResetVector/ResetVector.nasmb |   1 +
>  3 files changed, 1 insertion(+), 531 deletions(-)
>  copy OvmfPkg/ResetVector/Ia32/{PageTables64.asm => AmdSev.asm} (71%)
> 
> diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
> b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
> similarity index 71%
> copy from OvmfPkg/ResetVector/Ia32/PageTables64.asm
> copy to OvmfPkg/ResetVector/Ia32/AmdSev.asm
> index 5fae8986d9da..b32dd3b5d656 100644
> --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
> +++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
> @@ -10,33 +10,6 @@
>  

My only comment is the AmdSev.asm file header should be updated. The file
function needs to be changed and there should only be a single copyright
statement for AMD from 2017 to now 2021.

Thanks,
Tom


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78224): https://edk2.groups.io/g/devel/message/78224
Mute This Topic: https://groups.io/mt/84479271/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg/ResetVector: Removing SEV-ES CPUID bit check

[Lendacky, Thomas via groups.io]

On 1/10/22 9:29 AM, Peter Gonda wrote:

On Fri, Jan 7, 2022 at 3:54 PM Tom Lendacky  wrote:


On 1/7/22 11:04 AM, Peter Gonda wrote:

The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to
determine support for running SEV-ES guests. It should not be checked by
a guest to determine if it is running under SEV-ES. The guest should use
the SEV_STATUS MSR Bit 1 to determine if SEV-ES is enabled.


Worth mentioning in the commit message that this check wasn't part of the
original SEV-ES support (Fixes: a91b700e385e7484ab7286b3ba7ea2efbd59480e
tag?), so this is really a compatibility thing, and that this makes the
check consistent with the Linux kernel.


Sure I update the commit message in the V2 with this info and add the
Fixes tag. Do I need a (Fixes:
b461d67639f2deced77e9bb967d014b7cfcd75f8) tag too? Since the Check was
moved between files in that commit?


I don't think so, but that's just my opinion.

Thanks,
Tom






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85494): https://edk2.groups.io/g/devel/message/85494
Mute This Topic: https://groups.io/mt/88273346/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Build failure

[Lendacky, Thomas via groups.io]

Is there a new minimum version of NASM required for the build? The
following commit causes the build to fail on my Ubuntu 20.04 system:

d3febfd9ade3 ("MdePkg: Replace Opcode with the corresponding instructions.")

Specifically the opcode changes in LongJump.nasm:

/root/kernels/ovmf-build-X64/Build/OvmfX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/LongJump.iii:44:
 error: parser: instruction expected
/root/kernels/ovmf-build-X64/Build/OvmfX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/LongJump.iii:49:
 error: parser: instruction expected
make: *** [GNUmakefile:742: 
/root/kernels/ovmf-build-X64/Build/OvmfX64/DEBUG_GCC5/X64/MdePkg/Library/BaseLib/BaseLib/OUTPUT/X64/LongJump.obj]
 Error 1

The most recent NASM version available on Ubuntu 20.04 is:

# nasm -v
NASM version 2.14.02

Thanks,
Tom


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#87359): https://edk2.groups.io/g/devel/message/87359
Mute This Topic: https://groups.io/mt/89637409/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Another regression with SEV resulting in VM reset loop

[Lendacky, Thomas via groups.io]

On 2/16/22 12:06, Aaron Young via groups.io wrote:

We have encountered another regression related to SEV support resulting in a 
reset loop with Intel/Win2012R2 guests.

  NOTE that I reported this several months ago here (which contains more 
details):

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

  I have reconfirmed that this issue still exists with latest upstream (commit 
c9b7c6e0cc7da76b74bcdd8c90cef956d5ae971c).

  I was asked to raise this issue here on the edk2 mail list as well.


In the future, please consider copying the reviewers associated with this 
area on any mailing list postings or bugzillas, so that we may see this 
sooner. I just happened to notice this in the mailing list, but could have 
easily overlooked it.


Brijesh is working on some cleanup patches, one of which addresses this 
issue (https://www.mail-archive.com/devel@edk2.groups.io/msg41595.html). 
He has encountered an issue with this series that he is working through, 
but that series will fix this issue.


Thanks,
Tom



  Thanks,

  -Aaron Young
  aaron.yo...@oracle.com
  








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86711): https://edk2.groups.io/g/devel/message/86711
Mute This Topic: https://groups.io/mt/89191392/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] OvmfPkg VmgExitLib fails to build with CLANG38 (clang 13.0.0)

[Lendacky, Thomas via groups.io]

On 2/2/22 14:54, Rebecca Cran wrote:

VmgExitLib fails to build with the CLANG38 toolset (clang 13.0.0):


edk2/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c:1875:9: error: variable 
'Compacted' is used uninitialized whenever 'if' condition is false [-Werror,-W

sometimes-uninitialized]
    if (EcxIn == 1) {
    ^~
edk2/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c:1895:12: note: 
uninitialized use occurs here

   Compacted
   ^
edk2/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c:1875:5: note: remove 
the 'if' if its condition is always true

    if (EcxIn == 1) {
    ^~~~
edk2/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c:1871:37: note: 
initialize the variable 'Compacted' to silence this warning

    BOOLEAN    Compacted;
    ^
 = '\0'


This looks like the same error that XCODE5 was complaining about. The 
patch was submitted by Brijesh, but some CI failure occurred. I'm not sure 
how that is possible from a one line patch like that, maybe it has 
something to do with the file in general, excluding the patch?


Thanks,
Tom



--
Rebecca Cran




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86346): https://edk2.groups.io/g/devel/message/86346
Mute This Topic: https://groups.io/mt/88869092/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg/ResetVector: Removing SEV-ES CPUID bit check

[Lendacky, Thomas via groups.io]

On 1/7/22 11:04 AM, Peter Gonda wrote:

The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to
determine support for running SEV-ES guests. It should not be checked by
a guest to determine if it is running under SEV-ES. The guest should use
the SEV_STATUS MSR Bit 1 to determine if SEV-ES is enabled.


Worth mentioning in the commit message that this check wasn't part of the 
original SEV-ES support (Fixes: a91b700e385e7484ab7286b3ba7ea2efbd59480e 
tag?), so this is really a compatibility thing, and that this makes the 
check consistent with the Linux kernel.


Thanks,
Tom



Cc: James Bottomley 
Cc: Min Xu 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
Cc: Erdem Aktas 
Cc: Marc Orr 
Cc: Brijesh Singh 
Cc: Jim Mattson 
Signed-off-by: Peter Gonda 
---
  OvmfPkg/ResetVector/Ia32/AmdSev.asm | 8 
  1 file changed, 8 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
index 1f827da3b9..77692db27e 100644
--- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -265,14 +265,6 @@ CheckSevFeatures:
  ; Set the work area header to indicate that the SEV is enabled
  mov byte[WORK_AREA_GUEST_TYPE], 1
  
-; 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, 0x801f
-cpuid
-bteax, 3
-jnc   GetSevEncBit
-
  ; Check if SEV-ES is enabled
  ;  MSR_0xC0010131 - Bit 1 (SEV-ES enabled)
  mov   ecx, SEV_STATUS_MSR




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85334): https://edk2.groups.io/g/devel/message/85334
Mute This Topic: https://groups.io/mt/88273346/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] OvmfPkg/ResetVector: Removing SEV-ES CPUID bit check

[Lendacky, Thomas via groups.io]

On 1/13/22 10:30 AM, Peter Gonda wrote:

The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to
determine support for running SEV-ES guests. It should not be checked by
a guest to determine if it is running under SEV-ES. The guest should use
the SEV_STATUS MSR Bit 1 to determine if SEV-ES is enabled. This check
was not part of the original SEV-ES support and was added in
a91b700e38. Removing the check makes this code consistent with the
Linux kernel

Fixes: a91b700e38 (Ovmf/ResetVector: Simplify and consolidate the SEV features 
checks)
Cc: James Bottomley 
Cc: Min Xu 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
Cc: Erdem Aktas 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Marc Orr 
Signed-off-by: Peter Gonda 


Acked-by: Tom Lendacky 


---
  OvmfPkg/ResetVector/Ia32/AmdSev.asm | 8 
  1 file changed, 8 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
index 1f827da3b9..77692db27e 100644
--- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -265,14 +265,6 @@ CheckSevFeatures:
  ; Set the work area header to indicate that the SEV is enabled
  mov byte[WORK_AREA_GUEST_TYPE], 1
  
-; 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, 0x801f
-cpuid
-bteax, 3
-jnc   GetSevEncBit
-
  ; Check if SEV-ES is enabled
  ;  MSR_0xC0010131 - Bit 1 (SEV-ES enabled)
  mov   ecx, SEV_STATUS_MSR




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85824): https://edk2.groups.io/g/devel/message/85824
Mute This Topic: https://groups.io/mt/88400388/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] TDX patches have broken edk2 bisectability in OVMF

[Lendacky, Thomas via groups.io]

On 4/12/22 16:00, James Bottomley via groups.io wrote:

I've identified a serious performance regression in recent edk2, so
I've been trying to identify it by bisection, but it seems that the TDX
patches have broken bisection in edk2.  You can see this by trying to
checkout b6b2de884864 and build it.  It will give you

Active Platform  = /home/jejb/git/edk2/OvmfPkg/OvmfPkgX64.dsc
.

build.py...
/home/jejb/git/edk2/OvmfPkg/OvmfPkgX64.dsc(...): error 4000: Instance of 
library class [TdxLib] is not found
in 
[/home/jejb/git/edk2/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf]
 [X64]
consumed by module [/home/jejb/git/edk2/OvmfPkg/Sec/SecMain.inf]
  


I think I can work around this, but it makes bisection extremely
painful, please don't do it again ...


+1 for this as I'm trying to bisect an SEV-ES breakage on latest tree.

Thanks,
Tom



James










-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88948): https://edk2.groups.io/g/devel/message/88948
Mute This Topic: https://groups.io/mt/90427519/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V12 42/47] OvmfPkg: Add TdxDxe driver

[Lendacky, Thomas via groups.io]

On 3/29/22 18:46, Min Xu wrote:

RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429

TdxDxe driver is dispatched early in DXE, due to being list in APRIORI.
This module is responsible for below features:
  - Sets max logical cpus based on TDINFO
  - Sets PCI PCDs based on resource hobs
  - Set shared bit in MMIO region
  - Relocate Td mailbox and set its address in MADT table.

1. Set shared bit in MMIO region

Qemu allows a ROM device to set to ROMD mode (default) or MMIO mode.
When it is in ROMD mode, the device is mapped to guest memory and
satisfies read access directly.

In EDK2 Option ROM is treated as MMIO region. So Tdx guest access
Option ROM via TDVMCALL(MMIO). But as explained above, since Qemu set
the Option ROM to ROMD mode, the call of TDVMCALL(MMIO) always return
INVALID_OPERAND. Tdvf then falls back to direct access. This requires
to set the shared bit to corresponding PageTable entry. Otherwise it
triggers GP fault.

TdxDxe's entry point is the right place to set the shared bit in MMIO
region because Option ROM has not been discoverd yet.

2. Relocate Td mailbox and set the new address in MADT Mutiprocessor
Wakeup Table.

In TDX the guest firmware is designed to publish a multiprocessor-wakeup
structure to let the guest-bootstrap processor wake up guest-application
processors with a mailbox. The mailbox is memory that the guest firmware
can reserve so each guest virtual processor can have the guest OS send
a message to them. The address of the mailbox is recorded in the MADT
table. See [ACPI].

TdxDxe registers for protocol notification
(gQemuAcpiTableNotifyProtocolGuid) to call the AlterAcpiTable(), in
which MADT table is altered by the above Mailbox address. The protocol
will be installed in AcpiPlatformDxe when the MADT table provided by
Qemu is ready. This is to maintain the simplicity of the AcpiPlatformDxe.

AlterAcpiTable is the registered function which traverses the ACPI
table list to find the original MADT from Qemu. After the new MADT is
configured and installed, the original one will be uninstalled.

[ACPI] https://uefi.org/specs/ACPI/6.4/05_ACPI_Software_Programming_Model
/ACPI_Software_Programming_Model.html#multiprocessor-wakeup-structure

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
Signed-off-by: Min Xu 


Unfortunately, this driver also breaks SEV-ES. I bypassed the TDX code in
the SEC library, but then hit an issue because this driver is loaded
before the AmdSevDxe driver. The AmdSevDxe driver performs a
MemEncryptSevClearMmioPageEncMask() call against the
PcdPciExpressBaseAddress range to mark it shared/unencrypted. However,
the TdxDxe driver is loaded before the AmdSevDxe driver, and it appears
the dependencies result in an MMIO being performed to an address in the
PcdPciExpressBaseAddress range. Since the range has not been marked
shared/unencrypted, the #VC handler terminates the guest for trying to do
MMIO to an encrypted region.

Here is the error information:

Loading driver at 0x0003F1A5000 EntryPoint=0x0003F1A6BF2 TdxDxe.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 3F1AFA98
ProtectUefiImageCommon - 0x3F1AFB40
  - 0x3F1A5000 - 0x4300
MMIO using encrypted memory: B00F8040
 X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID -  

ExceptionData - 
RIP  - 3F1A6E86, CS  - 0018, RFLAGS - 00010002
RAX  - B000, RCX - 3F4EAD18, RDX - 3F4EAD01
RBX  - 0001, RSP - 3FBA5B60, RBP - 
RSI  - , RDI - 3F1AFB18
R8   - B00F8040, R9  - 29C0, R10 - 
R11  - , R12 - , R13 - 
R14  - 3FBCC6D0, R15 - 3FBC43E6
DS   - 0008, ES  - 0008, FS  - 0008
GS   - 0008, SS  - 0008
CR0  - 80010033, CR2 - , CR3 - 3F801000
CR4  - 0668, CR8 - 
DR0  - , DR1 - , DR2 - 
DR3  - , DR6 - , DR7 - 
GDTR - 3FBFE000 0027, LDTR - 
IDTR - 3BF95D70 021F,   TR - 
FXSAVE_STATE - 3FBA57C0
 Find image based on IP(0x3F1A6E86) 
/root/kernels/ovmf-build-X64/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/TdxDxe/TdxDxe/DEBUG/TdxDxe.dll
 (ImageBase=3F1A5000, EntryPoint=3F1A6BF2) 

Not sure what the best way forward is on this.

Thanks,
Tom


---



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88954): https://edk2.groups.io/g/devel/message/88954
Mute This Topic: https://groups.io/mt/90495224/21656
Group Owner: devel+ow...@edk2.groups.io

Re: [edk2-devel] [PATCH V12 33/47] OvmfPkg: Update Sec to support Tdx

[Lendacky, Thomas via groups.io]

On 3/29/22 18:46, Min Xu wrote:

RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429

There are below major changes in this commit.

1. SecEntry.nasm
In TDX BSP and APs goes to the same entry point in SecEntry.nasm.

BSP initialize the temporary stack and then jumps to SecMain, just as
legacy Ovmf does.

APs spin in a modified mailbox loop using initial mailbox structure.
Its structure defition is in OvmfPkg/Include/IndustryStandard/IntelTdx.h.
APs wait for command to see if the command is for me. If so execute the
command.

2. Sec/SecMain.c
When host VMM create the Td guest, the system memory informations are
stored in TdHob, which is a memory region described in Tdx metadata.
The system memory region in TdHob should be accepted before it can be
accessed. So the major task of this patch is to process the TdHobList
to accept the memory. After that TDVF follow the standard OVMF flow
and jump to PEI phase.

PcdUse1GPageTable is set to FALSE by default in OvmfPkgX64.dsc. It gives
no chance for Intel TDX to support 1G page table. To support 1G page
table this PCD is set to TRUE in OvmfPkgX64.dsc.

TDX_GUEST_SUPPORTED is defined in OvmfPkgX64.dsc. This macro wraps the
Tdx specific code.

TDX only works on X64, so the code is only valid in X64 arch.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
Signed-off-by: Min Xu 



diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index 02520e25ab9a..ca9717a7b526 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -26,9 +26,8 @@
  #include 
  #include 
  #include 
-
  #include 
-
+#include 
  #include "AmdSev.h"
  
  #define SEC_IDT_ENTRY_COUNT  34

@@ -738,6 +737,20 @@ SecCoreStartupWithStack (
UINT32Index;
volatile UINT8*Table;
  
+ #if defined (TDX_GUEST_SUPPORTED)

+  if (TdIsEnabled ()) {


I wish I had caught this earlier, but this patch breaks SEV-ES support. 
TdIsEnabled() uses the CPUID instruction. At this point, exception 
handling is not established and a CPUID instruction will generate a #VC 
and cause the booting guest to crash.


That is why the SevEsIsEnabled() function checks the work area to 
determine if SEV-ES is supported. In the early boot code we established a 
temporary #VC handler to specifically handle CPUID and then set the work 
area indicator that SEV-ES is enabled.


I think you'll need to do something similar for this area. Haven't you 
already set the workarea from calling InitTdx before this point?


Thanks,
Tom


+//
+// For Td guests, the memory map info is in TdHobLib. It should be 
processed
+// first so that the memory is accepted. Otherwise access to the unaccepted
+// memory will trigger tripple fault.
+//
+if (ProcessTdxHobList () != EFI_SUCCESS) {
+  CpuDeadLoop ();
+}
+  }
+
+ #endif
+



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88953): https://edk2.groups.io/g/devel/message/88953
Mute This Topic: https://groups.io/mt/90121245/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf

[Lendacky, Thomas via groups.io]

On 11/6/23 16:45, Lendacky, Thomas via groups.io wrote:

The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a subleaf as input when
returning CPUID information. However, the AsmCpuid() function does not
zero out ECX before the CPUID instruction, so the input leaf is used as
the sub-leaf for the CPUID request and returns erroneous/invalid CPUID
data, since the intent of the request was to get data related to sub-leaf
0. Instead, use AsmCpuidEx() for the CPUID_EXTENDED_TOPOLOGY leaf.


Alternatively, the AsmCpuid() function could be changed to XOR ECX before 
invoking the CPUID instruction. This would ensure that the 0 sub-leaf is 
returned for any CPUID leaves that support sub-leaves. Thoughts?


Adding some additional maintainers for their thoughts, too.

Thanks,
Tom



Fixes: d4d7c9ad5fe5 ("UefiCpuPkg/MpInitLib: use BSP to do extended ...")
Signed-off-by: Tom Lendacky 
---
  UefiCpuPkg/Library/MpInitLib/AmdSev.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/AmdSev.c 
b/UefiCpuPkg/Library/MpInitLib/AmdSev.c
index bda4960f6fd3..d34f9513e002 100644
--- a/UefiCpuPkg/Library/MpInitLib/AmdSev.c
+++ b/UefiCpuPkg/Library/MpInitLib/AmdSev.c
@@ -256,7 +256,14 @@ FillExchangeInfoDataSevEs (
if (StdRangeMax >= CPUID_EXTENDED_TOPOLOGY) {
  CPUID_EXTENDED_TOPOLOGY_EBX  ExtTopoEbx;
  
-AsmCpuid (CPUID_EXTENDED_TOPOLOGY, NULL, , NULL, NULL);

+AsmCpuidEx (
+  CPUID_EXTENDED_TOPOLOGY,
+  0,
+  NULL,
+  ,
+  NULL,
+  NULL
+  );
  ExchangeInfo->ExtTopoAvail = !!ExtTopoEbx.Bits.LogicalProcessors;
}
  }



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110771): https://edk2.groups.io/g/devel/message/110771
Mute This Topic: https://groups.io/mt/102432782/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 0/2] SEV-SNP guest support fixes

[Lendacky, Thomas via groups.io]

This patch series provides fixes around AP startup and sorting:

- The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a sub-leaf as input. The
  current SEV-SNP support is attempting to retrieve the this leaf with
  sub-leaf 0, but is calling AsmCpuid(), which does not clear ECX before
  invoking the CPUID instruction. Therefore, because of the calling
  convention, the leaf value becomes the sub-leaf value and ends up
  returning incorrect information. Change the call from AsmCpuid() to
  AsmCpuidEx().

- When sorting the CPUs by APIC ID, the VMSA associated with the vCPU
  should follow the APIC ID. Update the sorting code to swap the VMSA
  pointer during the sort.

---

These patches are based on commit:
da219919538b ("BaseTools: GenFw: auto-set nxcompat flag")

Tom Lendacky (2):
  UefiCpuPkg/MpInitLib: Use AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY
leaf
  UefiCpuPkg/MpInitLib: Copy SEV-ES save area pointer during APIC ID
sorting

 UefiCpuPkg/Library/MpInitLib/AmdSev.c | 9 -
 UefiCpuPkg/Library/MpInitLib/MpLib.c  | 8 +++-
 2 files changed, 15 insertions(+), 2 deletions(-)

-- 
2.42.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110766): https://edk2.groups.io/g/devel/message/110766
Mute This Topic: https://groups.io/mt/102432041/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 2/2] UefiCpuPkg/MpInitLib: Copy SEV-ES save area pointer during APIC ID sorting

[Lendacky, Thomas via groups.io]

With SEV-SNP, the SEV-ES save area for a vCPU should be unique to that
vCPU. After commit 3323359a811a, the VMSA allocation was re-used, but when
sorting the CPUs by APIC ID, the save area was not updated to follow the
original CPU. Similar to the StartupApSignal address, the SevEsSaveArea
address should be updated when sorting the CPUs.

This does not cause an issue at this time because all APs are in HLT state
and then are (re)started at the same time, with the same VMSA contents.
However, this should be fixed to account for any change in future
behavior.

Fixes: 3323359a811a ("UefiCpuPkg/MpInitLib: Reuse VMSA allocation to ...")
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/Library/MpInitLib/MpLib.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 9a6ec5db5ce9..a41b9e5701af 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -370,6 +370,7 @@ SortApicId (
   UINT32   ApCount;
   CPU_INFO_IN_HOB  *CpuInfoInHob;
   volatile UINT32  *StartupApSignal;
+  VOID *SevEsSaveArea;
 
   ApCount  = CpuMpData->CpuCount - 1;
   CpuInfoInHob = (CPU_INFO_IN_HOB *)(UINTN)CpuMpData->CpuInfoInHob;
@@ -397,12 +398,17 @@ SortApicId (
 CopyMem ([Index1], , sizeof (CPU_INFO_IN_HOB));
 
 //
-// Also exchange the StartupApSignal.
+// Also exchange the StartupApSignal and SevEsSaveArea.
 //
 StartupApSignal= 
CpuMpData->CpuData[Index3].StartupApSignal;
 CpuMpData->CpuData[Index3].StartupApSignal =
   CpuMpData->CpuData[Index1].StartupApSignal;
 CpuMpData->CpuData[Index1].StartupApSignal = StartupApSignal;
+
+SevEsSaveArea= 
CpuMpData->CpuData[Index3].SevEsSaveArea;
+CpuMpData->CpuData[Index3].SevEsSaveArea =
+  CpuMpData->CpuData[Index1].SevEsSaveArea;
+CpuMpData->CpuData[Index1].SevEsSaveArea = SevEsSaveArea;
   }
 }
 
-- 
2.42.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110768): https://edk2.groups.io/g/devel/message/110768
Mute This Topic: https://groups.io/mt/102432047/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/2] UefiCpuPkg/MpInitLib: Use AsmCpuidEx() for CPUID_EXTENDED_TOPOLOGY leaf

[Lendacky, Thomas via groups.io]

The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a subleaf as input when
returning CPUID information. However, the AsmCpuid() function does not
zero out ECX before the CPUID instruction, so the input leaf is used as
the sub-leaf for the CPUID request and returns erroneous/invalid CPUID
data, since the intent of the request was to get data related to sub-leaf
0. Instead, use AsmCpuidEx() for the CPUID_EXTENDED_TOPOLOGY leaf.

Fixes: d4d7c9ad5fe5 ("UefiCpuPkg/MpInitLib: use BSP to do extended ...")
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/Library/MpInitLib/AmdSev.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/AmdSev.c 
b/UefiCpuPkg/Library/MpInitLib/AmdSev.c
index bda4960f6fd3..d34f9513e002 100644
--- a/UefiCpuPkg/Library/MpInitLib/AmdSev.c
+++ b/UefiCpuPkg/Library/MpInitLib/AmdSev.c
@@ -256,7 +256,14 @@ FillExchangeInfoDataSevEs (
   if (StdRangeMax >= CPUID_EXTENDED_TOPOLOGY) {
 CPUID_EXTENDED_TOPOLOGY_EBX  ExtTopoEbx;
 
-AsmCpuid (CPUID_EXTENDED_TOPOLOGY, NULL, , NULL, NULL);
+AsmCpuidEx (
+  CPUID_EXTENDED_TOPOLOGY,
+  0,
+  NULL,
+  ,
+  NULL,
+  NULL
+  );
 ExchangeInfo->ExtTopoAvail = !!ExtTopoEbx.Bits.LogicalProcessors;
   }
 }
-- 
2.42.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110767): https://edk2.groups.io/g/devel/message/110767
Mute This Topic: https://groups.io/mt/102432043/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev

[Lendacky, Thomas via groups.io]

On 10/27/23 03:05, Tan, Dun wrote:

Hi all,

Could you please help to review this patch set? In this patch set, the IoLib 
instance BaseIoLibIntrinsic is modified to support AMD SEV feature and the 
BaseIoLibIntrinsicSev is removed.
Also could you help to do a test on AMD processor to make sure that the SEV 
feature still works good with this patch set?


I was able to test SEV, SEV-ES and SEV-SNP guests successfully at each 
step of the patchset.


However, you are unrolling the string I/O for everyone, now, not just SEV 
guests. Is that acceptable to the community? I think there need to be 
comments in IoLibFifo.c around the new code about why the access is 
unrolled/looping so that someone down the road doesn't come along and try 
to use string I/O again.


From a commit message standpoint, you have up to 74 characters per line 
to use and I see most of your messages do not make use of that. Also, you 
use sev when it should be SEV. Using SEV will make grep'ing commit 
messages simpler.


Thanks,
Tom



Thanks,
Dun

-Original Message-
From: Tan, Dun
Sent: Friday, October 27, 2023 3:35 PM
To: Yao, Jiewen ; devel@edk2.groups.io
Subject: RE: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic 
and remove BaseIoLibIntrinsicSev

Thanks for the suggestion.
I'll update the test result once I finished the test. Also the abstract message 
in this patch has been modified to mention that this patch should not be merged 
now.

Thanks,
Dun

-Original Message-
From: Yao, Jiewen 
Sent: Friday, October 27, 2023 3:07 PM
To: Tan, Dun ; devel@edk2.groups.io
Subject: RE: [edk2-devel] [PATCH 0/7] Support Tdx and sev in BaseIoLibIntrinsic 
and remove BaseIoLibIntrinsicSev

Here is my suggestion:

1) Please perform the test to ensure the functional part is correct.

Without that, how can people know you are doing things right?

2) If you do not run any test, before you send out patch, please call out that 
clearly.
That is important to reminder the maintainer: Don't merge, even if it pass 
review.

Otherwise, once the review passed, the maintainer may merge it.
I don't think that is the intention.



Thank you
Yao, Jiewen
  


-Original Message-
From: Tan, Dun 
Sent: Friday, October 27, 2023 2:32 PM
To: Yao, Jiewen ; devel@edk2.groups.io
Subject: RE: [edk2-devel] [PATCH 0/7] Support Tdx and sev in
BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev

Hi Jiewen,

Currently I'm working on the Tdx test. Since the patch set doesn't
change the code logic when Tdx or SEV is enabled, so I want to send
out the patch as soon as possible to see if there is any comments from 
community.

I will include AMD SEV reviewer in this patch series. Thanks for reminding.

Thanks,
Dun

-Original Message-
From: Yao, Jiewen 
Sent: Friday, October 27, 2023 1:49 PM
To: devel@edk2.groups.io; Tan, Dun 
Subject: RE: [edk2-devel] [PATCH 0/7] Support Tdx and sev in
BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev

HI
Since this impact TDX and SEV, would you please let me know what kind
of test you have done?
Have you validated TDX and SEV before you submit the patch? Please
describe that clearly in your patch description.

Also please include AMD SEV reviewer in this patch series.

Thank you
Yao, Jiewen


-Original Message-
From: devel@edk2.groups.io  On Behalf Of
duntan
Sent: Friday, October 27, 2023 1:43 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] [PATCH 0/7] Support Tdx and sev in
BaseIoLibIntrinsic and remove BaseIoLibIntrinsicSev (Don't merge
because the test hasn't been completed yet.)

The goal is to have single BaseIoLibIntrinsic instance that can also
used for sev and Tdx.
In this patch set, string I/O instructions are deleted in IoRead/WriteFifo API.
Then change the source file of BaseIoLibIntrinsic to also support
Tdx and sev feature. So BaseIoLibIntrinsicSev and related assembly
code can be

removed.


Dun Tan (7):
   MdePkg: Create TdxLibNull.inf instance
   MdePkg: Add CcProbeLibNull and TdxLibNull implement
   MdePkg: simplify IoRead/WriteFifo in IoLibFifo.c
   MdePkg:support Tdx and sev in BaseIoLibIntrinsic
   OvmfPkg: Add CcProbeLib in PlatformInitLib.inf
   OvmfPkg: use BaseIoLibIntrinsic.inf in dsc files
   MdePkg:remove BaseIoLibIntrinsicSev related code

  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf|  14 
++---

-

  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf |  61
--
---
  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifo.nasm  | 131 
-

---


--

-
  MdePkg/Library/BaseIoLibIntrinsic/Ia32/IoFifoSev.nasm   | 293 
---

---


--


--

Re: [edk2-devel] [PATCH] OvmfPkg/ResetVector: Fix assembler bit test flag check

[Lendacky, Thomas via groups.io]

On 9/19/23 02:59, Gerd Hoffmann wrote:

On Fri, Jul 14, 2023 at 03:28:26PM -0500, Tom Lendacky wrote:

Commit 63c50d3ff2854a76432b752af4f2a76f33ff1974 changed the check that is
used to determine if SEV-ES is active. Originally, a CMP instruction with
a supporting JZ instruction was used for the check. It was changed to use
the BT instruction but not JZ instruction. The result of a BT instruction
changes the the carry flag (CF) and not the zero flag (ZF). As a result,
the wrong condition is being checked. Update the JZ to a JNC to properly
detect if SEV-ES is active.


What is the effect of this bug?  Is it just the encryption sanity check
being skipped?


Yes, it is just causing the mitigation check to be skipped. Because of the 
previous xor instruction, the JZ instruction will always be taken.


Thanks,
Tom



take care,
   Gerd




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108830): https://edk2.groups.io/g/devel/message/108830
Mute This Topic: https://groups.io/mt/100149226/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg: Set PciLib for TdxDxe driver

[Lendacky, Thomas via groups.io]

On 4/19/22 00:06, Yao, Jiewen wrote:

OK. Let me describe what I think.

PCI Express BAR need to be initialized by someone in the platform.
This initialization may require CFG8. That is understandable.

A good design is that: After the PCIE BAR is initialized, it can be accessed.
Requires additional step (such as clear C-bit) means the PCIE BAR is not fully 
initialized originally. I don't think it is a good idea.

So far, the problem is TdxDxe, but what if a PEI driver also wants to use 
access PCIE space? It may run into same problem.

I think the best way is to clear C-bit in PciExBarInitialization(), as SEV 
specific step to finish initialization. 
https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PlatformInitLib/Platform.c#L261

As such, no matter how many drivers want to use PCIE, they can.


Splitting PCIE bar programming and C bit clearing is a big problem. In this 
window, no one can actually touch the PCIE bar, although it seems being 
initialized...


I tried this approach and it does not work. It is because new page tables 
are used in the DXE phase and so the c-bit has to be cleared in the new 
page tables vs the page tables used in PEI.


Thanks,
Tom




Thank you
Yao Jiewen


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Yao, Jiewen
Sent: Tuesday, April 19, 2022 12:47 PM
To: Xu, Min M ; devel@edk2.groups.io
Cc: Brijesh Singh ; Aktas, Erdem
; James Bottomley ; Tom
Lendacky 
Subject: Re: [edk2-devel] [PATCH] OvmfPkg: Set PciLib for TdxDxe driver

Can SEV clear the C-bit in SEC phase?

I think that is right way to ensure PCI Express can always be accessed by 
anyone.



-Original Message-
From: Xu, Min M 
Sent: Tuesday, April 19, 2022 12:39 PM
To: Yao, Jiewen ; devel@edk2.groups.io
Cc: Brijesh Singh ; Aktas, Erdem
; James Bottomley ; Tom
Lendacky 
Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Set PciLib for TdxDxe driver

In AmdSevDxe's entry point it clears the C-bit from PcdPciExpressBaseAddress
and other memory spaces if needed. Please see


https://github.com/tianocore/edk2/blob/master/OvmfPkg/AmdSevDxe/AmdSev

Dxe.c#L81-L95. After that OVMF can use PCI express.

This broken is caused by the call sequence of TdxDxe driver and AmdSevDxe
driver. Currently TdxDxe driver is loaded before AmdSevDxe, so in SEV-ES guest
the C-bit of PcdPciExpressBaseAddress hasn't been cleared. In this situation

the

access to PciExpressBaseAddress trigger exceptions (lib constructor in TdxDxe).

There are 2 options to fix this issue.
1. Adjust the load sequence of AmdSevDxe and TdxDxe (Load AmdSevDxe

before

TdxDxe)
2. Make TdxDxe to import BasePciLibCf8.inf instead of DxePciLibI440FxQ35.inf
(just like AmdSevDxe)

Tom and I tested above 2 options in SEV and TDX and all work.


-Original Message-
From: Yao, Jiewen 
Sent: Tuesday, April 19, 2022 12:16 PM
To: Xu, Min M ; devel@edk2.groups.io
Cc: Brijesh Singh ; Aktas, Erdem
; James Bottomley ; Tom
Lendacky 
Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Set PciLib for TdxDxe driver

Do you mean, with SEV introduced, OVMF cannot use PCI express any more?

Thank you
Yao Jiewen



-Original Message-
From: Xu, Min M 
Sent: Tuesday, April 19, 2022 11:05 AM
To: Yao, Jiewen ; devel@edk2.groups.io
Cc: Brijesh Singh ; Aktas, Erdem
; James Bottomley ;

Tom

Lendacky 
Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Set PciLib for TdxDxe
driver

On April 19, 2022 10:54 AM, Yao Jiewen wrote:


Why does TdxDxe call TdxMailbox in an SEV platform?
Or why does TdxMailbox call SynchronizationLib in an SEV platform?


TdxDxe will not call TdxMailbox/SynchronizationLib in SEV platform.
The problem is in the lib constructor. When TdxDxe driver is loaded,
before its entry point is called, the lib constructors will be called even in a

SEV platform.


There are many places we can do CcProbe to stop action. Why we need
do it in DSC?

So we cannot stop the lib constructor with CcProbe in this case.

Thanks
Min










-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89195): https://edk2.groups.io/g/devel/message/89195
Mute This Topic: https://groups.io/mt/90554139/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg: Set PciLib for TdxDxe driver

[Lendacky, Thomas via groups.io]

On 4/18/22 23:47, Yao, Jiewen wrote:

Can SEV clear the C-bit in SEC phase?


Not really. IIRC, even if cleared in the SEC phase, the DXE phase replaces 
the page tables and it has to be cleared again.


Thanks,
Tom



I think that is right way to ensure PCI Express can always be accessed by 
anyone.



-Original Message-
From: Xu, Min M 
Sent: Tuesday, April 19, 2022 12:39 PM
To: Yao, Jiewen ; devel@edk2.groups.io
Cc: Brijesh Singh ; Aktas, Erdem
; James Bottomley ; Tom
Lendacky 
Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Set PciLib for TdxDxe driver

In AmdSevDxe's entry point it clears the C-bit from PcdPciExpressBaseAddress
and other memory spaces if needed. Please see
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FOvmfPkg%2FAmdSevDxe%2FAmdSevdata=04%7C01%7Cthomas.lendacky%40amd.com%7Cc39c49fd4e944900bdb708da21bfac91%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637859404370071519%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9sxJnGXyaiHTdIzS%2BTzziBnwTAsKvSLFRMmHT4HGe60%3Dreserved=0
Dxe.c#L81-L95. After that OVMF can use PCI express.

This broken is caused by the call sequence of TdxDxe driver and AmdSevDxe
driver. Currently TdxDxe driver is loaded before AmdSevDxe, so in SEV-ES guest
the C-bit of PcdPciExpressBaseAddress hasn't been cleared. In this situation the
access to PciExpressBaseAddress trigger exceptions (lib constructor in TdxDxe).

There are 2 options to fix this issue.
1. Adjust the load sequence of AmdSevDxe and TdxDxe (Load AmdSevDxe before
TdxDxe)
2. Make TdxDxe to import BasePciLibCf8.inf instead of DxePciLibI440FxQ35.inf
(just like AmdSevDxe)

Tom and I tested above 2 options in SEV and TDX and all work.


-Original Message-
From: Yao, Jiewen 
Sent: Tuesday, April 19, 2022 12:16 PM
To: Xu, Min M ; devel@edk2.groups.io
Cc: Brijesh Singh ; Aktas, Erdem
; James Bottomley ; Tom
Lendacky 
Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Set PciLib for TdxDxe driver

Do you mean, with SEV introduced, OVMF cannot use PCI express any more?

Thank you
Yao Jiewen



-Original Message-
From: Xu, Min M 
Sent: Tuesday, April 19, 2022 11:05 AM
To: Yao, Jiewen ; devel@edk2.groups.io
Cc: Brijesh Singh ; Aktas, Erdem
; James Bottomley ; Tom
Lendacky 
Subject: RE: [edk2-devel] [PATCH] OvmfPkg: Set PciLib for TdxDxe
driver

On April 19, 2022 10:54 AM, Yao Jiewen wrote:


Why does TdxDxe call TdxMailbox in an SEV platform?
Or why does TdxMailbox call SynchronizationLib in an SEV platform?


TdxDxe will not call TdxMailbox/SynchronizationLib in SEV platform.
The problem is in the lib constructor. When TdxDxe driver is loaded,
before its entry point is called, the lib constructors will be called even in a

SEV platform.


There are many places we can do CcProbe to stop action. Why we need
do it in DSC?

So we cannot stop the lib constructor with CcProbe in this case.

Thanks
Min



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89076): https://edk2.groups.io/g/devel/message/89076
Mute This Topic: https://groups.io/mt/90554139/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V4 5/7] OvmfPkg: Add CcProbeLib in *.dsc

[Lendacky, Thomas via groups.io]

On 4/19/22 08:16, Tom Lendacky wrote:

On 4/18/22 19:26, Min Xu wrote:

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

CcProbeLib is imported in BaseIoLibIntrinsicSev.
OvmfPkg/Library/CcProbeLib is the OvmfPkg version which checks
OvmfWorkArea to return the Cc guest type. It is included
in OvmfPkgX64.dsc and IntelTdx/IntelTdxX64.dsc.

Other .dsc include the MdePkg/Library/CcProbeLibNull because Cc guest
is not supported in those projects.


Hmm... you missed my comment about OvmfPkgIa32X64.dsc requiring the 
non-NULL library.


Also, I'm not sure that the NULL library is what the AmdSevX64.dsc build 
needs. @James Bottomley, have you tested this series?




Although I guess everything should work since you aren't replacing the 
work area checks in the SEV related files with CcProbe (), only the values 
that are checked against. Sorry for the noise.


Thanks,
Tom


Thanks,
Tom



Cc: James Bottomley 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Tom Lendacky 
Reviewed-by: Jiewen Yao 
Reviewed-by: Tom Lendacky 
Signed-off-by: Min Xu 
---
  OvmfPkg/AmdSev/AmdSevX64.dsc | 1 +
  OvmfPkg/Bhyve/BhyveX64.dsc   | 1 +
  OvmfPkg/CloudHv/CloudHvX64.dsc   | 1 +
  OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 +
  OvmfPkg/Microvm/MicrovmX64.dsc   | 1 +
  OvmfPkg/OvmfPkgIa32.dsc  | 1 +
  OvmfPkg/OvmfPkgIa32X64.dsc   | 1 +
  OvmfPkg/OvmfPkgX64.dsc   | 1 +
  OvmfPkg/OvmfXen.dsc  | 1 +
  9 files changed, 9 insertions(+)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index fcdc3efab204..1c088f25fa4b 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -149,6 +149,7 @@
    PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf 


PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf

+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
    IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf 


    SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index e1b6b8e15f36..a8fa4d38ab60 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -146,6 +146,7 @@
    PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf 


PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf

+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
    IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf 


    SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc 
b/OvmfPkg/CloudHv/CloudHvX64.dsc

index 20f3bc340807..d1c85f60c768 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -158,6 +158,7 @@
    PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf 


PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf

+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
    IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf 


    SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc 
b/OvmfPkg/IntelTdx/IntelTdxX64.dsc

index 245155d41b30..73a6c30096a8 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -135,6 +135,7 @@
    PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf 


PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf

+  CcProbeLib|OvmfPkg/Library/CcProbeLib/CcProbeLib.inf
    IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf 


    SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc 
b/OvmfPkg/Microvm/MicrovmX64.dsc

index 59580ccd4691..c9c843e116a9 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -156,6 +156,7 @@
    PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf 


PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf

+  

Re: [edk2-devel] [PATCH V4 5/7] OvmfPkg: Add CcProbeLib in *.dsc

[Lendacky, Thomas via groups.io]

On 4/18/22 19:26, Min Xu wrote:

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

CcProbeLib is imported in BaseIoLibIntrinsicSev.
OvmfPkg/Library/CcProbeLib is the OvmfPkg version which checks
OvmfWorkArea to return the Cc guest type. It is included
in OvmfPkgX64.dsc and IntelTdx/IntelTdxX64.dsc.

Other .dsc include the MdePkg/Library/CcProbeLibNull because Cc guest
is not supported in those projects.


Hmm... you missed my comment about OvmfPkgIa32X64.dsc requiring the 
non-NULL library.


Also, I'm not sure that the NULL library is what the AmdSevX64.dsc build 
needs. @James Bottomley, have you tested this series?


Thanks,
Tom



Cc: James Bottomley 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Tom Lendacky 
Reviewed-by: Jiewen Yao 
Reviewed-by: Tom Lendacky 
Signed-off-by: Min Xu 
---
  OvmfPkg/AmdSev/AmdSevX64.dsc | 1 +
  OvmfPkg/Bhyve/BhyveX64.dsc   | 1 +
  OvmfPkg/CloudHv/CloudHvX64.dsc   | 1 +
  OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 +
  OvmfPkg/Microvm/MicrovmX64.dsc   | 1 +
  OvmfPkg/OvmfPkgIa32.dsc  | 1 +
  OvmfPkg/OvmfPkgIa32X64.dsc   | 1 +
  OvmfPkg/OvmfPkgX64.dsc   | 1 +
  OvmfPkg/OvmfXen.dsc  | 1 +
  9 files changed, 9 insertions(+)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index fcdc3efab204..1c088f25fa4b 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -149,6 +149,7 @@
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index e1b6b8e15f36..a8fa4d38ab60 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -146,6 +146,7 @@
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index 20f3bc340807..d1c85f60c768 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -158,6 +158,7 @@
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 245155d41b30..73a6c30096a8 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -135,6 +135,7 @@
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|OvmfPkg/Library/CcProbeLib/CcProbeLib.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 59580ccd4691..c9c843e116a9 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -156,6 +156,7 @@
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git 

Re: [edk2-devel] [PATCH] OvmfPkg: Make an Ia32/X64 hybrid build work with SEV

[Lendacky, Thomas via groups.io]

On 5/16/22 15:24, Lendacky, Thomas via groups.io wrote:

The BaseMemEncryptSevLib functionality was updated to rely on the use of
the OVMF/SEV workarea to check for SEV guests. However, this area is only
updated when running the X64 OVMF build, not the hybrid Ia32/X64 build.
Base SEV support is allowed under the Ia32/X64 build, but it now fails
to boot as a result of the change.

Update the ResetVector code to check for SEV features when built for
32-bit mode, not just 64-bit mode (requiring updates to both the Ia32
and Ia32X64 fdf files).


So this is a regression and it would be great if it could be applied to 
the 202205 release. Can folks take a look and make sure it looks safe to 
them for applying during hard feature freeze?


If it's ok to be applied now, is there a particular process for applying 
this during hard freeze?


Thanks,
Tom



Fixes: f1d1c337e7c0575da7fd248b2dd9cffc755940df
Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Michael Roth 
Cc: Min Xu 
Signed-off-by: Tom Lendacky 
---
  OvmfPkg/OvmfPkgIa32.fdf   | 11 +++
  OvmfPkg/OvmfPkgIa32X64.fdf|  8 +++
  OvmfPkg/OvmfPkgX64.fdf|  3 +-
  OvmfPkg/ResetVector/Ia32/AmdSev.asm   |  4 ++
  OvmfPkg/ResetVector/Main.asm  |  6 ++
  OvmfPkg/ResetVector/ResetVector.nasmb | 72 ++--
  6 files changed, 67 insertions(+), 37 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 3ab1755749d4..57d13b7130bc 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -76,6 +76,9 @@ [FD.MEMFD]
  0x007000|0x001000
  
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
  
+0x008000|0x001000

+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize
+
  0x01|0x01
  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
  
@@ -87,6 +90,14 @@ [FD.MEMFD]

  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
  FV = DXEFV
  
+##

+# Set the SEV-ES specific work area PCDs (used for all forms of SEV since the
+# the SEV STATUS MSR is now saved in the work area)
+#
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) +  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+##
+
  

  
  [FV.SECFV]

diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index e1638fa6ea38..ccde366887a9 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -90,6 +90,14 @@ [FD.MEMFD]
  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
  FV = DXEFV
  
+##

+# Set the SEV-ES specific work area PCDs (used for all forms of SEV since the
+# the SEV STATUS MSR is now saved in the work area)
+#
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) +  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+##
+
  

  
  [FV.SECFV]

diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index aa9a83032d9b..438806fba8f1 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -106,7 +106,8 @@ [FD.MEMFD]
  FV = DXEFV
  
  ##

-# Set the SEV-ES specific work area PCDs
+# Set the SEV-ES specific work area PCDs (used for all forms of SEV since the
+# the SEV STATUS MSR is now saved in the work area)
  #
  SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) +  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
  SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
b

Re: [edk2-devel] [PATCH v3 0/4] Fix AP Jump Table Handling for SEV-SNP

[Lendacky, Thomas via groups.io]

On 5/20/22 10:27, Michael Roth wrote:

A full-featured SEV-SNP guest will not rely on the AP jump table, and
will instead use the AP Creation interface defined by the GHCB. However,
a guest is still allowed to use the AP jump table if desired.

However, unlike with SEV-ES guests, SEV-SNP guests should not
store/retrieve the jump table address via GHCB requests to the
hypervisor, they should instead store/retrieve it via the SEV-SNP
secrets page.

This series implements the store side of this for OVMF by introducing a
PCD that can be used to pass the SEV-SNP secrets page address to
UefiCpuPkg, where the jump table address is allocated. It also
introduces a struct that defines the SEV-SNP secrets page format
according to the GHCB v2.01 and SEV-SNP FW ABI specifications.

v3:
  - Break up single patch into a set of patches containing the specific
changes for each package. (Ray)

v2:
  - Update Secrets OS area to match latest GHCB 2.01 spec (Tom)
  - Move Secrets header file into ./Register/AMD subdirectory (Tom)
  - Fix CI EccCheck due to assignment in variable declaration


Aside from the minor comment on patch 4, for the series:

Reviewed-by: Tom Lendacky 



  MdePkg/Include/Register/Amd/SnpSecretsPage.h  | 56 

  MdePkg/MdePkg.dec |  4 
  OvmfPkg/AmdSev/AmdSevX64.dsc  |  3 +++
  OvmfPkg/CloudHv/CloudHvX64.dsc|  3 +++
  OvmfPkg/IntelTdx/IntelTdxX64.dsc  |  3 +++
  OvmfPkg/Microvm/MicrovmX64.dsc|  3 +++
  OvmfPkg/OvmfPkgIa32.dsc   |  3 +++
  OvmfPkg/OvmfPkgIa32X64.dsc|  3 +++
  OvmfPkg/OvmfPkgX64.dsc|  3 +++
  OvmfPkg/PlatformPei/AmdSev.c  |  5 +
  OvmfPkg/PlatformPei/PlatformPei.inf   |  1 +
  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |  1 +
  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   | 10 ++
  13 files changed, 98 insertions(+)





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89968): https://edk2.groups.io/g/devel/message/89968
Mute This Topic: https://groups.io/mt/91279450/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 4/4] UefiCpuPkg: Store SEV-SNP AP jump table in the secrets page

[Lendacky, Thomas via groups.io]

On 5/20/22 10:27, Michael Roth wrote:

A full-featured SEV-SNP guest will not rely on the AP jump table, and
will instead use the AP Creation interface defined by the GHCB. However,
a guest is still allowed to use the AP jump table if desired.

However, unlike with SEV-ES guests, SEV-SNP guests should not
store/retrieve the jump table address via GHCB requests to the
hypervisor, they should instead store/retrieve it via the SEV-SNP
secrets page. Implement the store side of this for OVMF.

Suggested-by: Tom Lendacky 
Signed-off-by: Michael Roth 
---
  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |  1 +
  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   | 10 ++
  2 files changed, 11 insertions(+)

diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf 
b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
index e1cd0b3500..d8cfddcd82 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
@@ -80,3 +80,4 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard  ## 
CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase   ## 
CONSUMES
gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr   ## 
CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdSevSnpSecretsAddress ## 
CONSUMES
diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c 
b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
index 60d14a5a0e..4d6f7643db 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 
  
@@ -216,6 +217,15 @@ GetSevEsAPMemory (
  
DEBUG ((DEBUG_INFO, "Dxe: SevEsAPMemory = %lx\n", (UINTN)StartAddress));
  
+  if (ConfidentialComputingGuestHas (CCAttrAmdSevSnp)) {

+SNP_SECRETS_PAGE  *Secrets;
+
+Secrets   = (SNP_SECRETS_PAGE *)(INTN)PcdGet64 
(PcdSevSnpSecretsAddress);
+Secrets->OsArea.ApJumpTablePa = (UINT64)(UINTN)StartAddress;
+
+return (UINTN)StartAddress;
+  }
+


Just a nit, but I probably would have still put this under the comment 
below, because you are still saving the SevEsAPMemory as the AP jump table.


It might look cleaner with the non-SNP path as the else and have the 
single return.


Probably not worth another version, but up to you.

Thanks,
Tom


//
// Save the SevEsAPMemory as the AP jump table.
//



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89967): https://edk2.groups.io/g/devel/message/89967
Mute This Topic: https://groups.io/mt/91279454/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3] OvmfPkg/ResetVector: Removing SEV-ES CPUID bit check

[Lendacky, Thomas via groups.io]

On 6/1/22 07:25, Ard Biesheuvel wrote:

On Tue, 31 May 2022 at 16:40, Peter Gonda  wrote:


The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to
determine support for running SEV-ES guests. It should not be checked by
a guest to determine if it is running under SEV-ES. The guest should use
the SEV_STATUS MSR Bit 1 to determine if SEV-ES is enabled. This check
was not part of the original SEV-ES support and was added in
a91b700e38. Removing the check makes this code consistent with the
Linux kernel

Fixes: a91b700e38 (Ovmf/ResetVector: Simplify and consolidate the SEV features 
checks)

Cc: James Bottomley 
Cc: Min Xu 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Cc: Laszlo Ersek 
Cc: Erdem Aktas 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Marc Orr 
Signed-off-by: Peter Gonda 
Acked-by: Tom Lendacky 

---
  OvmfPkg/ResetVector/Ia32/AmdSev.asm | 8 
  1 file changed, 8 deletions(-)

diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
index 1f827da3b9..77692db27e 100644
--- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -265,14 +265,6 @@ CheckSevFeatures:
  ; Set the work area header to indicate that the SEV is enabled
  mov byte[WORK_AREA_GUEST_TYPE], 1

-; 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, 0x801f
-cpuid
-bteax, 3
-jnc   GetSevEncBit
-
  ; Check if SEV-ES is enabled
  ;  MSR_0xC0010131 - Bit 1 (SEV-ES enabled)
  mov   ecx, SEV_STATUS_MSR


Thanks Peter, I have queued this up.

I did wonder, though: the only remaining reference to GetSevEncBit is
a conditional branch that just precedes the label itself. This appears
to be a leftover from commit 63c50d3ff2854a76 ("OvmfPkg/ResetVector:
cache the SEV status MSR value in workarea") but it looks a bit dodgy.


Yes, it looks like the rdmsr and the GetSevEncBit: label can all be 
removed since the MSR value is now cached (a few lines above) and used for 
checks.


Thanks,
Tom


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90127): https://edk2.groups.io/g/devel/message/90127
Mute This Topic: https://groups.io/mt/91473916/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: Store SEV-SNP AP jump table in the secrets page

[Lendacky, Thomas via groups.io]

On 5/13/22 08:22, Michael Roth wrote:

A full-featured SEV-SNP guest will not rely on the AP jump table, and
will instead use the AP Creation interface defined by the GHCB. However,
a guest is still allowed to use the AP jump table if desired.

However, unlike with SEV-ES guests, SEV-SNP guests should not
store/retrieve the jump table address via GHCB requests to the
hypervisor, they should instead store/retrieve it via the SEV-SNP
secrets page. Implement the store side of this for OVMF.

Suggested-by: Tom Lendacky 
Signed-off-by: Michael Roth 
---
  MdePkg/Include/AmdSevSnpSecretsPage.h | 51 +++
  MdePkg/MdePkg.dec |  4 ++
  OvmfPkg/AmdSev/AmdSevX64.dsc  |  3 ++
  OvmfPkg/CloudHv/CloudHvX64.dsc|  3 ++
  OvmfPkg/IntelTdx/IntelTdxX64.dsc  |  3 ++
  OvmfPkg/Microvm/MicrovmX64.dsc|  3 ++
  OvmfPkg/OvmfPkgIa32.dsc   |  3 ++
  OvmfPkg/OvmfPkgIa32X64.dsc|  3 ++
  OvmfPkg/OvmfPkgX64.dsc|  3 ++
  OvmfPkg/PlatformPei/AmdSev.c  |  5 ++
  OvmfPkg/PlatformPei/PlatformPei.inf   |  1 +
  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |  1 +
  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   |  9 
  13 files changed, 92 insertions(+)
  create mode 100644 MdePkg/Include/AmdSevSnpSecretsPage.h

diff --git a/MdePkg/Include/AmdSevSnpSecretsPage.h 
b/MdePkg/Include/AmdSevSnpSecretsPage.h
new file mode 100644
index 00..55c7475ff0
--- /dev/null
+++ b/MdePkg/Include/AmdSevSnpSecretsPage.h


Just wondering if this should be in the MdePkg/Include/Register/Amd directory?


@@ -0,0 +1,51 @@
+/** @file
+Definitions for AMD SEV-SNP Secrets Page
+
+Copyright (c) 2022 AMD Inc. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef AMD_SEV_SNP_SECRETS_PAGE_H_
+#define AMD_SEV_SNP_SECRETS_PAGE_H_
+
+//
+// OS-defined area of secrets page
+//
+// As defined by "SEV-ES Guest-Hypervisor Communication Block Standardization",
+// revision 1.50, section 2.7, "SEV-SNP Secrets Page".


This should be using at least revision 2.00 (if not 2.01 which is in the 
process of being published). 2.01 uses some of the 40-byte reserved area 
to hold the high 32-bits of the message sequence numbers (since the SNP 
API changed after the GHCB spec was published to convert the sequence 
numbers from 32-bit to 64-bit). The changes are backwards compatible, so 
not a big deal as to whether to implement since OVMF doesn't make any 
guest request API calls.


Thanks,
Tom


+//
+typedef PACKED struct _SNP_SECRETS_OS_AREA {
+  UINT32MsgSeqNum0;
+  UINT32MsgSeqNum1;
+  UINT32MsgSeqNum2;
+  UINT32MsgSeqNum3;
+  UINT64ApJumpTablePa;
+  UINT8 Reserved[40];
+  UINT8 GuestUsage[32];
+} SNP_SECRETS_OS_AREA;
+
+#define VMPCK_KEY_LEN  32
+
+//
+// SEV-SNP Secrets page
+//
+// As defined by "SEV-SNP Firmware ABI", revision 1.51, section 8.17.2.5,
+// "PAGE_TYPE_SECRETS".
+//
+typedef PACKED struct _SNP_SECRETS_PAGE {
+  UINT32 Version;
+  UINT32 ImiEn: 1,
+ Reserved : 31;
+  UINT32 Fms;
+  UINT32 Reserved2;
+  UINT8  Gosvw[16];
+  UINT8  Vmpck0[VMPCK_KEY_LEN];
+  UINT8  Vmpck1[VMPCK_KEY_LEN];
+  UINT8  Vmpck2[VMPCK_KEY_LEN];
+  UINT8  Vmpck3[VMPCK_KEY_LEN];
+  SNP_SECRETS_OS_AREAOsArea;
+  UINT8  Reserved3[3840];
+} SNP_SECRETS_PAGE;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index f1ebf9e251..a365bfcfe8 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2417,5 +2417,9 @@
# @Prompt Memory encryption attribute

gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr|0|UINT64|0x002e
  
+  ## This dynamic PCD indicates the location of the SEV-SNP secrets page.

+  # @Prompt SEV-SNP secrets page address
+  gEfiMdePkgTokenSpaceGuid.PcdSevSnpSecretsAddress|0|UINT64|0x002f
+
  [UserExtensions.TianoCore."ExtraFiles"]
MdePkgExtra.uni
diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index f0700035c1..02306945fd 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -575,6 +575,9 @@
# Set ConfidentialComputing defaults
gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr|0
  
+  # Set SEV-SNP Secrets page address default

+  gEfiMdePkgTokenSpaceGuid.PcdSevSnpSecretsAddress|0
+
  !include OvmfPkg/OvmfTpmPcds.dsc.inc
  
gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1

diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index d1c85f60c7..7143698253 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -630,6 +630,9 @@
# Set ConfidentialComputing defaults
gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr|0
  
+  # Set SEV-SNP Secrets page address default

+ 

Re: [edk2-devel] [PATCH] OvmfPkg/AmdSevDxe: Update ConfidentialComputing blob struct definition

[Lendacky, Thomas via groups.io]

On 5/13/22 08:22, Michael Roth wrote:

The Confidential Computing blob defined here is intended to match the
definition defined by linux guest kernel. Previously, both definitions
relied on natural alignment, but that relies on both OVMF and kernel
being compiled as 64-bit. While there aren't currently any plans to
enable SNP support for 32-bit compilations, the kernel definition has
since been updated to use explicit padding/reserved fields to avoid
this dependency. Update OVMF to match that definition.

No functional changes (for currently-supported environments, at least).

Signed-off-by: Michael Roth 


Minor nit comment below that can be ignored if desired.

Reviewed-by: Tom Lendacky 


---
  OvmfPkg/AmdSevDxe/AmdSevDxe.c  | 2 ++
  OvmfPkg/Include/Guid/ConfidentialComputingSevSnpBlob.h | 6 --
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
index 662d3c4ccb..ee6d2528d9 100644
--- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
+++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
@@ -27,8 +27,10 @@ STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION  
mSnpBootDxeTable = {
0,
(UINT64)(UINTN)FixedPcdGet32 (PcdOvmfSnpSecretsBase),
FixedPcdGet32 (PcdOvmfSnpSecretsSize),
+  0,
(UINT64)(UINTN)FixedPcdGet32 (PcdOvmfCpuidBase),
FixedPcdGet32 (PcdOvmfCpuidSize),
+  0,
  };
  
  EFI_STATUS

diff --git a/OvmfPkg/Include/Guid/ConfidentialComputingSevSnpBlob.h 
b/OvmfPkg/Include/Guid/ConfidentialComputingSevSnpBlob.h
index b328310fd0..83620e31b8 100644
--- a/OvmfPkg/Include/Guid/ConfidentialComputingSevSnpBlob.h
+++ b/OvmfPkg/Include/Guid/ConfidentialComputingSevSnpBlob.h
@@ -18,14 +18,16 @@
  { 0x85, 0x54, 0x93, 0xd7, 0x77, 0x91, 0x2d, 0x42 }, \
}
  
-typedef struct {

+typedef PACKED struct {
UINT32Header;
UINT16Version;
-  UINT16Reserved1;
+  UINT16Reserved;


Not to be picky, but I would have left this as Reserved1 and then made the 
below entries Reserved2 and Reserved3.


Thanks,
Tom


UINT64SecretsPhysicalAddress;
UINT32SecretsSize;
+  UINT32Reserved1;
UINT64CpuidPhysicalAddress;
UINT32CpuidLSize;
+  UINT32Reserved2;
  } CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION;
  
  extern EFI_GUID  gConfidentialComputingSevSnpBlobGuid;



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89722): https://edk2.groups.io/g/devel/message/89722
Mute This Topic: https://groups.io/mt/91080662/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V7 36/37] UefiCpuPkg: Setting initial-count register as the last step

[Lendacky, Thomas via groups.io]

On 5/11/22 19:52, Min Xu via groups.io wrote:

On May 11, 2022 10:06 PM, Lendacky, Thomas wrote:

On 5/10/22 21:00, Xu, Min M wrote:

On May 11, 2022 4:30 AM, Tom Lendacky wrote:

I'm replying to this patch since I can't find patch V12 46/47
anywhere in my email.

I've bisected a regression in the Linux kernel to this patch when an
SEV-SNP guest is booted. The following message is issued in the
kernel for every AP being brought online:

APIC: Stale IRR:


,,,,,,,000

00020 ISR:


,,,,,,,000

0

Possibly a timing issue involving the mode switch with the interrupt
unmasked. If I leave the interrupt masked and only un-mask it after
the programming of the init-count, then the message goes away.


Do you mean in InitializeApicTimer, it should follow below steps:
1. mask LvtTimer. (set LvtTimer.Bits.Mask = 1) 2. Do other stuff,
including programing the init-count register.
3. un-mask LvtTimer (set LvtTimer.Bit.Mask = 0)


Yes, I believe so. I'm not an expert on the APIC timer, but that seems
reasonable to me.

I tested this fix in Td guest and it has no side effect.
I check the Intel SDM (Vol.3A Chap 10.5 Handling Local Interrupts) but it 
doesn't describe the actual sequence of LvtTimer.Bits.Mask and  programming of 
init-count register.
@ Ni, Ray,  What's your thought about it?


I guess you can theoretically miss an interrupt if your initial count is 
expires before you unmask the interrupt, so I think your fix is correct 
and no changes are needed.


I need to double check whether I'm properly resetting the APIC when APs 
are booted multiple times. Since this only occurs with SNP, I think this 
is on my end.


Thanks,
Tom



Thanks
Min








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89732): https://edk2.groups.io/g/devel/message/89732
Mute This Topic: https://groups.io/mt/89446188/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/4] MpInitLib: Put SEV logic in separate file

[Lendacky, Thomas via groups.io]

On 5/7/22 10:13, Ray Ni wrote:

Probably should have a commit message here explaining the reason for the 
changes.


Overall, this works, but it does seem strange to have the SwitchToRealProc 
procedure in the middle of the RendezvousFunnelProc procedure. Not sure if 
it would be worth just creating a second SEV nasm file (and maybe renaming 
the first one):


  AmdSevRendevous.nasm
  AmdSevSwitchToReal.nasm

and then including the two in different locations.

Then you wouldn't have to change any of the size calculations either.

If you want to keep the function within the function and eliminate the use 
of SwitchToRealSize, you should probably update the struct in MpLib.h to 
remove SwitchToRealSize and then update the Ia32 and X64 AsmGetAddressMap 
function to no longer set SwitchToRealSize (or just reserve the field so 
that none of the other offsets change and just remove the set in 
AsmGetAddressMap).


Thanks,
Tom


Signed-off-by: Ray Ni 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Michael Roth 
Cc: James Bottomley 
Cc: Min Xu 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
---
  .../Library/MpInitLib/Ia32/MpFuncs.nasm   |   3 +-
  UefiCpuPkg/Library/MpInitLib/MpLib.c  |  13 +-
  UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm  | 148 +
  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 157 +-
  4 files changed, 159 insertions(+), 162 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm 
b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
index 8981c32722..67f9ed05cf 100644
--- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
+++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
@@ -199,7 +199,6 @@ CProcedureInvoke:
  call   eax   ; Invoke C function
  
  jmp$ ; Never reach here

-RendezvousFunnelProcEnd:
  
  ;-

  ;SwitchToRealProc procedure follows.
@@ -209,6 +208,8 @@ SwitchToRealProcStart:
  jmp$ ; Never reach here
  SwitchToRealProcEnd:
  
+RendezvousFunnelProcEnd:

+
  
;-
  ;  AsmRelocateApLoop (MwaitSupport, ApTargetCState, PmCodeSegment, 
TopOfApStack, CountTofinish, Pm16CodeSegment, SevEsAPJumpTable, WakeupBuffer);
  ;
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 3dc1b9f872..722ff3fd42 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -938,8 +938,7 @@ FillExchangeInfoData (
// EfiBootServicesCode to avoid page fault if NX memory protection is 
enabled.
//
if (CpuMpData->WakeupBufferHigh != 0) {
-Size = CpuMpData->AddressMap.RendezvousFunnelSize +
-   CpuMpData->AddressMap.SwitchToRealSize -
+Size = CpuMpData->AddressMap.RendezvousFunnelSize -
 CpuMpData->AddressMap.ModeTransitionOffset;
  CopyMem (
(VOID *)CpuMpData->WakeupBufferHigh,
@@ -993,8 +992,7 @@ BackupAndPrepareWakeupBuffer (
CopyMem (
  (VOID *)CpuMpData->WakeupBuffer,
  (VOID *)CpuMpData->AddressMap.RendezvousFunnelAddress,
-CpuMpData->AddressMap.RendezvousFunnelSize +
-CpuMpData->AddressMap.SwitchToRealSize
+CpuMpData->AddressMap.RendezvousFunnelSize
  );
  }
  
@@ -1031,7 +1029,6 @@ GetApResetVectorSize (

UINTN  Size;
  
Size = AddressMap->RendezvousFunnelSize +

- AddressMap->SwitchToRealSize +
   sizeof (MP_CPU_EXCHANGE_INFO);
  
return Size;

@@ -1056,11 +1053,9 @@ AllocateResetVector (
  CpuMpData->WakeupBuffer  = GetWakeupBuffer (ApResetVectorSize);
  CpuMpData->MpCpuExchangeInfo = (MP_CPU_EXCHANGE_INFO *)(UINTN)
 (CpuMpData->WakeupBuffer +
-CpuMpData->AddressMap.RendezvousFunnelSize 
+
-CpuMpData->AddressMap.SwitchToRealSize);
+
CpuMpData->AddressMap.RendezvousFunnelSize);
  CpuMpData->WakeupBufferHigh = AllocateCodeBuffer (
-CpuMpData->AddressMap.RendezvousFunnelSize 
+
-CpuMpData->AddressMap.SwitchToRealSize -
+CpuMpData->AddressMap.RendezvousFunnelSize 
-
  CpuMpData->AddressMap.ModeTransitionOffset
  );
  //
diff --git a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm 
b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm
index 8bb1161fa0..7c2469f9c5 100644
--- a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm
+++ b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm
@@ -198,3 +198,151 @@ RestoreGhcb:
  
  SevEsGetApicIdExit:

  OneTimeCallRetSevEsGetApicId
+
+

Re: [edk2-devel] [PATCH v3 3/5] MpInitLib: Put SEV logic in separate file

[Lendacky, Thomas via groups.io]

On 5/16/22 02:14, Ray Ni wrote:

The patch does several simplifications:
1. Treat SwitchToRealProc as part of RendezvousFunnelProc.
So the common logic in MpLib.c doesn't need to be aware of
SwitchToRealProc.
As a result, SwitchToRealSize/Offset are removed from
MP_ASSEMBLY_ADDRESS_MAP.

2. Move SwitchToRealProc to AmdSev.nasm.
All other assembly code in AmdSev.nasm is called through
OneTimeCall.


I hadn't realized that Brijesh made all of the functions in AmdSev.nasm 
OneTimeCall functions, so moving the include now actually gets those 
"functions" out of the RendezvousFunnelProc function. Looks much cleaner 
this way.


Thanks Ray!

Reviewed-by: Tom Lendacky 
Tested-by: Tom Lendacky 



Signed-off-by: Ray Ni 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Michael Roth 
Cc: James Bottomley 
Cc: Min Xu 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
---
  .../Library/MpInitLib/Ia32/MpFuncs.nasm   |   5 +-
  UefiCpuPkg/Library/MpInitLib/MpEqu.inc|   4 +-
  UefiCpuPkg/Library/MpInitLib/MpLib.c  |  13 +-
  UefiCpuPkg/Library/MpInitLib/MpLib.h  |   4 +-
  UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm  | 148 
  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 159 +-
  6 files changed, 161 insertions(+), 172 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm 
b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
index 8981c32722..28301bb8f0 100644
--- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
+++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
@@ -199,7 +199,6 @@ CProcedureInvoke:
  call   eax   ; Invoke C function
  
  jmp$ ; Never reach here

-RendezvousFunnelProcEnd:
  
  ;-

  ;SwitchToRealProc procedure follows.
@@ -209,6 +208,8 @@ SwitchToRealProcStart:
  jmp$ ; Never reach here
  SwitchToRealProcEnd:
  
+RendezvousFunnelProcEnd:

+
  
;-
  ;  AsmRelocateApLoop (MwaitSupport, ApTargetCState, PmCodeSegment, 
TopOfApStack, CountTofinish, Pm16CodeSegment, SevEsAPJumpTable, WakeupBuffer);
  ;
@@ -258,8 +259,6 @@ ASM_PFX(AsmGetAddressMap):
  movdword [ebx + 
MP_ASSEMBLY_ADDRESS_MAP.RelocateApLoopFuncAddress], AsmRelocateApLoopStart
  movdword [ebx + MP_ASSEMBLY_ADDRESS_MAP.RelocateApLoopFuncSize], 
AsmRelocateApLoopEnd - AsmRelocateApLoopStart
  movdword [ebx + MP_ASSEMBLY_ADDRESS_MAP.ModeTransitionOffset], 
Flat32Start - RendezvousFunnelProcStart
-movdword [ebx + MP_ASSEMBLY_ADDRESS_MAP.SwitchToRealSize], 
SwitchToRealProcEnd - SwitchToRealProcStart
-movdword [ebx + MP_ASSEMBLY_ADDRESS_MAP.SwitchToRealOffset], 
SwitchToRealProcStart - RendezvousFunnelProcStart
  movdword [ebx + MP_ASSEMBLY_ADDRESS_MAP.SwitchToRealNoNxOffset], 
SwitchToRealProcStart - Flat32Start
  movdword [ebx + 
MP_ASSEMBLY_ADDRESS_MAP.SwitchToRealPM16ModeOffset], 0
  movdword [ebx + 
MP_ASSEMBLY_ADDRESS_MAP.SwitchToRealPM16ModeSize], 0
diff --git a/UefiCpuPkg/Library/MpInitLib/MpEqu.inc 
b/UefiCpuPkg/Library/MpInitLib/MpEqu.inc
index aba53f5720..1cc071cf7b 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpEqu.inc
+++ b/UefiCpuPkg/Library/MpInitLib/MpEqu.inc
@@ -1,5 +1,5 @@
  
;-- 
;
-; Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
+; Copyright (c) 2015 - 2022, Intel Corporation. All rights reserved.
  ; SPDX-License-Identifier: BSD-2-Clause-Patent
  ;
  ; Module Name:
@@ -27,8 +27,6 @@ struc MP_ASSEMBLY_ADDRESS_MAP
.RelocateApLoopFuncAddress CTYPE_UINTN 1
.RelocateApLoopFuncSizeCTYPE_UINTN 1
.ModeTransitionOffset  CTYPE_UINTN 1
-  .SwitchToRealSize  CTYPE_UINTN 1
-  .SwitchToRealOffsetCTYPE_UINTN 1
.SwitchToRealNoNxOffsetCTYPE_UINTN 1
.SwitchToRealPM16ModeOffsetCTYPE_UINTN 1
.SwitchToRealPM16ModeSize  CTYPE_UINTN 1
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index d761bdc487..aa0eb9a70b 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -936,8 +936,7 @@ FillExchangeInfoData (
// EfiBootServicesCode to avoid page fault if NX memory protection is 
enabled.
//
if (CpuMpData->WakeupBufferHigh != 0) {
-Size = CpuMpData->AddressMap.RendezvousFunnelSize +
-   CpuMpData->AddressMap.SwitchToRealSize -
+Size = CpuMpData->AddressMap.RendezvousFunnelSize -
 CpuMpData->AddressMap.ModeTransitionOffset;
  CopyMem (
(VOID *)CpuMpData->WakeupBufferHigh,
@@ -991,8 +990,7 @@ BackupAndPrepareWakeupBuffer (
CopyMem (
  (VOID 

Re: [edk2-devel] [PATCH] OvmfPkg: Make an Ia32/X64 hybrid build work with SEV

[Lendacky, Thomas via groups.io]

Explicitly adding Liming to the To: line for visibility.

Thanks,
Tom

On 5/17/22 11:29, Ard Biesheuvel wrote:

On Tue, 17 May 2022 at 18:26, Tom Lendacky  wrote:


On 5/16/22 15:24, Lendacky, Thomas via groups.io wrote:

The BaseMemEncryptSevLib functionality was updated to rely on the use of
the OVMF/SEV workarea to check for SEV guests. However, this area is only
updated when running the X64 OVMF build, not the hybrid Ia32/X64 build.
Base SEV support is allowed under the Ia32/X64 build, but it now fails
to boot as a result of the change.

Update the ResetVector code to check for SEV features when built for
32-bit mode, not just 64-bit mode (requiring updates to both the Ia32
and Ia32X64 fdf files).


So this is a regression and it would be great if it could be applied to
the 202205 release. Can folks take a look and make sure it looks safe to
them for applying during hard feature freeze?

If it's ok to be applied now, is there a particular process for applying
this during hard freeze?



For the change itself:

Acked-by: Ard Biesheuvel 

and I am fine with taking this during hard freeze, but I'll defer to
Liming to make the final call.







Fixes: f1d1c337e7c0575da7fd248b2dd9cffc755940df
Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Michael Roth 
Cc: Min Xu 
Signed-off-by: Tom Lendacky 
---
   OvmfPkg/OvmfPkgIa32.fdf   | 11 +++
   OvmfPkg/OvmfPkgIa32X64.fdf|  8 +++
   OvmfPkg/OvmfPkgX64.fdf|  3 +-
   OvmfPkg/ResetVector/Ia32/AmdSev.asm   |  4 ++
   OvmfPkg/ResetVector/Main.asm  |  6 ++
   OvmfPkg/ResetVector/ResetVector.nasmb | 72 ++--
   6 files changed, 67 insertions(+), 37 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 3ab1755749d4..57d13b7130bc 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -76,6 +76,9 @@ [FD.MEMFD]
   0x007000|0x001000
   
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize

+0x008000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize
+
   0x01|0x01
   
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize

@@ -87,6 +90,14 @@ [FD.MEMFD]
   
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
   FV = DXEFV

+##
+# Set the SEV-ES specific work area PCDs (used for all forms of SEV since the
+# the SEV STATUS MSR is now saved in the work area)
+#
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) +  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+##
+
   


   [FV.SECFV]
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index e1638fa6ea38..ccde366887a9 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -90,6 +90,14 @@ [FD.MEMFD]
   
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
   FV = DXEFV

+##
+# Set the SEV-ES specific work area PCDs (used for all forms of SEV since the
+# the SEV STATUS MSR is now saved in the work area)
+#
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) +  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+##
+
   


   [FV.SECFV]
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index aa9a83032d9b..438806fba8f1 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -106,7 +106,8 @@ [FD.MEMFD]
   FV = DXEFV

   
##
-# Set the SEV-ES specific work area PCDs
+# Set the SEV-ES specific work area PCDs (used for all forms of SEV since the
+# the SEV STATUS MSR is now saved in the work area)
   #
   SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS

[edk2-devel] [PATCH] OvmfPkg: Make an Ia32/X64 hybrid build work with SEV

[Lendacky, Thomas via groups.io]

The BaseMemEncryptSevLib functionality was updated to rely on the use of
the OVMF/SEV workarea to check for SEV guests. However, this area is only
updated when running the X64 OVMF build, not the hybrid Ia32/X64 build.
Base SEV support is allowed under the Ia32/X64 build, but it now fails
to boot as a result of the change.

Update the ResetVector code to check for SEV features when built for
32-bit mode, not just 64-bit mode (requiring updates to both the Ia32
and Ia32X64 fdf files).

Fixes: f1d1c337e7c0575da7fd248b2dd9cffc755940df
Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Michael Roth 
Cc: Min Xu 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgIa32.fdf   | 11 +++
 OvmfPkg/OvmfPkgIa32X64.fdf|  8 +++
 OvmfPkg/OvmfPkgX64.fdf|  3 +-
 OvmfPkg/ResetVector/Ia32/AmdSev.asm   |  4 ++
 OvmfPkg/ResetVector/Main.asm  |  6 ++
 OvmfPkg/ResetVector/ResetVector.nasmb | 72 ++--
 6 files changed, 67 insertions(+), 37 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 3ab1755749d4..57d13b7130bc 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -76,6 +76,9 @@ [FD.MEMFD]
 0x007000|0x001000
 
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
 
+0x008000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize
+
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
@@ -87,6 +90,14 @@ [FD.MEMFD]
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
 FV = DXEFV
 
+##
+# Set the SEV-ES specific work area PCDs (used for all forms of SEV since the
+# the SEV STATUS MSR is now saved in the work area)
+#
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) +  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+##
+
 

 
 [FV.SECFV]
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index e1638fa6ea38..ccde366887a9 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -90,6 +90,14 @@ [FD.MEMFD]
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
 FV = DXEFV
 
+##
+# Set the SEV-ES specific work area PCDs (used for all forms of SEV since the
+# the SEV STATUS MSR is now saved in the work area)
+#
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) +  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
+##
+
 

 
 [FV.SECFV]
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index aa9a83032d9b..438806fba8f1 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -106,7 +106,8 @@ [FD.MEMFD]
 FV = DXEFV
 
 
##
-# Set the SEV-ES specific work area PCDs
+# Set the SEV-ES specific work area PCDs (used for all forms of SEV since the
+# the SEV STATUS MSR is now saved in the work area)
 #
 SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase = $(MEMFD_BASE_ADDRESS) +  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase + 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
 SET gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize = 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaSize - 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfConfidentialComputingWorkAreaHeader
diff --git a/OvmfPkg/ResetVector/Ia32/AmdSev.asm 
b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
index 864d68385342..9350b0406833 100644
--- a/OvmfPkg/ResetVector/Ia32/AmdSev.asm
+++ b/OvmfPkg/ResetVector/Ia32/AmdSev.asm
@@ -150,6 +150,8 @@ BITS32
 SevEsUnexpectedRespTerminate:
 TerminateVmgExitTERM_UNEXPECTED_RESP_CODE
 
+%ifdef ARCH_X64
+
 ; If SEV-ES is enabled then initialize and make the GHCB page shared
 SevClearPageEncMaskForGhcbPage:
 ; Check 

Re: [edk2-devel] [PATCH 07/14] OvmfPkg: Add PCD and DEFINEs for Lazy Accept page.

[Lendacky, Thomas via groups.io]

On 6/16/22 00:51, Gerd Hoffmann wrote:

   Hi,


Tom Lendacky's suggestion for SEV-SNP is to pre-accept all memory under
4GB to make all that complexity go away. Only this approach worked in my
own testing. With the MMIO hole it's just validating 3GB of memory.

Accepting all memory under 4GB will make the things much simpler. In this way I 
think the accept-on-demand maybe not needed.
A question: is there some performance impact when accepting all memory under 
4GB?


That would certainly be easiest when it is acceptable from a performance
point of view.  Will also simplify the code because you don't have to
split the low memory block into accepted/unaccepted parts.

It'll be 3G (-machine pc) or 2G (-machine q35) of memory.
Is it possible to accept gigabyte pages btw?


+Ashish/Mike - I thought I had added them earlier...

SNP supports 4K and 2MB. However, SNP can support multiple pages in a 
single Page State Change GHCB request. This might be better than having to 
exit once for every on-demand page.


Thanks,
Tom



And, yes, this might be enough that accept-on-demand is not needed any
more.

take care,
   Gerd




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90548): https://edk2.groups.io/g/devel/message/90548
Mute This Topic: https://groups.io/mt/91570202/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 07/14] OvmfPkg: Add PCD and DEFINEs for Lazy Accept page.

[Lendacky, Thomas via groups.io]

On 6/16/22 11:44, Dionna Amalie Glaze wrote:

A question: is there some performance impact when accepting all memory under 
4GB?


On SEV-SNP, we accept the HOBs 0-0xA000 and 0x10_-0xC00_,
which takes a couple seconds, which is non-negligible.


Are you possibly including the memory pinning time (that happens in the 
hypervisor before the guest is started) in your measurement?


For example, I added from RDTSCP instructions in before and after the 
calls to MemEncryptSevSnpPreValidateSystemRam() and got:


*** DEBUG: SEC PreValidating RAM from 82 to 171
*** DEBUG: TSC1=3057966080, TSC2=3070503712, delta = 12537632
*** DEBUG: PEI PreValidating RAM from 0 to A
*** DEBUG: TSC1=3430088800, TSC2=3432589504, delta = 2500704
*** DEBUG: PEI PreValidating RAM from 10 to 8000
*** DEBUG: TSC1=3436557536, TSC2=3496324336, delta = 59766800


This is for 2GB (0x8000) of RAM. If I've done my calculations 
correctly for a 1600MHz TSC, that comes out to about 45 milliseconds.


Thanks,
Tom


For VMs that want to boot very fast and still have access to a lot of
memory in the long run (e.g., a UEFI app as an enclave or sandbox), I
admit it's not my favorite solution.
That being said, supporting unaccepted memory in the guest means that
the 4GB solution doesn't preclude an accept-on-demand solution in the
future in the case that there is demand.




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90553): https://edk2.groups.io/g/devel/message/90553
Mute This Topic: https://groups.io/mt/91570202/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V12 33/47] OvmfPkg: Update Sec to support Tdx

[Lendacky, Thomas via groups.io]

On 4/15/22 19:13, Xu, Min M wrote:

On April 16, 2022 4:05 AM, Tom Lendacky wrote:

   #define SEC_IDT_ENTRY_COUNT  34
@@ -738,6 +737,20 @@ SecCoreStartupWithStack (
 UINT32Index;
 volatile UINT8*Table;

+ #if defined (TDX_GUEST_SUPPORTED)
+  if (TdIsEnabled ()) {


I wish I had caught this earlier, but this patch breaks SEV-ES support.
TdIsEnabled() uses the CPUID instruction. At this point, exception handling is
not established and a CPUID instruction will generate a #VC and cause the
booting guest to crash.


Sorry for the broken.


That is why the SevEsIsEnabled() function checks the work area to determine
if SEV-ES is supported. In the early boot code we established a temporary
#VC handler to specifically handle CPUID and then set the work area
indicator that SEV-ES is enabled.

I think you'll need to do something similar for this area. Haven't you already
set the workarea from calling InitTdx before this point?

TDX has set the workarea in ResetVector.
I am working on a patch-set (now it is v2) which is to fix the issues caused by 
TdIsEnabled. Please see https://edk2.groups.io/g/devel/message/88916
This patch-set introduce CcProbe() which checks the Ovmf work area to return 
the guest type.
In the next version CcProbe will be called instead of TdIsEnabled in SecMain.c.

Please help to review the above patch-set so that there will not be more broken 
in the future.


I'll test out that patchset on Monday. Thanks!

Tom



Thanks much
Min



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88963): https://edk2.groups.io/g/devel/message/88963
Mute This Topic: https://groups.io/mt/90121245/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V12 42/47] OvmfPkg: Add TdxDxe driver

[Lendacky, Thomas via groups.io]

On 4/15/22 20:57, Xu, Min M wrote:

On April 16, 2022 4:52 AM, Lendacky, Thomas wrote:


Unfortunately, this driver also breaks SEV-ES. I bypassed the TDX code in the
SEC library, but then hit an issue because this driver is loaded before the
AmdSevDxe driver. The AmdSevDxe driver performs a
MemEncryptSevClearMmioPageEncMask() call against the
PcdPciExpressBaseAddress range to mark it shared/unencrypted. However,
the TdxDxe driver is loaded before the AmdSevDxe driver, and it appears the
dependencies result in an MMIO being performed to an address in the
PcdPciExpressBaseAddress range. Since the range has not been marked
shared/unencrypted, the #VC handler terminates the guest for trying to do
MMIO to an encrypted region.


I carefully check the code TdxDxeEntryPoint@TdxDxe.c.
If the working guest is NOT td guest, before it returns, it just does below:
1. check if the GuidHob exists
2. Set PcdOvmfHostBridgePciDevId with the information in the GuidHob

SetMmioSharedBit() is called if the working guest is Td guest. So if it is sev 
guest, SetMmioSharedBit will not be called.

I don't have a SEV-ES in hand. Can you help to add some debug information in 
TdxDxe to see what the last code before the exception is triggered?


I don't think it is anything in your code, I think it is another library 
that is being loaded based on dependencies. I put a DEBUG statement at the 
start of TdxDxeEntryPoint() and never see the output before the crash.




BTW, have you tried to load AmdSev.inf before TdxDxe.inf? I tried it in my TDX 
guest and it works fine.


Yes, moving AmdSevDxe.inf ahead of TdxDxe.inf does fix this issue. Do you 
want to submit the patch or do you want me to?


Thanks,
Tom



Thanks
Min



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#88966): https://edk2.groups.io/g/devel/message/88966
Mute This Topic: https://groups.io/mt/90495224/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3 1/7] MdePkg: Add CC_GUEST_TYPE in ConfidentialComputingGuestAttr.h

[Lendacky, Thomas via groups.io]

On 4/16/22 22:01, Min Xu wrote:

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

The confidential computing guest type (GUEST_TYPE) was defined in
OvmfPkg/Include/WorkArea.h. Now it is to be moved to
MdePkg/Include/ConfidentialComputingGuestAttr.h and renamed as
CC_GUEST_TYPE.

There are 2 reasons for this change.
1. CC_GUEST_TYPE is a generic definition and will be used in CcProbeLib
which is defined in MdePkg.
2. Based on the latest edk2 coding style:
  - First character should be upper case
  - Must contain lower case characters
  - No white space characters
  - Global variable name must start with a 'g'

As the first step CC_GUEST_TYPE is defined in this patch. In the
next patch GUEST_TYPE will be deleted. This is to make sure the
bisect work correctly.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
  MdePkg/Include/ConfidentialComputingGuestAttr.h | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/ConfidentialComputingGuestAttr.h 
b/MdePkg/Include/ConfidentialComputingGuestAttr.h
index dd2541c6dcdf..9e9424a01559 100644
--- a/MdePkg/Include/ConfidentialComputingGuestAttr.h
+++ b/MdePkg/Include/ConfidentialComputingGuestAttr.h
@@ -1,5 +1,5 @@
  /** @file
-Definitions for Confidential Computing Attribute
+Definitions for Confidential Computing Guest Attributes
  
  Copyright (c) 2021 AMD Inc. All rights reserved.

  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -9,6 +9,15 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
  #ifndef CONFIDENTIAL_COMPUTING_GUEST_ATTR_H_
  #define CONFIDENTIAL_COMPUTING_GUEST_ATTR_H_
  
+//

+// Confidential computing guest type
+//
+typedef enum {
+  CCGuestTypeNonEncrypted = 0,
+  CCGuestTypeAmdSev,
+  CCGuestTypeIntelTdx,
+} CC_GUEST_TYPE;


Should these be CcGuest... ? The precedent seems to be use lowercase even 
when the the acronym is uppercase, e.g. PCI => Pci, GHCB => Ghcb, SMBIOS 
=> SmBios, NVME => Nvme, etc.


Thanks,
Tom


+
  typedef enum {
/* The guest is running with memory encryption disabled. */
CCAttrNotEncrypted = 0,



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89015): https://edk2.groups.io/g/devel/message/89015
Mute This Topic: https://groups.io/mt/90516972/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V12 42/47] OvmfPkg: Add TdxDxe driver

[Lendacky, Thomas via groups.io]

On 4/16/22 19:56, Xu, Min M wrote:

On April 16, 2022 11:09 PM, Lendacky, Thomas wrote:

On 4/15/22 20:57, Xu, Min M wrote:

On April 16, 2022 4:52 AM, Lendacky, Thomas wrote:


Unfortunately, this driver also breaks SEV-ES. I bypassed the TDX
code in the SEC library, but then hit an issue because this driver is
loaded before the AmdSevDxe driver. The AmdSevDxe driver performs a
MemEncryptSevClearMmioPageEncMask() call against the
PcdPciExpressBaseAddress range to mark it shared/unencrypted.
However, the TdxDxe driver is loaded before the AmdSevDxe driver, and
it appears the dependencies result in an MMIO being performed to an
address in the PcdPciExpressBaseAddress range. Since the range has
not been marked shared/unencrypted, the #VC handler terminates the
guest for trying to do MMIO to an encrypted region.


I carefully check the code TdxDxeEntryPoint@TdxDxe.c.
If the working guest is NOT td guest, before it returns, it just does below:
1. check if the GuidHob exists
2. Set PcdOvmfHostBridgePciDevId with the information in the GuidHob

SetMmioSharedBit() is called if the working guest is Td guest. So if it is sev

guest, SetMmioSharedBit will not be called.


I don't have a SEV-ES in hand. Can you help to add some debug

information in TdxDxe to see what the last code before the exception is
triggered?

I don't think it is anything in your code, I think it is another library that is
being loaded based on dependencies. I put a DEBUG statement at the start
of TdxDxeEntryPoint() and never see the output before the crash.


I check the libraries loaded by TdxDxe and AmdSev and find that they load 
different PciLib.
TdxDxe load PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf.
AmdSev load PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf.

PciLib is consumed by DxeAcpiTimerLib. In the 
AcpiTimerLibConstructor@DxeAcpiTimerLib there is below code:
mAcpiTimerIoAddr = (PciRead32 (Pmba) & ~PMBA_RTE) + ACPI_TIMER_OFFSET;

I think this is the root cause of the exception.

There are 2 options to fix this issue.
1. Load AmdSev before TdxDxe
2. Make TdxDxe to import BasePciLibCf8.inf instead of DxePciLibI440FxQ35.inf 
(just like AmdSev)

I tried above 2 options in my Tdx guest and both work.
Tom, Can you help to try above 2 options in your SEV guest to see whether they 
work?





BTW, have you tried to load AmdSev.inf before TdxDxe.inf? I tried it in my

TDX guest and it works fine.

Yes, moving AmdSevDxe.inf ahead of TdxDxe.inf does fix this issue. Do you
want to submit the patch or do you want me to?


If above option 2 works, I prefer this option to fix the issue. Because there 
is still potential issues in option 1. I will submit the patch.


I added the same library class override to TdxDxe and, yes, option 2 worked.

Thanks,
Tom



Thanks
Min



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89014): https://edk2.groups.io/g/devel/message/89014
Mute This Topic: https://groups.io/mt/90495224/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V3 0/7] Introduce CcProbe in MdePkg

[Lendacky, Thomas via groups.io]

On 4/16/22 22:01, Min Xu wrote:

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

Bad IO performance in SEC phase is observed after TDX features was
introduced. (after commit b6b2de884864 - "MdePkg: Support mmio for
Tdx guest in BaseIoLibIntrinsic").

This is because IsTdxGuest() will be called in each MMIO operation.
It is trying to cache the result of the probe in the efi data segment.
However, that doesn't work in SEC, because the data segment is read only
(so the write seems to succeed but a read will always return the
original value), leading to us calling TdIsEnabled() check for every
mmio we do, which is causing the slowdown because it's very expensive.

CcProbe is introduced in this patch-set. It is called in
BaseIoLibIntrinsicSev instead of IsTdxGuest. There are 2 versions of
the CcProbeLib. Null instance of CcProbe always returns
CCGuestTypeNonEncrypted. Its OvmfPkg version checks the Ovmf work area
and returns the CC guest type.

In this patch-set another issue is fixed with CcProbe as well. If the
working guest is SEV and in the beginning of SecMain.c TdIsEnabled()
was called. At this point, exception handling is not established and
a CPUID instruction will generate a #VC and cause the booting SEV guest
to crash. Patch #7 is to fix this broken.

Code is at: https://github.com/mxu9/edk2/tree/cc_probe.v3

v3 changes:
  - Fix the broken issue in SEV guest at SecMain.c. Please refer to
Patch #7.

v2 changes:
  - Rename TdProbe to CcProbe to make the lib work for Confidential
Computing guests.
  - Rename the GUEST_TYPE to CC_GUEST_TYPE and move it from
WorkArea.h@OvmfPkg to ConfidentialComputingGuestAttr.h@MdePkg.
This is because CcProbeLib is designed to return the CC Guest
type and the lib is located at MdePkg.
  - Rename the CC_GUEST_TYPE's fields name to Camel style. See the
commit message in patch #1.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 


After working around the PCI library issue (for which Min will be 
submitting a patch), this series boots successfully for SEV, SEV-ES and 
SEV-SNP when built as X64. I documented the issue that SEV has with 
Ia32X64 in patch 5/7 and I'll have to decide what to do there. So...


Reviewed-by: Tom Lendacky 



Min Xu (7):
   MdePkg: Add CC_GUEST_TYPE in ConfidentialComputingGuestAttr.h
   OvmfPkg: Replace GUEST_TYPE with CC_GUEST_TYPE
   MdePkg: Add CcProbeLib
   OvmfPkg: Add CcProbeLib
   OvmfPkg: Add CcProbeLib in *.dsc
   MdePkg: Probe Cc guest in BaseIoLibIntrinsicSev
   OvmfPkg: Call CcProbe in SecMain.c instead of TsIsEnabled

  .../Include/ConfidentialComputingGuestAttr.h  | 11 ++-
  MdePkg/Include/Library/CcProbeLib.h   | 26 
  .../BaseIoLibIntrinsicSev.inf |  1 +
  .../BaseIoLibIntrinsic/IoLibInternalTdx.c | 13 ++--
  .../Library/CcProbeLibNull/CcProbeLibNull.c   | 26 
  .../Library/CcProbeLibNull/CcProbeLibNull.inf | 21 +
  MdePkg/MdePkg.dec |  5 +++
  MdePkg/MdePkg.dsc |  1 +
  OvmfPkg/AmdSev/AmdSevX64.dsc  |  1 +
  OvmfPkg/Bhyve/BhyveX64.dsc|  1 +
  OvmfPkg/CloudHv/CloudHvX64.dsc|  1 +
  OvmfPkg/Include/WorkArea.h|  9 +-
  OvmfPkg/IntelTdx/IntelTdxX64.dsc  |  1 +
  OvmfPkg/IntelTdx/Sec/SecMain.c|  6 ++--
  OvmfPkg/IntelTdx/Sec/SecMain.inf  |  1 +
  .../PeiMemEncryptSevLibInternal.c |  2 +-
  .../SecMemEncryptSevLibInternal.c |  2 +-
  OvmfPkg/Library/CcProbeLib/CcProbeLib.c   | 31 +++
  OvmfPkg/Library/CcProbeLib/CcProbeLib.inf | 25 +++
  OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPei.c   |  2 +-
  OvmfPkg/Microvm/MicrovmX64.dsc|  1 +
  OvmfPkg/OvmfPkgIa32.dsc   |  1 +
  OvmfPkg/OvmfPkgIa32X64.dsc|  1 +
  OvmfPkg/OvmfPkgX64.dsc|  1 +
  OvmfPkg/OvmfXen.dsc   |  1 +
  OvmfPkg/Sec/AmdSev.c  |  2 +-
  OvmfPkg/Sec/SecMain.c |  5 +--
  OvmfPkg/Sec/SecMain.inf   |  1 +
  28 files changed, 170 insertions(+), 29 deletions(-)
  create mode 100644 MdePkg/Include/Library/CcProbeLib.h
  create mode 100644 MdePkg/Library/CcProbeLibNull/CcProbeLibNull.c
  create mode 100644 MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
  create mode 100644 OvmfPkg/Library/CcProbeLib/CcProbeLib.c
  create mode 100644 OvmfPkg/Library/CcProbeLib/CcProbeLib.inf




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89021): https://edk2.groups.io/g/devel/message/89021
Mute This Topic: https://groups.io/mt/90516971/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 

Re: [edk2-devel] [PATCH V3 5/7] OvmfPkg: Add CcProbeLib in *.dsc

[Lendacky, Thomas via groups.io]

On 4/16/22 22:01, Min Xu wrote:

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

CcProbeLib is imported in BaseIoLibIntrinsicSev.
OvmfPkg/Library/CcProbeLib is the OvmfPkg version which checks
OvmfWorkArea to return the Cc guest type. It is included
in OvmfPkgX64.dsc and IntelTdx/IntelTdxX64.dsc.


SEV support (as opposed to SEV-ES and SEV-SNP) builds and runs with
OvmfPkgIa32X64.dsc, so that needs updating. It also builds with
OvmfPkgIa32.dsc, but is not expected to run successfully in only the
32-bit variant - and since there is no work area in the fdf file that
can stay as the NULL library.

However, when testing the Ia32X64 variant, I found that commits:

63c50d3ff285 ("OvmfPkg/ResetVector: cache the SEV status MSR value in workarea")
f1d1c337e7c0 ("OvmfPkg/BaseMemEncryptLib: use the SEV_STATUS MSR value from 
workarea")

actually broke the Ia32X64 variant running under SEV, so we (AMD)
will need to fix that - unless we just say that now SEV requires
the X64-only build since both SEV-ES and SEV-SNP require that.

Thanks,
Tom



Other .dsc include the MdePkg/Library/CcProbeLibNull because Cc guest
is not supported in those projects.

Cc: James Bottomley 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
  OvmfPkg/AmdSev/AmdSevX64.dsc | 1 +
  OvmfPkg/Bhyve/BhyveX64.dsc   | 1 +
  OvmfPkg/CloudHv/CloudHvX64.dsc   | 1 +
  OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 +
  OvmfPkg/Microvm/MicrovmX64.dsc   | 1 +
  OvmfPkg/OvmfPkgIa32.dsc  | 1 +
  OvmfPkg/OvmfPkgIa32X64.dsc   | 1 +
  OvmfPkg/OvmfPkgX64.dsc   | 1 +
  OvmfPkg/OvmfXen.dsc  | 1 +
  9 files changed, 9 insertions(+)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index fcdc3efab204..1c088f25fa4b 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -149,6 +149,7 @@
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index e1b6b8e15f36..a8fa4d38ab60 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -146,6 +146,7 @@
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index 20f3bc340807..d1c85f60c768 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -158,6 +158,7 @@
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|MdePkg/Library/CcProbeLibNull/CcProbeLibNull.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 245155d41b30..73a6c30096a8 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -135,6 +135,7 @@
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
+  CcProbeLib|OvmfPkg/Library/CcProbeLib/CcProbeLib.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf

OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 59580ccd4691..c9c843e116a9 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -156,6 +156,7 @@
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf

Re: [edk2-devel] [PATCH V12 14/47] UefiCpuPkg: Enable Tdx support in MpInitLib

[Lendacky, Thomas via groups.io]

On 3/29/22 18:46, Min Xu wrote:

RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429

In TDVF BSP and APs are simplified. BSP is the vCPU-0, while the others
are treated as APs.

So MP intialization is rather simple. ApWorker is not supported, BSP is
always the working processor, while the APs are just in a
wait-for-precedure state.

Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
Signed-off-by: Min Xu 
---
  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |   3 +
  UefiCpuPkg/Library/MpInitLib/MpIntelTdx.h |  69 
  UefiCpuPkg/Library/MpInitLib/MpLib.c  |  63 ++-
  UefiCpuPkg/Library/MpInitLib/MpLibTdx.c   | 106 ++
  UefiCpuPkg/Library/MpInitLib/MpLibTdxNull.c   |  69 
  UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf |   3 +
  6 files changed, 308 insertions(+), 5 deletions(-)
  create mode 100644 UefiCpuPkg/Library/MpInitLib/MpIntelTdx.h
  create mode 100644 UefiCpuPkg/Library/MpInitLib/MpLibTdx.c
  create mode 100644 UefiCpuPkg/Library/MpInitLib/MpLibTdxNull.c




//
@@ -2367,6 +2385,11 @@ MpInitLibWhoAmI (
  return EFI_INVALID_PARAMETER;
}
  
+  if (CC_GUEST_IS_TDX (PcdGet64 (PcdConfidentialComputingGuestAttr))) {

+*ProcessorNumber = 0;
+return EFI_SUCCESS;
+  }
+


I've narrowed down this change as causing issues when booting multiple 
vCPU guests (regular and SEV). This issues consist of EfiAcquireLock() / 
EfiReleaseLock() ASSERTS and TPL level ASSERTS that occur during 
ExitBootServices when the APs are being parked by RelocateApLoop(). The 
PCD accesses use locking which is not SMP safe. I believe PCD calls are 
not supposed to be issued by APs because of this (or at least not APs 
executing in parallel).


This check is spread throughout the MpLib code and I didn't look to see 
how many of those calls can be done by an AP. I think the PCD usage can be 
reduced to getting the PcdConfidentialComputingGuestAttr value at init and 
caching it in a STATIC variable, but I would feel better if @Min Xu could 
verify that and submit a patch accordingly. Otherwise, maybe this TDX 
guest setting could be added to the CpuMpData (similar to the 
SevEsIsEnabled, etc. fields).


A future cleanup could cache PcdConfidentialComputingGuestAttr in 
CpuMpData and use CC_GUEST_IS_XXX() calls against that.


Thanks,
Tom


CpuMpData = GetCpuMpData ();
  
return GetProcessorNumber (CpuMpData, ProcessorNumber);



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89374): https://edk2.groups.io/g/devel/message/89374
Mute This Topic: https://groups.io/mt/90121206/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V7 36/37] UefiCpuPkg: Setting initial-count register as the last step

[Lendacky, Thomas via groups.io]

On 2/28/22 01:21, Min Xu via groups.io wrote:

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

Per SDM, changing the mode of APIC timer (from one-shot to periodic or
vice versa) by writing to the timer LVT entry does not start the timer.
To start the timer, it is necessary to write to the initial-count
register.

If initial-count is wrote before mode change, it's possible that timer
expired before the mode change. Thus failing the periodic mode.


I'm replying to this patch since I can't find patch V12 46/47 anywhere in
my email.

I've bisected a regression in the Linux kernel to this patch when an
SEV-SNP guest is booted. The following message is issued in the kernel for
every AP being brought online:

APIC: Stale IRR: 
,,,,,,,0020 ISR: 
,,,,,,,

Possibly a timing issue involving the mode switch with the interrupt
unmasked. If I leave the interrupt masked and only un-mask it
after the programming of the init-count, then the message goes away.

Thoughts?

Thanks,
Tom



Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Anthony Perard 
Cc: Julien Grall 
Cc: Eric Dong 
Cc: Ray Ni 
Acked-by: Gerd Hoffmann 
Signed-off-by: Min Xu 
---
  .../Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c| 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c 
b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
index 2d17177df12b..f26d9c93894f 100644
--- a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
+++ b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c
@@ -967,11 +967,6 @@ InitializeApicTimer (
//
InitializeLocalApicSoftwareEnable (TRUE);
  
-  //

-  // Program init-count register.
-  //
-  WriteLocalApicReg (XAPIC_TIMER_INIT_COUNT_OFFSET, InitCount);
-
if (DivideValue != 0) {
  ASSERT (DivideValue <= 128);
  ASSERT (DivideValue == GetPowerOfTwo32 ((UINT32)DivideValue));
@@ -996,6 +991,11 @@ InitializeApicTimer (
LvtTimer.Bits.Mask   = 0;
LvtTimer.Bits.Vector = Vector;
WriteLocalApicReg (XAPIC_LVT_TIMER_OFFSET, LvtTimer.Uint32);
+
+  //
+  // Program init-count register.
+  //
+  WriteLocalApicReg (XAPIC_TIMER_INIT_COUNT_OFFSET, InitCount);
  }
  
  /**



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89669): https://edk2.groups.io/g/devel/message/89669
Mute This Topic: https://groups.io/mt/89446188/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 0/6] Support 2 CpuMpPei/CpuDxe in One image

[Lendacky, Thomas via groups.io]

On 5/9/22 18:37, Xu, Min M wrote:

On May 10, 2022 1:30 AM, Tom Lendacky wrote:


On 5/9/22 07:44, Xu, Min M wrote:

Gerd & Tom
What are your comments about this patch-set?


Hi Min,

This appears to resolve the issue. I was able to boot a 64 vCPU guest in
legacy, SEV, SEV-ES and SEV-SNP modes without any asserts.

I'm assuming that you were able to see the ASSERTs on your end and
validate, too?


Yes. I enable a 4 vCPU legacy guest and can see the ASSERTs. But it appears in 
a random rate so it missed in the CI.


Yeah, with a low number of vCPUs, the crashes were random. When I upped 
the count to 64 vCPUs that could all run in parallel (running on an EPYC 
server box) it happened on (almost) every boot.


But glad that you were able to observe it and create this fix.

Thanks, Min!

Tom



Thanks
Min



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89661): https://edk2.groups.io/g/devel/message/89661
Mute This Topic: https://groups.io/mt/90946714/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 0/6] Support 2 CpuMpPei/CpuDxe in One image

[Lendacky, Thomas via groups.io]

On 5/9/22 18:37, Xu, Min M wrote:

On May 10, 2022 1:30 AM, Tom Lendacky wrote:


On 5/9/22 07:44, Xu, Min M wrote:

Gerd & Tom
What are your comments about this patch-set?


Hi Min,

This appears to resolve the issue. I was able to boot a 64 vCPU guest in
legacy, SEV, SEV-ES and SEV-SNP modes without any asserts.

I'm assuming that you were able to see the ASSERTs on your end and
validate, too?


Yes. I enable a 4 vCPU legacy guest and can see the ASSERTs. But it appears in 
a random rate so it missed in the CI.


Hmmm... I hadn't noticed it before, but I'm seeing the following message
from the Linux kernel for each AP being brought online:

APIC: Stale IRR: 
,,,,,,0001, ISR: 
,,,,,,,

Let me investigate this further to see where this regression was
introduced.

Thanks,
Tom



Thanks
Min



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89666): https://edk2.groups.io/g/devel/message/89666
Mute This Topic: https://groups.io/mt/90946714/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/4] Refactor MpInitLib

[Lendacky, Thomas via groups.io]

On 5/9/22 18:16, Ni, Ray wrote:

https://github.com/niruiyu/edk2/tree/refactormp<https://github.com/niruiyu/edk2/tree/refactormp


Thanks for the tree, Ray. I was able to build and test against legacy,
SEV, SEV-ES and SEV-SNP guests and found everything worked well.

I did notice a regression in the tree, un-related to your patches, when
booting an SEV-SNP guest. The following message appears for each AP:

APIC: Stale IRR: 
,,,,,,0001, ISR: 
,,,,,,,

So I'll start bisecting to see which commit introduced that.

Thanks,
Tom



thanks,
ray
--
*From:* devel@edk2.groups.io  on behalf of Lendacky, 
Thomas via groups.io 

*Sent:* Tuesday, May 10, 2022 5:39:51 AM
*To:* devel@edk2.groups.io ; Ni, Ray 
*Subject:* Re: [edk2-devel] [PATCH 0/4] Refactor MpInitLib
Hi Ray,

Do you have a public git tree with these patches that I can use to test
with? I'm having lots of problems pulling these patches out of my mail
client and applying them.

Thanks,
Tom

On 5/7/22 10:13, Ni, Ray via groups.io wrote:


Ray Ni (4):
    MpInitLib: Allocate code buffer for PEI phase
    MpInitLib: remove unneeded global ASM_PFX
    MpInitLib: Put SEV logic in separate file
    MpInitLib: Only allocate below 1MB memory for 16bit code

   UefiCpuPkg/Library/MpInitLib/AmdSev.c |   6 +-
   UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   |   2 +-
   .../Library/MpInitLib/Ia32/MpFuncs.nasm   |  11 +-
   UefiCpuPkg/Library/MpInitLib/MpEqu.inc    |   2 +-
   UefiCpuPkg/Library/MpInitLib/MpLib.c  |  99 +--
   UefiCpuPkg/Library/MpInitLib/MpLib.h  |   2 +-
   UefiCpuPkg/Library/MpInitLib/PeiMpLib.c   |  15 +-
   UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm  | 148 
   UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 167 +-
   9 files changed, 216 insertions(+), 236 deletions(-)










-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89663): https://edk2.groups.io/g/devel/message/89663
Mute This Topic: https://groups.io/mt/90954624/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/4] Refactor MpInitLib

[Lendacky, Thomas via groups.io]

On 5/10/22 09:44, Tom Lendacky wrote:

On 5/9/22 18:16, Ni, Ray wrote:
https://github.com/niruiyu/edk2/tree/refactormp<https://github.com/niruiyu/edk2/tree/refactormp 



Thanks for the tree, Ray. I was able to build and test against legacy,
SEV, SEV-ES and SEV-SNP guests and found everything worked well.

I did notice a regression in the tree, un-related to your patches, when
booting an SEV-SNP guest. The following message appears for each AP:

APIC: Stale IRR: 
,,,,,,0001, 
ISR: ,,,,,,,


So I'll start bisecting to see which commit introduced that.


This was introduced in the debug hack I needed to boot multiple vCPUs 
successfully (since Min's fix isn't in your tree, yet).


I hadn't noticed this in Min's MpLib fix, but after investigating I do see 
it now. I'll follow up with Min.


Thanks,
Tom



Thanks,
Tom



thanks,
ray
--
*From:* devel@edk2.groups.io  on behalf of 
Lendacky, Thomas via groups.io 

*Sent:* Tuesday, May 10, 2022 5:39:51 AM
*To:* devel@edk2.groups.io ; Ni, Ray 


*Subject:* Re: [edk2-devel] [PATCH 0/4] Refactor MpInitLib
Hi Ray,

Do you have a public git tree with these patches that I can use to test
with? I'm having lots of problems pulling these patches out of my mail
client and applying them.

Thanks,
Tom

On 5/7/22 10:13, Ni, Ray via groups.io wrote:


Ray Ni (4):
    MpInitLib: Allocate code buffer for PEI phase
    MpInitLib: remove unneeded global ASM_PFX
    MpInitLib: Put SEV logic in separate file
    MpInitLib: Only allocate below 1MB memory for 16bit code

   UefiCpuPkg/Library/MpInitLib/AmdSev.c |   6 +-
   UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   |   2 +-
   .../Library/MpInitLib/Ia32/MpFuncs.nasm   |  11 +-
   UefiCpuPkg/Library/MpInitLib/MpEqu.inc    |   2 +-
   UefiCpuPkg/Library/MpInitLib/MpLib.c  |  99 +--
   UefiCpuPkg/Library/MpInitLib/MpLib.h  |   2 +-
   UefiCpuPkg/Library/MpInitLib/PeiMpLib.c   |  15 +-
   UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm  | 148 
   UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 167 +-
   9 files changed, 216 insertions(+), 236 deletions(-)










-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89665): https://edk2.groups.io/g/devel/message/89665
Mute This Topic: https://groups.io/mt/90954624/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V7 36/37] UefiCpuPkg: Setting initial-count register as the last step

[Lendacky, Thomas via groups.io]

On 5/10/22 21:00, Xu, Min M wrote:

On May 11, 2022 4:30 AM, Tom Lendacky wrote:

On 2/28/22 01:21, Min Xu via groups.io wrote:

BZ: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3711data=05%7C01%7Cthomas.lendacky%40amd.com%7Cce8cd76e1b054fe277d808da32f20976%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637878312370633666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=C%2F0BMTV%2FoZdUxLwRbqzjNVdlMvEKfl20z6RwKeMzr2c%3Dreserved=0

Per SDM, changing the mode of APIC timer (from one-shot to periodic or
vice versa) by writing to the timer LVT entry does not start the timer.
To start the timer, it is necessary to write to the initial-count
register.

If initial-count is wrote before mode change, it's possible that timer
expired before the mode change. Thus failing the periodic mode.


I'm replying to this patch since I can't find patch V12 46/47 anywhere in my
email.

I've bisected a regression in the Linux kernel to this patch when an SEV-SNP
guest is booted. The following message is issued in the kernel for every AP
being brought online:

APIC: Stale IRR:
,,,,,,,000
00020 ISR:
,,,,,,,000
0

Possibly a timing issue involving the mode switch with the interrupt
unmasked. If I leave the interrupt masked and only un-mask it after the
programming of the init-count, then the message goes away.


Do you mean in InitializeApicTimer, it should follow below steps:
1. mask LvtTimer. (set LvtTimer.Bits.Mask = 1)
2. Do other stuff, including programing the init-count register.
3. un-mask LvtTimer (set LvtTimer.Bit.Mask = 0)


Yes, I believe so. I'm not an expert on the APIC timer, but that seems 
reasonable to me.


Thanks,
Tom



Thanks
Min




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89682): https://edk2.groups.io/g/devel/message/89682
Mute This Topic: https://groups.io/mt/89446188/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 0/6] Support 2 CpuMpPei/CpuDxe in One image

[Lendacky, Thomas via groups.io]

On 5/9/22 07:44, Xu, Min M wrote:

Gerd & Tom
What are your comments about this patch-set?


Hi Min,

This appears to resolve the issue. I was able to boot a 64 vCPU guest in 
legacy, SEV, SEV-ES and SEV-SNP modes without any asserts.


I'm assuming that you were able to see the ASSERTs on your end and 
validate, too?


Thanks,
Tom




-Original Message-
From: Xu, Min M 
Sent: Saturday, May 7, 2022 9:36 AM
To: devel@edk2.groups.io
Cc: Xu, Min M ; Dong, Eric ; Ni,
Ray ; Brijesh Singh ; Aktas,
Erdem ; James Bottomley ;
Yao, Jiewen ; Tom Lendacky
; Gerd Hoffmann 
Subject: [PATCH V2 0/6] Support 2 CpuMpPei/CpuDxe in One image

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

Above BZ reports an issue that commit 88da06ca triggers ASSERT in some
scenario. This patch-set is to fix this issue.

As commit 88da06ca describes TDVF BSP and APs are simplied and it can
simply use MpInitLibUp instead of MpInitLib. To achieve this goal, we
include 2 CpuMpPei/CpuDxe drivers in OvmfPkgX64 and IntelTdxX64. This is
done by setting different FILE_GUID to these drivers (of the same name). In
the other hand, we import a set of MpInitLibDepLib. These libs simply
depend on the PPI/Protocols. While these PPI/Protocols are installed
according to the guest type.

This patch-set is a replacement of
https://edk2.groups.io/g/devel/message/89381
  - https://edk2.groups.io/g/devel/message/89382
  - https://edk2.groups.io/g/devel/message/89455
  - https://edk2.groups.io/g/devel/message/89522
  - https://edk2.groups.io/g/devel/message/89535

The code is at: https://github.com/mxu9/edk2/tree/Rework-MpInitLib.v2

v2 changes:
  - Remove the un-used FILE_GUID definitions.
  - Delete un-used EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST in
DispatchTable.
  - Add more comments.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Gerd Hoffmann 
Signed-off-by: Min Xu 

Min M Xu (4):
   UefiCpuPkg: Revert "UefiCpuPkg: Enable Tdx support in MpInitLib"
   OvmfPkg/Sec: Install MpInitLibDepLib PPIs in SecMain.c
   OvmfPkg/TdxDxe: Install MpInitLibDepLib protocols
   OvmfPkg: Enable 2 different CpuMpPei and CpuDxe drivers

Min Xu (2):
   OvmfPkg: Add MpInitLibDepLib related PPI/Protocol definitions
   OvmfPkg: Add MpInitLibDepLib

  OvmfPkg/Include/Ppi/MpInitLibDep.h|  28 +
  .../Include/Protocol/MpInitLibDepProtocols.h  |  28 +
  OvmfPkg/IntelTdx/IntelTdxX64.dsc  |  30 -
  OvmfPkg/IntelTdx/IntelTdxX64.fdf  |   3 +
  .../MpInitLibDepLib/DxeMpInitLibMpDepLib.inf  |  27
+  .../MpInitLibDepLib/DxeMpInitLibUpDepLib.inf  |  27
+  .../Library/MpInitLibDepLib/MpInitLibDepLib.c |  23
  .../MpInitLibDepLib/PeiMpInitLibMpDepLib.inf  |  27
+  .../MpInitLibDepLib/PeiMpInitLibUpDepLib.inf  |  27 +
  OvmfPkg/OvmfPkg.dec   |   5 +
  OvmfPkg/OvmfPkgX64.dsc|  55 -
  OvmfPkg/OvmfPkgX64.fdf|   4 +
  OvmfPkg/Sec/SecMain.c |  34 +-
  OvmfPkg/Sec/SecMain.inf   |   2 +
  OvmfPkg/TdxDxe/TdxDxe.c   |  22 +++-
  OvmfPkg/TdxDxe/TdxDxe.inf |   2 +
  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |   3 -
  UefiCpuPkg/Library/MpInitLib/MpIntelTdx.h |  69 
  UefiCpuPkg/Library/MpInitLib/MpLib.c  |  63 +--
  UefiCpuPkg/Library/MpInitLib/MpLibTdx.c   | 106 --
  UefiCpuPkg/Library/MpInitLib/MpLibTdxNull.c   |  69 
  UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf |   3 -
  22 files changed, 343 insertions(+), 314 deletions(-)  create mode 100644
OvmfPkg/Include/Ppi/MpInitLibDep.h
  create mode 100644 OvmfPkg/Include/Protocol/MpInitLibDepProtocols.h
  create mode 100644
OvmfPkg/Library/MpInitLibDepLib/DxeMpInitLibMpDepLib.inf
  create mode 100644
OvmfPkg/Library/MpInitLibDepLib/DxeMpInitLibUpDepLib.inf
  create mode 100644 OvmfPkg/Library/MpInitLibDepLib/MpInitLibDepLib.c
  create mode 100644
OvmfPkg/Library/MpInitLibDepLib/PeiMpInitLibMpDepLib.inf
  create mode 100644
OvmfPkg/Library/MpInitLibDepLib/PeiMpInitLibUpDepLib.inf
  delete mode 100644 UefiCpuPkg/Library/MpInitLib/MpIntelTdx.h
  delete mode 100644 UefiCpuPkg/Library/MpInitLib/MpLibTdx.c
  delete mode 100644 UefiCpuPkg/Library/MpInitLib/MpLibTdxNull.c

--
2.29.2.windows.2





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89620): https://edk2.groups.io/g/devel/message/89620
Mute This Topic: https://groups.io/mt/90946714/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/4] MpInitLib: Put SEV logic in separate file

[Lendacky, Thomas via groups.io]

On 5/9/22 06:54, Ni, Ray wrote:

Tom,
Can you please review this change? Does it cause any regression to SEV feature?


Hi Ray,

I just got back from vacation today and I'm going through all my email. 
I'll take a look as soon as I can.


Thanks,
Tom




-Original Message-
From: devel@edk2.groups.io  On Behalf Of Ni, Ray
Sent: Saturday, May 7, 2022 11:13 PM
To: devel@edk2.groups.io
Cc: Dong, Eric ; Kumar, Rahul1 ; Michael 
Roth ;
James Bottomley ; Xu, Min M ; Yao, Jiewen 
; Tom
Lendacky ; Justen, Jordan L 
; Ard Biesheuvel
; Aktas, Erdem ; Gerd Hoffmann 

Subject: [edk2-devel] [PATCH 3/4] MpInitLib: Put SEV logic in separate file

Signed-off-by: Ray Ni 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Michael Roth 
Cc: James Bottomley 
Cc: Min Xu 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Cc: Erdem Aktas 
Cc: Gerd Hoffmann 
---
  .../Library/MpInitLib/Ia32/MpFuncs.nasm   |   3 +-
  UefiCpuPkg/Library/MpInitLib/MpLib.c  |  13 +-
  UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm  | 148 +
  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 157 +-
  4 files changed, 159 insertions(+), 162 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm 
b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
index 8981c32722..67f9ed05cf 100644
--- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
+++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
@@ -199,7 +199,6 @@ CProcedureInvoke:
  call   eax   ; Invoke C function



  jmp$ ; Never reach here

-RendezvousFunnelProcEnd:



  
;-

  ;SwitchToRealProc procedure follows.

@@ -209,6 +208,8 @@ SwitchToRealProcStart:
  jmp$ ; Never reach here

  SwitchToRealProcEnd:



+RendezvousFunnelProcEnd:

+

  
;-

  ;  AsmRelocateApLoop (MwaitSupport, ApTargetCState, PmCodeSegment, 
TopOfApStack, CountTofinish, Pm16CodeSegment,
SevEsAPJumpTable, WakeupBuffer);

  ;

diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 3dc1b9f872..722ff3fd42 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -938,8 +938,7 @@ FillExchangeInfoData (
// EfiBootServicesCode to avoid page fault if NX memory protection is 
enabled.

//

if (CpuMpData->WakeupBufferHigh != 0) {

-Size = CpuMpData->AddressMap.RendezvousFunnelSize +

-   CpuMpData->AddressMap.SwitchToRealSize -

+Size = CpuMpData->AddressMap.RendezvousFunnelSize -

 CpuMpData->AddressMap.ModeTransitionOffset;

  CopyMem (

(VOID *)CpuMpData->WakeupBufferHigh,

@@ -993,8 +992,7 @@ BackupAndPrepareWakeupBuffer (
CopyMem (

  (VOID *)CpuMpData->WakeupBuffer,

  (VOID *)CpuMpData->AddressMap.RendezvousFunnelAddress,

-CpuMpData->AddressMap.RendezvousFunnelSize +

-CpuMpData->AddressMap.SwitchToRealSize

+CpuMpData->AddressMap.RendezvousFunnelSize

  );

  }



@@ -1031,7 +1029,6 @@ GetApResetVectorSize (
UINTN  Size;



Size = AddressMap->RendezvousFunnelSize +

- AddressMap->SwitchToRealSize +

   sizeof (MP_CPU_EXCHANGE_INFO);



return Size;

@@ -1056,11 +1053,9 @@ AllocateResetVector (
  CpuMpData->WakeupBuffer  = GetWakeupBuffer (ApResetVectorSize);

  CpuMpData->MpCpuExchangeInfo = (MP_CPU_EXCHANGE_INFO *)(UINTN)

 (CpuMpData->WakeupBuffer +

-CpuMpData->AddressMap.RendezvousFunnelSize 
+

-CpuMpData->AddressMap.SwitchToRealSize);

+
CpuMpData->AddressMap.RendezvousFunnelSize);

  CpuMpData->WakeupBufferHigh = AllocateCodeBuffer (

-CpuMpData->AddressMap.RendezvousFunnelSize 
+

-CpuMpData->AddressMap.SwitchToRealSize -

+CpuMpData->AddressMap.RendezvousFunnelSize 
-

  CpuMpData->AddressMap.ModeTransitionOffset

  );

  //

diff --git a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm 
b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm
index 8bb1161fa0..7c2469f9c5 100644
--- a/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm
+++ b/UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm
@@ -198,3 +198,151 @@ RestoreGhcb:


  SevEsGetApicIdExit:

  OneTimeCallRetSevEsGetApicId

+

+

+;-

+;SwitchToRealProc procedure follows.

+;ALSO THIS PROCEDURE IS EXECUTED BY APs TRANSITIONING TO 16 BIT MODE. HENCE 
THIS PROC

+;IS IN MACHINE CODE.

+;  SwitchToRealProc (UINTN BufferStart, UINT16 Code16, UINT16 Code32, UINTN 

Re: [edk2-devel] [PATCH 0/4] Refactor MpInitLib

[Lendacky, Thomas via groups.io]

Hi Ray,

Do you have a public git tree with these patches that I can use to test 
with? I'm having lots of problems pulling these patches out of my mail 
client and applying them.


Thanks,
Tom

On 5/7/22 10:13, Ni, Ray via groups.io wrote:


Ray Ni (4):
   MpInitLib: Allocate code buffer for PEI phase
   MpInitLib: remove unneeded global ASM_PFX
   MpInitLib: Put SEV logic in separate file
   MpInitLib: Only allocate below 1MB memory for 16bit code

  UefiCpuPkg/Library/MpInitLib/AmdSev.c |   6 +-
  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   |   2 +-
  .../Library/MpInitLib/Ia32/MpFuncs.nasm   |  11 +-
  UefiCpuPkg/Library/MpInitLib/MpEqu.inc|   2 +-
  UefiCpuPkg/Library/MpInitLib/MpLib.c  |  99 +--
  UefiCpuPkg/Library/MpInitLib/MpLib.h  |   2 +-
  UefiCpuPkg/Library/MpInitLib/PeiMpLib.c   |  15 +-
  UefiCpuPkg/Library/MpInitLib/X64/AmdSev.nasm  | 148 
  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 167 +-
  9 files changed, 216 insertions(+), 236 deletions(-)




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89622): https://edk2.groups.io/g/devel/message/89622
Mute This Topic: https://groups.io/mt/90954624/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg: Reserve the Ovmf work area as RT_DATA

[Lendacky, Thomas via groups.io]

On 8/23/22 03:40, Xu, Min M wrote:

On August 23, 2022 3:38 PM, Gerd Hoffmann wrote:

   Hi,


Ah, I forget to reserve the work-area as RT_Data in below code:
   BuildMemoryAllocationHob (
 (EFI_PHYSICAL_ADDRESS)(UINTN)FixedPcdGet32

(PcdOvmfWorkAreaBase),

 (UINT64)(UINTN)FixedPcdGet32 (PcdOvmfWorkAreaSize),
 PlatformInfoHob->S3Supported ? EfiACPIMemoryNVS :

EfiRuntimeServicesData  <-- ACPI_NVS is not accessible either in OS-Runtime.

 );


https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/Platform

InitLib/MemDetect.c#L1022-L1026


With that changed to use EfiRuntimeServicesData unconditionally the page
fault is gone.


Gerd, do you think we can reserve Ovmf WorkArea as RT_Data even when

S3 is supported?

Hmm, not fully sure how the various memory types are handled when the
VM is suspended.


Tom suggested that the work area should not  be kept around. In stead a PCD 
should be used.
https://edk2.groups.io/g/devel/message/92617

But the dynamic PCD is not thread-safe and it cannot be accessed by APs.

Now we have 2 solutions to fix this issue.
1. Reserve the Ovmf work area as RT_DATA.
2. Split the CcProbeLib into 2 instances. See 
https://edk2.groups.io/g/devel/message/91132

Gerd & Tom, what's your thought?


Runtime service call are restricted so that you don't have concurrent 
threads executing (see section 8.1 of the specification). Without that you 
would have problems with runtime services today.


Thanks,
Tom



Thanks
Min




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92678): https://edk2.groups.io/g/devel/message/92678
Mute This Topic: https://groups.io/mt/93173995/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V4 2/2] OvmfPkg: Update CcProbeLib to DxeCcProbeLib

[Lendacky, Thomas via groups.io]

On 8/26/22 18:07, Min Xu wrote:

From: Min M Xu 

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

CcProbeLib once was designed to probe the Confidential Computing guest
type by checking the PcdOvmfWorkArea. But this memory is allocated with
either EfiACPIMemoryNVS or EfiBootServicesData. It cannot be accessed
after ExitBootService. Please see the detailed analysis in BZ#3974.

To fix this issue, CcProbeLib is redesigned as 2 implementation:
  - SecPeiCcProbeLib
  - DxeCcProbeLib

In SecPeiCcProbeLib we check the CC guest type by reading the
PcdOvmfWorkArea. Because it is used in SEC / PEI and we don't worry about
the issues in BZ#3974.

In DxeCcProbeLib we cache the GuestType in Ovmf work area in a variable.
After that the Guest type is returned with the cached value. So that we
don't need to worry about the access to Ovmf work area after
ExitBootService.

To gurantee the GuestType is cached, we read the value in both


s/gurantee/guarantee/


constructor and CcProbe. Because in some corner case, the constructor
may be called after CcProbe. For example in MdeModulePkg/Core/Dxe/DxeMain,
BaseDebugLibSerialPortConstructor is called before
DxeCcProbeLibConstructor. While CcProbe () is called in
BaseDebugLibSerialPortConstructor.


Is there a way to put some kind of ordering in place so that CcProbe's 
constructor is called before BaseDebugLibSerialPortConstructor?




The reason why we probe CC guest type in 2 different ways is the global
varialbe. Global variable cannot be used in SEC/PEI and CcProbe is called


s/varialbe/variable/

Thanks,
Tom


very frequently.

Cc: Gerd Hoffmann 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92914): https://edk2.groups.io/g/devel/message/92914
Mute This Topic: https://groups.io/mt/93281453/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg: Use Top of each AP's stack to save CpuMpData

[Lendacky, Thomas via groups.io]

On 8/16/22 02:57, Yuanhao Xie via groups.io wrote:

To remove the dependency of CPU register, 4/8 byte at the top of the stack
is occupied for CpuMpData. BIST information is also taken care here.
This modification is only for PEI phase, since in DXE phase CpuMpData is
accessed via global variable.

Signed-off-by: Yuanhao 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
---
  .../Library/MpInitLib/Ia32/MpFuncs.nasm   |  5 +++
  UefiCpuPkg/Library/MpInitLib/MpLib.c  | 41 ++-
  UefiCpuPkg/Library/MpInitLib/MpLib.h  |  8 
  UefiCpuPkg/Library/MpInitLib/PeiMpLib.c   | 10 +++--
  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm |  6 +++
  5 files changed, 56 insertions(+), 14 deletions(-)




@@ -1796,30 +1806,41 @@ MpInitLibInitialize (
AsmGetAddressMap ();
GetApResetVectorSize (, , 
);
ApStackSize = PcdGet32 (PcdCpuApStackSize);
-  ApLoopMode  = GetApLoopMode ();
+  //
+  // ApStackSize must be power of 2
+  //
+  ASSERT ((ApStackSize & (ApStackSize - 1)) == 0);
+  ApLoopMode = GetApLoopMode ();
  
//

// Save BSP's Control registers for APs.
//
SaveVolatileRegisters ();
  
+  //

+  // Allocate extra ApStackSize to let AP stack align on ApStackSize bounday
+  //
BufferSize  = ApStackSize * MaxLogicalProcessorNumber;
+  BufferSize += ApStackSize;
BufferSize += MonitorFilterSize * MaxLogicalProcessorNumber;
BufferSize += ApResetVectorSizeBelow1Mb;
BufferSize  = ALIGN_VALUE (BufferSize, 8);
BufferSize += VolatileRegisters.Idtr.Limit + 1;
BufferSize += sizeof (CPU_MP_DATA);
BufferSize += (sizeof (CPU_AP_DATA) + sizeof (CPU_INFO_IN_HOB))* 
MaxLogicalProcessorNumber;
-  MpBuffer= AllocatePages (EFI_SIZE_TO_PAGES (BufferSize));
+  //
+  // Allocate extra ApStackSize to let stack align on ApStackSize bounday
+  //
+  MpBuffer = AllocatePages (EFI_SIZE_TO_PAGES (BufferSize));


If you're allocating pages, is all the alignment stuff really necessary? 
The allocated value is going to be page aligned already, right?


Thanks,
Tom


ASSERT (MpBuffer != NULL);
ZeroMem (MpBuffer, BufferSize);
-  Buffer = (UINTN)MpBuffer;
+  Buffer = ALIGN_VALUE ((UINTN)MpBuffer, ApStackSize);
  



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92867): https://edk2.groups.io/g/devel/message/92867
Mute This Topic: https://groups.io/mt/93054601/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 14/14] MdeModulePkg: Pool and page functions accept memory when OOM occurs

[Lendacky, Thomas via groups.io]

On 8/27/22 01:21, Min Xu wrote:

From: Jiaqi Gao 

RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937

When CoreAllocatePages() / CoreAllocatePool() meets error of
EFI_OUT_OF_RESOURCES, locate the EdkiiMemoryAcceptProtocol and accept extra
memory dynamically.

Firstly, find the unaccpeted memory region with enough size in GCD


s/unaccpeted/unaccepted/


entries. Then locate the EdkiiMemoryAcceptProtocol and accept the memory.
Finally, update the GCD memory and gMemoryMap entries.

After updating the memory infomation, CoreInternalAllocatePages() /
CoreInternalAllocatePool() will be recalled to allocate pages / pool.


What path does allocation take when called through boot services? If I set 
a 256MB accepted memory size, I can get to the bootloader and select my 
kernel. But then the kernel dies in efi_relocate_kernel() with:


EFI stub: ERROR: Failed to allocate usable memory for kernel.
EFI stub: ERROR: efi_relocate_kernel() failed!
EFI stub: ERROR: efi_main() failed!

because both efi_bs_call(allocate_pages, ...) and efi_low_alloc_above() fail.

Similar to DXE, should OVMF accept more memory through this path to let 
the kernel boot?


Thanks,
Tom



Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Dandan Bi 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 
Cc: Gerd Hoffmann 
Signed-off-by: Jiaqi Gao 
Signed-off-by: Min Xu 
---
  MdeModulePkg/Core/Dxe/DxeMain.inf |   1 +
  MdeModulePkg/Core/Dxe/Mem/Imem.h  |  16 +++
  MdeModulePkg/Core/Dxe/Mem/Page.c  | 190 ++
  MdeModulePkg/Core/Dxe/Mem/Pool.c  |  14 +++
  4 files changed, 221 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index e4bca895773d..371ba45357be 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -169,6 +169,7 @@
gEfiVariableArchProtocolGuid  ## CONSUMES
gEfiCapsuleArchProtocolGuid   ## CONSUMES
gEfiWatchdogTimerArchProtocolGuid ## CONSUMES
+  gEdkiiMemoryAcceptProtocolGuid## CONSUMES
  
  [Pcd]

gEfiMdeModulePkgTokenSpaceGuid.PcdLoadFixAddressBootTimeCodePageNumber
## SOMETIMES_CONSUMES
diff --git a/MdeModulePkg/Core/Dxe/Mem/Imem.h b/MdeModulePkg/Core/Dxe/Mem/Imem.h
index 2f0bf2bf631f..22e0d0e44030 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Imem.h
+++ b/MdeModulePkg/Core/Dxe/Mem/Imem.h
@@ -47,6 +47,22 @@ typedef struct {
  // Internal prototypes
  //
  
+/**

+  Internal function.  Used by the pool and page functions to accept memory
+  when OOM occurs.
+
+  @param  Type   The type of allocation to perform.
+  @param  AcceptSize Size of memory to be accepted.
+  @param  Memory Accept memory address
+
+**/
+EFI_STATUS
+AcceptMemoryResource (
+  IN EFI_ALLOCATE_TYPE Type,
+  IN UINTN AcceptSize,
+  IN OUT EFI_PHYSICAL_ADDRESS  *Memory
+  );
+
  /**
Internal function.  Used by the pool functions to allocate pages
to back pool allocation requests.
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index 160289c1f9ec..513792a7fe04 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -10,6 +10,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
  #include "Imem.h"
  #include "HeapGuard.h"
  #include 
+#include 
  
  //

  // Entry for tracking the memory regions for each memory type to coalesce 
similar memory types
@@ -379,6 +380,176 @@ CoreFreeMemoryMapStack (
mFreeMapStack -= 1;
  }
  
+/**

+  Used to accept memory when OOM occurs.
+
+  @param  Type   The type of allocation to perform.
+  @param  AcceptSize Size of memory to be accepted.
+  @param  Memory Accept memory address
+
+**/
+EFI_STATUS
+AcceptMemoryResource (
+  IN EFI_ALLOCATE_TYPE Type,
+  IN UINTN AcceptSize,
+  IN OUT EFI_PHYSICAL_ADDRESS  *Memory
+  )
+{
+ #ifdef MDE_CPU_X64
+
+  LIST_ENTRY*Link;
+  EFI_GCD_MAP_ENTRY *GcdEntry;
+  EFI_GCD_MAP_ENTRY UnacceptedEntry;
+  EDKII_MEMORY_ACCEPT_PROTOCOL  *MemoryAcceptProtocol;
+  UINTN Start;
+  UINTN End;
+  EFI_STATUSStatus;
+
+  //
+  // We accept n*32MB at one time to improve the efficiency.
+  //
+  AcceptSize = (AcceptSize + SIZE_32MB - 1) & ~(SIZE_32MB - 1);
+
+  if (AcceptSize == 0) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  Status = gBS->LocateProtocol (, NULL, (VOID 
**));
+  if (EFI_ERROR (Status)) {
+return EFI_UNSUPPORTED;
+  }
+
+  if (Type == AllocateAddress) {
+Start = *Memory;
+End   = *Memory + AcceptSize;
+  }
+
+  if (Type == AllocateMaxAddress) {
+if (*Memory < EFI_PAGE_MASK) {
+  return EFI_INVALID_PARAMETER;
+}
+
+if ((*Memory & EFI_PAGE_MASK) != EFI_PAGE_MASK) {
+  //
+  // Change MaxAddress to be 1 page lower
+  //
+  *Memory -= 

Re: [edk2-devel] [PATCH 1/1] OvmfPkg: Reserve the Ovmf work area as RT_DATA

[Lendacky, Thomas via groups.io]

On 8/21/22 21:23, Min Xu wrote:

From: Min M Xu 

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

Ovmf work-area (PcdOvmfWorkArea) was designed to store the Confidential
Computing guest information, including the CC guest type. This
information will be probed by CcProbeLib so that the CC guest type can
be determined in run-time. But the Ovmf work-area was reserved as
BT_Data so that it cannot be accessed after ExitBootService. Please see
the detailed analysis in BZ#3974.

RH also reports a similar bug. Please see:
https://bugzilla.redhat.com/show_bug.cgi?id=2114858

This patch reserves the work-area as RT_Data to fix this bug.


The work area was never meant to be kept around. When first introduced, 
Laszlo had said it could be used early, but that global structures should 
be represented by PCDs. So the code is correct. It seems that the 
CcProbeLib should be setting some PCDs during the start of DXE or similar 
for use during run time services.


Thanks,
Tom



Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Gerd Hoffmann 
Cc: Tom Lendacky 
Signed-off-by: Min Xu 
---
  OvmfPkg/Library/PlatformInitLib/IntelTdx.c  | 2 +-
  OvmfPkg/Library/PlatformInitLib/MemDetect.c | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Library/PlatformInitLib/IntelTdx.c 
b/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
index c6d7c8bb6e0e..286f447fea03 100644
--- a/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
+++ b/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
@@ -557,7 +557,7 @@ PlatformTdxPublishRamRegions (
  BuildMemoryAllocationHob (
(EFI_PHYSICAL_ADDRESS)(UINTN)FixedPcdGet32 (PcdOvmfWorkAreaBase),
(UINT64)(UINTN)FixedPcdGet32 (PcdOvmfWorkAreaSize),
-  EfiBootServicesData
+  EfiRuntimeServicesData
);
}
  }
diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index 942eaf89cfcf..83fc061fcbac 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -1022,7 +1022,7 @@ PlatformQemuInitializeRamForS3 (
BuildMemoryAllocationHob (
  (EFI_PHYSICAL_ADDRESS)(UINTN)FixedPcdGet32 (PcdOvmfWorkAreaBase),
  (UINT64)(UINTN)FixedPcdGet32 (PcdOvmfWorkAreaSize),
-PlatformInfoHob->S3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
+PlatformInfoHob->S3Supported ? EfiACPIMemoryNVS : 
EfiRuntimeServicesData
  );
  }
  



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92617): https://edk2.groups.io/g/devel/message/92617
Mute This Topic: https://groups.io/mt/93173995/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 14/14] MdeModulePkg: Pool and page functions accept memory when OOM occurs

[Lendacky, Thomas via groups.io]

On 8/29/22 22:20, Xu, Min M wrote:

On August 30, 2022 4:47 AM, Lendacky, Thomas wrote:

On 8/27/22 01:21, Min Xu wrote:

From: Jiaqi Gao 

RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937

When CoreAllocatePages() / CoreAllocatePool() meets error of
EFI_OUT_OF_RESOURCES, locate the EdkiiMemoryAcceptProtocol and

accept

extra memory dynamically.

Firstly, find the unaccpeted memory region with enough size in GCD


s/unaccpeted/unaccepted/

Thanks for reminder. It will be fixed in the next version.



entries. Then locate the EdkiiMemoryAcceptProtocol and accept the memory.
Finally, update the GCD memory and gMemoryMap entries.

After updating the memory infomation, CoreInternalAllocatePages() /
CoreInternalAllocatePool() will be recalled to allocate pages / pool.


What path does allocation take when called through boot services? If I set a
256MB accepted memory size, I can get to the bootloader and select my kernel.
But then the kernel dies in efi_relocate_kernel() with:

EFI stub: ERROR: Failed to allocate usable memory for kernel.
EFI stub: ERROR: efi_relocate_kernel() failed!
EFI stub: ERROR: efi_main() failed!

because both efi_bs_call(allocate_pages, ...) and efi_low_alloc_above() fail.

Similar to DXE, should OVMF accept more memory through this path to let the
kernel boot?


Tom is using the grub boot, right? In this case, 256MB accepted memory size is 
too small.
Because in grub boot, AllocatePages is called to allocate memory in grub boot. 
The allocation type is AllocateMaxAddress and the memory address is 10. It 
means the memory should be allocated below 0x10.
If only 256MB is accepted, then probably this memory region (which is under 
0x10) has been used. And there is no unaccepted memory region which is 
available for this memory region (which is under 0x10).
I tried 256MB and it works for direct boot, but not for grub boot.
I tried 384MB and it works for both grub boot and direct boot.
So my suggestion is that the minimal accept memory size is 384MB or more.


Right, I've been able to boot with 512MB without issues. The address is 
0x100 (16MB) and so that makes sense, nothing that can be done for 
that situation.


Thanks,
Tom



Thanks
Min



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92980): https://edk2.groups.io/g/devel/message/92980
Mute This Topic: https://groups.io/mt/93285612/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 1/6] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe

[Lendacky, Thomas via groups.io]

On 9/28/22 10:33, Dionna Glaze wrote:

From: Sophia Wolf 

When a guest OS does not support unaccepted memory, the unaccepted
memory must be accepted before returning a memory map to the caller.

EfiMemoryAcceptProtocol is defined in MdePkg and is implemented /
Installed in AmdSevDxe for AMD SEV-SNP memory acceptance.

Cc: Gerd Hoffmann 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 

Signed-off-by: Sophia Wolf 
---
  OvmfPkg/AmdSevDxe/AmdSevDxe.c  | 34 

  OvmfPkg/AmdSevDxe/AmdSevDxe.inf|  3 ++
  OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c | 24 
+++---
  3 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
index 662d3c4ccb..09aa15165d 100644
--- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
+++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
@@ -20,6 +20,7 @@
  #include 
  #include 
  #include 
+#include 
  
  STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION  mSnpBootDxeTable = {

SIGNATURE_32 ('A','M', 'D', 'E'),
@@ -31,6 +32,29 @@ STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION  
mSnpBootDxeTable = {
FixedPcdGet32 (PcdOvmfCpuidSize),
  };
  
+STATIC EFI_HANDLE mAmdSevDxeHandle = NULL;

+
+STATIC
+EFI_STATUS
+EFIAPI
+AmdSevMemoryAccept (
+  IN EFI_MEMORY_ACCEPT_PROTOCOL *This,
+  IN EFI_PHYSICAL_ADDRESS StartAddress,
+  IN UINTN Size
+)
+{
+  MemEncryptSevSnpPreValidateSystemRam (
+StartAddress,
+EFI_SIZE_TO_PAGES (Size)


Sorry, I forgot to ask this earlier in the series, but is StartAddress 
guaranteed to be page-aligned and Size a multiple of 4KB? Should there be 
any asserts for those just in case?


Also, can Size be 0? In which case MemEncryptSevSnpPreValidateSystemRam() 
shouldn't be called?



+);
+
+  return EFI_SUCCESS;
+}
+
+STATIC EFI_MEMORY_ACCEPT_PROTOCOL mMemoryAcceptProtocol = {
+  AmdSevMemoryAccept
+};
+
  EFI_STATUS
  EFIAPI
  AmdSevDxeEntryPoint (
@@ -147,6 +171,16 @@ AmdSevDxeEntryPoint (
  }
}
  
+  Status = gBS->InstallProtocolInterface (

+  ,
+  ,
+  EFI_NATIVE_INTERFACE,
+  
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Install EfiMemoryAcceptProtocol failed.\n"));
+  }


Should this only be installed for an SNP guest, e.g. put within the
"if (MemEncryptSevSnpIsEnabled ()) {" check?

Maybe use ASSERT_EFI_ERROR (Status)?

Thanks,
Tom


+
//
// If its SEV-SNP active guest then install the 
CONFIDENTIAL_COMPUTING_SEV_SNP_BLOB.
// It contains the location for both the Secrets and CPUID page.
diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
index 9acf860cf2..5abc32 100644
--- a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
+++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
@@ -47,6 +47,9 @@
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize
  
+[Protocols]

+  gEfiMemoryAcceptProtocolGuid
+
  [Guids]
gConfidentialComputingSevSnpBlobGuid
  
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c

index d3a95e4913..ee3710f7b3 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c
@@ -14,6 +14,7 @@
  #include 
  
  #include "SnpPageStateChange.h"

+#include "VirtualMemory.h"
  
  /**

Pre-validate the system RAM when SEV-SNP is enabled in the guest VM.
@@ -29,12 +30,27 @@ MemEncryptSevSnpPreValidateSystemRam (
IN UINTN NumPages
)
  {
+  EFI_STATUS Status;
+
if (!MemEncryptSevSnpIsEnabled ()) {
  return;
}
  
-  //

-  // All the pre-validation must be completed in the PEI phase.
-  //
-  ASSERT (FALSE);
+  // DXE pre-validation may happen with the memory accept protocol.
+  // The protocol should only be called outside the prevalidated ranges
+  // that the PEI stage code explicitly skips. Specifically, only memory
+  // ranges that are classified as unaccepted.
+  if (BaseAddress >= SIZE_4GB) {
+Status = InternalMemEncryptSevCreateIdentityMap1G (
+   0,
+   BaseAddress,
+   EFI_PAGES_TO_SIZE (NumPages)
+   );
+if (EFI_ERROR (Status)) {
+  ASSERT (FALSE);
+  CpuDeadLoop ();
+}
+  }
+
+  InternalSetPageState (BaseAddress, NumPages, SevSnpPagePrivate, TRUE);
  }



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94485): https://edk2.groups.io/g/devel/message/94485
Mute This Topic: https://groups.io/mt/93975245/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/3] Add safe unaccepted memory behavior

[Lendacky, Thomas via groups.io]

On 9/23/22 14:34, Dionna Amalie Glaze wrote:
Ah yes, I did forget to include that patch. Will add to v2. I was just 
setting the ResourceType to unaccepted and skipping the Prevalidate call 
in PlatformPei if the start address is greater or equal to SIZE_4GB. That 
seemed more self-contained than messing with PlatformInitLib. Would you 
prefer that I add SevSnp logic to PlatformInitLib?


No, if it works and is easier / more concise, then please keep it the way 
you have it.


Thanks,
Tom



On Fri, Sep 23, 2022 at 10:19 AM Tom Lendacky > wrote:


On 9/22/22 15:50, Dionna Glaze wrote:
 > These three patches build on the lazy-accept patch series
 >
 > "Introduce Lazy-accept for Tdx guest"
 >
 > by adding SEV-SNP support for the MemoryAccept protocol, and
 > importantly making eager memory acceptance the default behavior.
 >
 > For unaccepted memory to be enabled, we must know that the booted image
 > supports the unaccepted memory type. We add a trivial protocol that
sets
 > a dynamic Pcd to true when called in order for the booted image to
 > signal its support for unaccepted memory. This does not need to be an
 > OsIndications bit because it does not need to be persisted.
 >
 > We use the Pcd to disable a new ExitBootServices notification that
 > accepts all unaccepted memory, removes the unaccepted memory entries in
 > the memory space map, and then add the same memory ranges back as
 > conventional memory.
 >
 > All images that support unaccepted memory must now locate and call this
 > new ENABLE_UNACCEPTED_MEMORY_PROTOCOL.

This seems to be missing the creation of unaccepted memory under SEV-SNP.
Is that going to be part of a separate patch (to update
PlatformAddMemoryBaseSizeHob () and mark anything above 4GB as
unaccepted)?

Thanks,
Tom

 >
 > Cc: Ard Biescheuvel mailto:a...@kernel.org>>
 > Cc: "Min M. Xu" mailto:min.m...@intel.org>>
 > Cc: Gerd Hoffmann mailto:kra...@redhat.com>>
 > Cc: James Bottomley mailto:j...@linux.ibm.com>>
 > Cc: Tom Lendacky mailto:thomas.lenda...@amd.com>>
 > Cc: Jiewen Yao mailto:jiewen@intel.com>>
 > Cc: Erdem Aktas mailto:erdemak...@google.com>>
 >
 > Signed-off-by: Dionna Glaze mailto:dionnagl...@google.com>>
 >
 > Dionna Glaze (3):
 >    OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe
 >    DxeMain accepts all memory at EBS if needed
 >    MdeModulePkg: add EnableUnacceptedMemoryProtocol
 >
 >   MdeModulePkg/Core/Dxe/DxeMain.h               |  32 +
 >   MdeModulePkg/Core/Dxe/DxeMain.inf             |   3 +
 >   MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c       |  19 ++-
 >   MdeModulePkg/Core/Dxe/Mem/Page.c              | 122
++
 >   MdeModulePkg/MdeModulePkg.dec                 |   9 ++
 >   MdeModulePkg/MdeModulePkg.uni                 |   6 +
 >   OvmfPkg/AmdSev/AmdSevX64.dsc                  |   1 +
 >   OvmfPkg/AmdSevDxe/AmdSevDxe.c                 |  27 
 >   OvmfPkg/AmdSevDxe/AmdSevDxe.inf               |   3 +
 >   OvmfPkg/Bhyve/BhyveX64.dsc                    |   2 +
 >   OvmfPkg/CloudHv/CloudHvX64.dsc                |   2 +
 >   OvmfPkg/Include/Library/MemEncryptSevLib.h    |  14 ++
 >   OvmfPkg/IntelTdx/IntelTdxX64.dsc              |   2 +
 >   .../Ia32/MemEncryptSevLib.c                   |  17 +++
 >   .../X64/DxeSnpSystemRamValidate.c             |  35 +
 >   .../X64/PeiSnpSystemRamValidate.c             |  17 +++
 >   .../X64/SecSnpSystemRamValidate.c             |  18 +++
 >   OvmfPkg/OvmfPkgIa32X64.dsc                    |   2 +
 >   OvmfPkg/OvmfPkgX64.dsc                        |   2 +
 >   OvmfPkg/OvmfXen.dsc                           |   2 +
 >   20 files changed, 334 insertions(+), 1 deletion(-)
 >



--
-Dionna Glaze, PhD (she/her)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94249): https://edk2.groups.io/g/devel/message/94249
Mute This Topic: https://groups.io/mt/93857638/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/3] Add safe unaccepted memory behavior

[Lendacky, Thomas via groups.io]

On 9/22/22 15:50, Dionna Glaze wrote:

These three patches build on the lazy-accept patch series

"Introduce Lazy-accept for Tdx guest"

by adding SEV-SNP support for the MemoryAccept protocol, and
importantly making eager memory acceptance the default behavior.

For unaccepted memory to be enabled, we must know that the booted image
supports the unaccepted memory type. We add a trivial protocol that sets
a dynamic Pcd to true when called in order for the booted image to
signal its support for unaccepted memory. This does not need to be an
OsIndications bit because it does not need to be persisted.

We use the Pcd to disable a new ExitBootServices notification that
accepts all unaccepted memory, removes the unaccepted memory entries in
the memory space map, and then add the same memory ranges back as
conventional memory.

All images that support unaccepted memory must now locate and call this
new ENABLE_UNACCEPTED_MEMORY_PROTOCOL.


This seems to be missing the creation of unaccepted memory under SEV-SNP. 
Is that going to be part of a separate patch (to update 
PlatformAddMemoryBaseSizeHob () and mark anything above 4GB as unaccepted)?


Thanks,
Tom



Cc: Ard Biescheuvel 
Cc: "Min M. Xu" 
Cc: Gerd Hoffmann 
Cc: James Bottomley 
Cc: Tom Lendacky 
Cc: Jiewen Yao 
Cc: Erdem Aktas 

Signed-off-by: Dionna Glaze 

Dionna Glaze (3):
   OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe
   DxeMain accepts all memory at EBS if needed
   MdeModulePkg: add EnableUnacceptedMemoryProtocol

  MdeModulePkg/Core/Dxe/DxeMain.h   |  32 +
  MdeModulePkg/Core/Dxe/DxeMain.inf |   3 +
  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c   |  19 ++-
  MdeModulePkg/Core/Dxe/Mem/Page.c  | 122 ++
  MdeModulePkg/MdeModulePkg.dec |   9 ++
  MdeModulePkg/MdeModulePkg.uni |   6 +
  OvmfPkg/AmdSev/AmdSevX64.dsc  |   1 +
  OvmfPkg/AmdSevDxe/AmdSevDxe.c |  27 
  OvmfPkg/AmdSevDxe/AmdSevDxe.inf   |   3 +
  OvmfPkg/Bhyve/BhyveX64.dsc|   2 +
  OvmfPkg/CloudHv/CloudHvX64.dsc|   2 +
  OvmfPkg/Include/Library/MemEncryptSevLib.h|  14 ++
  OvmfPkg/IntelTdx/IntelTdxX64.dsc  |   2 +
  .../Ia32/MemEncryptSevLib.c   |  17 +++
  .../X64/DxeSnpSystemRamValidate.c |  35 +
  .../X64/PeiSnpSystemRamValidate.c |  17 +++
  .../X64/SecSnpSystemRamValidate.c |  18 +++
  OvmfPkg/OvmfPkgIa32X64.dsc|   2 +
  OvmfPkg/OvmfPkgX64.dsc|   2 +
  OvmfPkg/OvmfXen.dsc   |   2 +
  20 files changed, 334 insertions(+), 1 deletion(-)




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94243): https://edk2.groups.io/g/devel/message/94243
Mute This Topic: https://groups.io/mt/93857638/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe

[Lendacky, Thomas via groups.io]

On 9/22/22 15:50, Dionna Glaze wrote:

From: Sophia Wolf 

When a guest OS does not support unaccepted memory, the unaccepted
memory must be accepted before returning a memory map to the caller.

EfiMemoryAcceptProtocol is defined in MdePkg and is implementated /
Installed in AmdSevDxe for AMD SEV-SNP memory acceptance.

Cc: Gerd Hoffmann 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 

Signed-off-by: Sophia Wolf 
---
  OvmfPkg/AmdSevDxe/AmdSevDxe.c | 27 ++
  OvmfPkg/AmdSevDxe/AmdSevDxe.inf   |  3 ++
  OvmfPkg/Include/Library/MemEncryptSevLib.h| 14 
  .../Ia32/MemEncryptSevLib.c   | 17 +
  .../X64/DxeSnpSystemRamValidate.c | 35 +++
  .../X64/PeiSnpSystemRamValidate.c | 17 +
  .../X64/SecSnpSystemRamValidate.c | 18 ++
  7 files changed, 131 insertions(+)

diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
index 662d3c4ccb..74b82a5814 100644
--- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
+++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
@@ -20,6 +20,7 @@
  #include 
  #include 
  #include 
+#include 
  
  STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION  mSnpBootDxeTable = {

SIGNATURE_32 ('A','M', 'D', 'E'),
@@ -31,6 +32,25 @@ STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION  
mSnpBootDxeTable = {
FixedPcdGet32 (PcdOvmfCpuidSize),
  };
  
+EFI_HANDLE mAmdSevDxeHandle = NULL;


Add STATIC this variable and the function below.


+
+EFI_STATUS
+EFIAPI
+AmdSevMemoryAccept (
+  IN EFI_MEMORY_ACCEPT_PROTOCOL *This,
+  IN EFI_PHYSICAL_ADDRESS StartAddress,
+  IN UINTN Size
+)
+{
+  MemEncryptSnpAcceptPages (StartAddress, Size / SIZE_4KB);


Can't this instead just call MemEncryptSevSnpPreValidateSystemRam()? All 
phases have this function, so it would just be changing the version that 
is currently in

OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c

Also, this needs to follow the coding standards and should be:

  MemEncryptSevSnpPreValidateSystemRam (
StartAddress,
EFI_SIZE_TO_PAGES (Size)
);


+
+  return EFI_SUCCESS;
+}
+
+EFI_MEMORY_ACCEPT_PROTOCOL  mMemoryAcceptProtocol = {


STATIC


+  AmdSevMemoryAccept
+};
+
  EFI_STATUS
  EFIAPI
  AmdSevDxeEntryPoint (
@@ -147,6 +167,13 @@ AmdSevDxeEntryPoint (
  }
}
  
+  Status = gBS->InstallProtocolInterface (,

+  , EFI_NATIVE_INTERFACE,
+  );


  Status = gBS->InstallProtocolInterface (
  ,
  ,
  EFI_NATIVE_INTERFACE,
  
  );

(You'll need to this in all places in order to pass CI)


+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Install EfiMemoryAcceptProtocol failed.\n"));
+  }
+
//
// If its SEV-SNP active guest then install the 
CONFIDENTIAL_COMPUTING_SEV_SNP_BLOB.
// It contains the location for both the Secrets and CPUID page.
diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
index 9acf860cf2..5abc32 100644
--- a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
+++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
@@ -47,6 +47,9 @@
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize
  
+[Protocols]

+  gEfiMemoryAcceptProtocolGuid
+
  [Guids]
gConfidentialComputingSevSnpBlobGuid
  
diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h b/OvmfPkg/Include/Library/MemEncryptSevLib.h

index 4fa9c0d700..05ec10471d 100644
--- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
+++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
@@ -228,4 +228,18 @@ MemEncryptSevSnpPreValidateSystemRam (
IN UINTN NumPages
);
  
+/**

+  Accept pages system RAM when SEV-SNP is enabled in the guest VM.
+
+  @param[in]  BaseAddress Base address
+  @param[in]  NumPagesNumber of pages starting from the base 
address
+
+**/
+VOID
+EFIAPI
+MemEncryptSnpAcceptPages (
+  IN PHYSICAL_ADDRESS   BaseAddress,
+  IN UINTN  NumPages
+  );
+


This becomes unnecessary if you use MemEncryptSevSnpPreValidateSystemRam()
instead, since this will only be called during DXE, right?

Thanks,
Tom


  #endif // _MEM_ENCRYPT_SEV_LIB_H_
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c
index f92299fc77..f0747d792e 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c
@@ -153,3 +153,20 @@ MemEncryptSevSnpPreValidateSystemRam (
  {
ASSERT (FALSE);
  }
+
+/**
+  Accept pages system RAM when SEV-SNP is enabled in the guest VM.
+
+  @param[in]  BaseAddress Base address
+  @param[in]  NumPagesNumber of pages starting from the base 
address
+
+**/
+VOID
+EFIAPI
+MemEncryptSnpAcceptPages (
+  IN PHYSICAL_ADDRESS   

Re: [edk2-devel] [PATCH 1/4] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe

[Lendacky, Thomas via groups.io]

On 9/23/22 15:34, Dionna Glaze wrote:

From: Sophia Wolf 

When a guest OS does not support unaccepted memory, the unaccepted
memory must be accepted before returning a memory map to the caller.

EfiMemoryAcceptProtocol is defined in MdePkg and is implementated /
Installed in AmdSevDxe for AMD SEV-SNP memory acceptance.



Shouldn't this have a v2 in the subject (same goes for patch 2/4)?

I didn't see an answer as to why you couldn't use the 
MemEncryptSevSnpPreValidateSystemRam() function in 
OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c to 
accomplish this without introducing a whole new interface to the 
MemEncryptSevLib library.


Also, to better see the paths in the diffstat, I recommend using:
  --diff-options "--stat=1000 --stat-graph-width=20"

Thanks,
Tom


Cc: Gerd Hoffmann 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Tom Lendacky 

Signed-off-by: Sophia Wolf 
---
  OvmfPkg/AmdSevDxe/AmdSevDxe.c | 34 ++
  OvmfPkg/AmdSevDxe/AmdSevDxe.inf   |  3 ++
  OvmfPkg/Include/Library/MemEncryptSevLib.h| 14 
  .../Ia32/MemEncryptSevLib.c   | 17 +
  .../X64/DxeSnpSystemRamValidate.c | 35 +++
  .../X64/PeiSnpSystemRamValidate.c | 17 +
  .../X64/SecSnpSystemRamValidate.c | 18 ++
  7 files changed, 138 insertions(+)

diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
index 662d3c4ccb..6e3a1fc7d7 100644
--- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
+++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
@@ -20,6 +20,7 @@
  #include 
  #include 
  #include 
+#include 
  
  STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION  mSnpBootDxeTable = {

SIGNATURE_32 ('A','M', 'D', 'E'),
@@ -31,6 +32,29 @@ STATIC CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION  
mSnpBootDxeTable = {
FixedPcdGet32 (PcdOvmfCpuidSize),
  };
  
+STATIC EFI_HANDLE mAmdSevDxeHandle = NULL;

+
+STATIC
+EFI_STATUS
+EFIAPI
+AmdSevMemoryAccept (
+  IN EFI_MEMORY_ACCEPT_PROTOCOL *This,
+  IN EFI_PHYSICAL_ADDRESS StartAddress,
+  IN UINTN Size
+)
+{
+  MemEncryptSnpAcceptPages (
+StartAddress,
+EFI_SIZE_TO_PAGES (Size)
+);
+
+  return EFI_SUCCESS;
+}
+
+STATIC EFI_MEMORY_ACCEPT_PROTOCOL mMemoryAcceptProtocol = {
+  AmdSevMemoryAccept
+};
+
  EFI_STATUS
  EFIAPI
  AmdSevDxeEntryPoint (
@@ -147,6 +171,16 @@ AmdSevDxeEntryPoint (
  }
}
  
+  Status = gBS->InstallProtocolInterface (

+  ,
+  ,
+  EFI_NATIVE_INTERFACE,
+  
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Install EfiMemoryAcceptProtocol failed.\n"));
+  }
+
//
// If its SEV-SNP active guest then install the 
CONFIDENTIAL_COMPUTING_SEV_SNP_BLOB.
// It contains the location for both the Secrets and CPUID page.
diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
index 9acf860cf2..5abc32 100644
--- a/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
+++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.inf
@@ -47,6 +47,9 @@
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsSize
  
+[Protocols]

+  gEfiMemoryAcceptProtocolGuid
+
  [Guids]
gConfidentialComputingSevSnpBlobGuid
  
diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h b/OvmfPkg/Include/Library/MemEncryptSevLib.h

index 4fa9c0d700..05ec10471d 100644
--- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
+++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
@@ -228,4 +228,18 @@ MemEncryptSevSnpPreValidateSystemRam (
IN UINTN NumPages
);
  
+/**

+  Accept pages system RAM when SEV-SNP is enabled in the guest VM.
+
+  @param[in]  BaseAddress Base address
+  @param[in]  NumPagesNumber of pages starting from the base 
address
+
+**/
+VOID
+EFIAPI
+MemEncryptSnpAcceptPages (
+  IN PHYSICAL_ADDRESS   BaseAddress,
+  IN UINTN  NumPages
+  );
+
  #endif // _MEM_ENCRYPT_SEV_LIB_H_
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c
index f92299fc77..f0747d792e 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c
@@ -153,3 +153,20 @@ MemEncryptSevSnpPreValidateSystemRam (
  {
ASSERT (FALSE);
  }
+
+/**
+  Accept pages system RAM when SEV-SNP is enabled in the guest VM.
+
+  @param[in]  BaseAddress Base address
+  @param[in]  NumPagesNumber of pages starting from the base 
address
+
+**/
+VOID
+EFIAPI
+MemEncryptSnpAcceptPages (
+  IN PHYSICAL_ADDRESS   BaseAddress,
+  IN UINTN  NumPages
+  )
+{
+  ASSERT (FALSE);
+}
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c
index