Re: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast Live Migration for AMD SEV
[AMD Official Use Only - Internal Distribution Only] Hi Yao, In the current proposal the accelerated migration does not involve the PSP. I will let Tobin and Dov comment on how things works in current prototype. If PSP was involved in the migration, then flow would be like this: - During the guest creation time two things will happen (both source and destination VMs go through this step) a) create a random VM encryption key (VEK) -- the key is used for encrypting the guest pages. b) guest owner supplies a session blob to the PSP. The session blob contains transport encryption key (TEK). The TEK is used to encrypt all the confidential information exchanged between the PSP and the external entities such as a guest owner or another PSP. During the migration i) source VMM asks PSP to get a page that can be migrated. ii) source PSP encrypt the guest pages using the TEK iii) source VMM write the encrypted pages on the wire iv) destination VMM will call PSP to put the received encrypted page in the guest memory. v) destination PSP will decrypt the received pages using TEK, then encrypt it using the VEK before copying it to the guest memory. As you see in the flow, the PSP's never share the keys. The TEK is wrapped in the session blob provided to the PSP on launch. You are correct that the SEV/SEV-ES does not support querying the attestation report after the guest boot. All the attestation need to be done during the guest creation time. With SEV-SNP, a guest OS/BIOS can call PSP to get the attestation report. The SEV-SNP, provides a method in which the guest owner can provide an IMI (Initial migration agent) through the launch process. The IMI will be measured separately and stored in IMD (Initial Migration Digest). When source VMM is ready to migrate it will use a PSP command (VM_EXPORT) to export the data from source to destination. The export will contains information about IMD etc. The destination VMM will use the PSP command (ABSORB) to import the incoming data. During the absorb process the destination PSP will check the IMD to ensure that same IMI is used at the source end. I have cut short few details in the email; See the SEV-SNP spec (section migration 4.11) for more. Thanks Brijesh -Original Message- From: Yao, Jiewen Sent: Friday, March 12, 2021 8:32 PM To: devel@edk2.groups.io; Yao, Jiewen ; to...@linux.ibm.com Cc: Dov Murik ; Tobin Feldman-Fitzthum ; James Bottomley ; Hubertus Franke ; Singh, Brijesh ; Kalra, Ashish ; Grimm, Jon ; Lendacky, Thomas Subject: RE: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast Live Migration for AMD SEV Hi We discuss the patch internally. We do see PROs and CONs with this approach. The advantage is that it is very simple. In-VM migration can save lots of effort on security context restore. On the other hand, we feel not so comfortable to reserve a dedicate CPU to achieve that. Similar to the feedback in the community. Using Hot-Plug is not a solution for Intel TDX as well. It is unsupported now. I like the idea to diverge the migration boot mode v.s. normal boot mode in SEC phase. We must be very carefully handle this migration boot mode, to avoid any touching on system memory. Intel TDX Virtual Firmware skips the PEI phase directly. If we choose this approach, SEC-based migration is our preference. Besides this patch, we would like to understand a full picture. 1) How the key is passed from source VM to destination? I saw you mentions: "Key sharing is out of scope for this part of the RFC." "This will probably be implemented via inject-launch-secret in the future" Does that mean two PSP will sync with each other and negotiate the key, after the Migration Agent (MA) checks the policy? 2) How the attestation is supported? I read the whitepaper https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2FSEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdfdata=04%7C01%7Cbrijesh.singh%40amd.com%7Cb19ccecd6ca946abd0eb08d8e5c84177%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637511995981376795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=h67VntbdjigZFvhRfP6%2FGYTE9eqrFDqJRojWqG0C25c%3Dreserved=0. It seems SEV and SEV-ES only support attestation during launch, I don't believe this migration feature will impact the attestation report. Am I right? SEV-SNP supports more flexible attestation, does it include any information about the new migrated content? > -Original Message- > From: devel@edk2.groups.io On Behalf Of Yao, > Jiewen > Sent: Thursday, March 4, 2021 9:49 AM > To: devel@edk2.groups.io; to...@linux.ibm.com > Cc: Dov Murik ; Tobin Feldman-Fitzthum > ; James Bottomley ; Hubertus Franke > ; Brijesh Singh ; Ashish > Kalra ; Jon Grimm ; Tom > Lendacky ; Yao, Jiewen > Subject: Re: [edk2-devel] [RFC PATCH 00/1
Re: [edk2-devel] [PATCH 4/4] MdeModulePkg/DxeIpl: Create 5-level page table for long mode
On 7/23/19 2:48 AM, Laszlo Ersek wrote:
> (+ Brijesh, and one comment below)
>
> On 07/23/19 04:05, Wu, Hao A wrote:
>>> -Original Message-
>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ni,
>>> Ray
>>> Sent: Monday, July 22, 2019 4:16 PM
>>> To: devel@edk2.groups.io
>>> Cc: Dong, Eric; Laszlo Ersek
>>> Subject: [edk2-devel] [PATCH 4/4] MdeModulePkg/DxeIpl: Create 5-level
>>> page table for long mode
>>>
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2008
>>>
>>> DxeIpl is responsible to create page table for DXE phase running
>>> either in long mode or in 32bit mode with certain protection
>>> mechanism enabled (refer to ToBuildPageTable()).
>>>
>>> The patch updates DxeIpl to create 5-level page table for DXE phase
>>> running in long mode when PcdUse5LevelPageTable is TRUE and CPU
>>> supports 5-level page table.
>>>
>>> Signed-off-by: Ray Ni
>>> Cc: Eric Dong
>>> Cc: Laszlo Ersek
>>> ---
>>> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 1 +
>>> .../Core/DxeIplPeim/X64/VirtualMemory.c | 227 --
>>> 2 files changed, 151 insertions(+), 77 deletions(-)
>>>
>>> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>>> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>>> index abc3217b01..98bc17fc9d 100644
>>> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>>> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>>> @@ -110,6 +110,7 @@ [Pcd.IA32,Pcd.X64]
>>>
>>> gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
>>> ## CONSUMES
>>> gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
>>> ## CONSUMES
>>> gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard ##
>>> CONSUMES
>>> + gEfiMdeModulePkgTokenSpaceGuid.PcdUse5LevelPageTable ##
>>> SOMETIMES_CONSUMES
>>>
>>> [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
>>> gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack ##
>>> SOMETIMES_CONSUMES
>>> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>>> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>>> index edc38e4525..a5bcdcc734 100644
>>> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>>> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>>> @@ -15,7 +15,7 @@
>>> 2) IA-32 Intel(R) Architecture Software Developer's Manual Volume
>>> 2:Instruction Set Reference, Intel
>>> 3) IA-32 Intel(R) Architecture Software Developer's Manual Volume
>>> 3:System Programmer's Guide, Intel
>>>
>>> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>>> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>>> Copyright (c) 2017, AMD Incorporated. All rights reserved.
>>>
>>> SPDX-License-Identifier: BSD-2-Clause-Patent
>>> @@ -626,14 +626,19 @@ CreateIdentityMappingPageTables (
>>> )
>>> {
>>> UINT32RegEax;
>>> + UINT32RegEbx;
>>> + UINT32RegEcx;
>>> UINT32RegEdx;
>>> UINT8 PhysicalAddressBits;
>>> EFI_PHYSICAL_ADDRESS PageAddress;
>>> + UINTN IndexOfPml5Entries;
>>> UINTN IndexOfPml4Entries;
>>> UINTN IndexOfPdpEntries;
>>> UINTN
>>> IndexOfPageDirectoryEntries;
>>> + UINT32NumberOfPml5EntriesNeeded;
>>> UINT32NumberOfPml4EntriesNeeded;
>>> UINT32NumberOfPdpEntriesNeeded;
>>> + PAGE_MAP_AND_DIRECTORY_POINTER*PageMapLevel5Entry;
>>> PAGE_MAP_AND_DIRECTORY_POINTER*PageMapLevel4Entry;
>>> PAGE_MAP_AND_DIRECTORY_POINTER*PageMap;
>>> PAGE_MAP_AND_DIRECTORY_POINTER
>>> *PageDirectoryPointerEntry;
>>> @@ -641,9 +646,11 @@ CreateIdentityMappingPageTables (
>>> UINTN TotalPagesNum;
>>> UINTN BigPageAddress;
>>> VOID *Hob;
>>> + BOOLEAN Page5LevelSupport;
>>> BOOLEAN Page1GSupport;
>>> PAGE_TABLE_1G_ENTRY *PageDirectory1GEntry;
>>> UINT64AddressEncMask;
>>> + IA32_CR4 Cr4;
>>>
>>> //
>>> // Make sure AddressEncMask is contained to smallest supported address
>>> field
>>> @@ -677,33 +684,66 @@ CreateIdentityMappingPageTables (
>>> }
>>> }
>>>
>>> + Page5LevelSupport = FALSE;
>>> + if (PcdGetBool (PcdUse5LevelPageTable)) {
>>> +AsmCpuidEx (0x7, 0, , , , );
>>> +DEBUG ((DEBUG_INFO,
