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

--- Comment #15 from Dionna Glaze <dionnaglaze@...> ---

What I am missing here is the justification for supporting all these combinations in what amounts to a highly bespoke and restricted confidential VM scenario.

We have customers in each category is the short of it. There's demand for
supporting all these cases.

The attestation and memory encryption pieces of confidential computing rely heavily on firmware abstractions. Is it really a priority, and worth obfuscating the picture, to support a boot mode where a legacy BIOS boots directly into a Linux kernel without awareness of the EFI firmware at all? If so, could you elaborate on how such a deployment still makes meaningful use of the features that confidential VMs provide?

I'm not sure I understand your question. Canonical for example ships their
Ubuntu virtual machine images with GRUB2 installed, so it may call
ExitBootServices before Linux can. I'm not talking about Linux having no
understanding of the EFI. I'm talking about supporting a clean path where Linux
might not be compiled with CONFIG_UNSUPPORTED_MEMORY=y, which is an allowed
configuration for both SEV-SNP and TDX.

As for the use of OsIndications: I think this is a reasonable and idiomatic way of using this feature. I do wonder if we could 'abuse' the fact that GetMemoryMap()+ExitBootServices() are documented as potentially needing to be invoked twice, and accept all memory at ExitBootServices() time if the OsIndication has not been set by the EFI stub (as opposed to the OS proper).

ExitBootServices() would accept all memory and return an error, forcing the
caller to call GetMemoryMap() again to obtain the updated version before
calling EBS() again. If the OsIndication has been set, things proceed as usual.

I've implemented this and it doesn't work without a reboot when using GRUB2 to
boot Linux. It calls ExitBootServices before launching Linux. We'd have to do
some kind of inspection in GRUB2 to check if the kernel supports unaccepted
memory, or add a grub configuration thingy and have it perform the EFI variable
dance. That kernel inspection is something I know you've NACK'd explicitly.
GRUB2 configuration is kind of this problem all over again, so I feel a bit
stuck.

--
You are receiving this mail because:
You are on the CC list for the bug.