Re: [edk2-devel] [PATCH RFC v2 11/28] OvmfPkg: Reserve Secrets page in MEMFD

["James Bottomley" <jejb@linux.ibm.com>]

On Thu, 2021-05-06 at 13:57 +0300, Dov Murik wrote:
> 
> On 05/05/2021 22:33, Laszlo Ersek wrote:
> > On 05/05/21 15:11, Brijesh Singh wrote:
> > > On 5/5/21 1:42 AM, Dov Murik wrote:
[...]
> > > > Would it make sense to always use EfiACPIMemoryNVS for the
> > > > injected secret area, even for regular SEV (non-SNP)?
> > > 
> > > Ideally yes. Maybe James had some reasons for choosing the
> > > EfiBootServicesData. If I had to guess, it was mainly because
> > > there no guest kernel support which consumes the SEV secrets
> > > page.
> > 
> > git-blame fingers commit bff2811c6d99 ("OvmfPkg/AmdSev: assign and
> > reserve the Sev Secret area", 2020-12-14).
> > 
> > Commit bff2811c6d99 makes it clear that the area in question lives
> > in MEMFD.
> > 
> > We're populating the area in the PEI phase. We don't want anything
> > in DXE to overwrite it.
> > 
> > Once the bootloader (and/or perhaps the kernel's EFI stub) fetched
> > the secret from that particular location, there is no need to
> > prevent later parts of the OS (the actual kernel) from repurposing
> > that area. That's why EfiBootServicesData was used.
> > 
> 
> The first use of the secret area was to hold the guest luks disk
> passphrase; this is used in the grub-inside-OVMF (AmdSev package),
> and there was no need to keep that page around for the guest kernel.
> 
> The reason I'm raising this whole point is that we're working now on
> guest-kernel support for reading secrets from that injected page (for
> plain SEV).  We considered either (a) modifying the secrets page
> memory type to reserved here, or (b) add code to the kernel EFI stub
> that would copy this page somewhere else for kernel's later use
> (which seems more work and not sure what's the advantage).

It mirrors the TPM boot log behaviour: the log is stored in boot time
only memory, so the kernel EFI stub has to copy it out.  The reason the
TPM boot log behaves this way is that if the kernel didn't want to
collect it, it still gets freed.  I imagine a similar rationale exists
for the boot secrets: if the kernel isn't interested in them for some
reason, we don't want them to persist.

> Option (b) seems harder and more fragile, and I'm not sure if there
> are any advantages (though I'm definitely not an expert in that
> area).

I think forcing the kernel to consume the secret before exit boot
services is still a good idea because 

   1. If the kernel can't consume the secret it gets freed
   2. Not all secrets are consumed by the kernel, so it can pick the ones
      it wants out and discard the rest
   3. If the kernel is using a secret protection mechanism, that may not
      work for the memfd page, so relocation of the secret might be a more
      secure mechanism.

James