Re: [PATCH v6 15/29] OvmfPkg/MemEncryptSevLib: add support to validate system RAM

["Brijesh Singh" <brijesh.singh@amd.com>]

On 9/2/21 4:50 AM, Gerd Hoffmann wrote:
>   Hi,
>
>> During the guest creation, the boot ROM memory is pre-validated by the
>> AMD-SEV firmware. The MemEncryptSevSnpValidateSystemRam() can be called
>> during the SEC and PEI phase to validate the detected system RAM.
> [ for this and the following few patches ]
>
> So, sev-snp and tdx have the same fundamental requirement here.  Both
> must track what the state of page ranges is.  Both must talk to the vmm
> before they can actually use pages.  snp calls this "validate", tdx
> "accept", but the underlying concept should be roughly comparable.

Yes, both the technologies need to accept/validate the pages before
access. Both the hypervisor and guest implementation will be different.
e.g., in SNP, communication to the hypervisor is done through the
VMGEXIT defined in the GHCB spec, whereas TDX will follow a separate
exit on how it reaches the hypervisor calls the TDX shim, etc. All the
platform-specific details on how the validation is executed should live
inside the vendor-specific libraries. That is why I added all the
validation flow in MemEncryptSevLib (which is AMD SEV specification
library that provides routines to change the page state etc). The Intel
TDX patches add a similar flow in the TDX specific library and Ovmf core
calls it. Once both the libraries are in, we can develop a shared
library that OVMF can use.

IIRC, in the TDX proposal, I got the impression that TDX implementation
will skip the PEI phase, and it jumps from SEC->DXE. The SEC phase
somehow will know the guest memory range and validate it. For SEV-SNP,
we are trying to stick to the existing boot flow and validate the memory
as soon as its discovered during the PEI phase.

As explained in the commit, there are multiple options we can take to
validate the guest memory.
1) The OVMF PEI validates the entire RAM while its discovers it.
2) The OVMF memory probe routine marks the discovered system RAM as
"Unaccepted".
3) The OVMF memory probe routine does nothing during the discovery phase.

Each of these approaches have advantages and disadvantage

Approach #1

The main advantage is that EDK2 core and guest OS can accept the memory
without any validation step. It will be slower because validation will
require the hypervisor to exist and also touch the memory. For SNP, a
new VMGEXIT was added in the GHCB spec that can be used to batch
multiple validation requests. e.g. one PSC (Page State Change) can
contain up to 253 entries, and each entry can cover up to 2MB. In other
words, we can validate up to 500MB in one VMGEXIT.

Approach #2

The main advantage of this approach is that it can support lazy
validation, and it can undoubtedly help reduce boot time. But to support
this, the EDK2 core memory management needs to be enhanced to know the
unaccepted memory type and validate it before access. The EDK2 core
should also build the EFI memory map to communicate to the guest OS on
validated so that guest OS does not double validation.

For this to work, the guest OS needs to know how to deal with the
unaccepted EFI memory range.

Approach #3

Validate memory on demand. In SNP hardware, access to the unvalidated
page causes a #VC. The guest BIOS and OS can use the #VC
(page-not-validated) exception and validate the range from exception
handler itself. It looks attractive until we run into a situation where
the guest is doing a memset() of significant memory, and each access is
causing the #VC and thus making the boot or run slow on the first access.

This patch series implements #1. And we will be looking at approach #2
after the base is enabled. Approach #2 builds upon #1. As you
highlighted below that we have not seen the patches for the Lazy
validation here so its hard to comment but I am hopeful that it will
integrated just fine with the SNP.


> The vmm part obviously needs to be different.  I can't see any good
> reason why the state tracking and the state hand over from one boot
> stage to the next (vmm -> sec -> pei -> dxe -> os) should be different
> though.  Having a common workflow makes long-term maintenance and
> testing easier.
>
>     So, can you all look at each others patches and find common ground
>     here?  It worked out well for the WorkArea, so *please* continue
>     that way.
>
> This series seems to side-step most of this by validating all memory in
> the pei stage, so there is nothing to hand over to dxe and os.  Only the
> range where the compressed code gets uncompressed to must be passed from
> sec to pei.  And there is the memory range registered for pre-validation
> by the vmm.

Yes, I am taking phased approach. Making the Lazy validation work will
require changes in both the edk2 and guest OS core memory management.


> Intels (long-term?) plan seems to be to do lazily validate/accept
> memory, triggered by memory allocations, to reduce boot time.  Which
> implies the dxe memory management core needs to be aware of page state
> and invoke an vmm-specific protocol to handle validation/acceptance.
> Concept posted to the list earlier this week.  Slides only so far, no
> patches yet.
> take care,
>   Gerd
>