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