Re: [PATCH v3 00/23] hw/uefi: add uefi variable service

[Alexander Graf <graf@amazon.com>]

On 13.02.25 10:41, Ard Biesheuvel wrote:
> On Tue, 11 Feb 2025 at 10:23, Gerd Hoffmann <kraxel@redhat.com> wrote:
>> This patch adds a virtual device to qemu which the uefi firmware can use
>> to store variables.  This moves the UEFI variable management from
>> privileged guest code (managing vars in pflash) to the host.  Main
>> advantage is that the need to have privilege separation in the guest
>> goes away.
>>
>> On x86 privileged guest code runs in SMM.  It's supported by kvm, but
>> not liked much by various stakeholders in cloud space due to the
>> complexity SMM emulation brings.
>>
>> On arm privileged guest code runs in el3 (aka secure world).  This is
>> not supported by kvm, which is unlikely to change anytime soon given
>> that even el2 support (nested virt) is being worked on for years and is
>> not yet in mainline.
>>
> The secure counterpart of this would never execute at EL3 on ARM, but
> at secure EL1 (or potentially at secure EL2 on more recent CPUs). But
> the general point that this is difficult to virtualize stands; I've
> contemplated doing something similar to SMM emulation using non-secure
> EL1 in a separate VM to provide an execution context that could those
> the secure EL1 payload (using standalone MM) but I never found the
> time to work on this.


Sounds very similar to what Ilias built a few years ago?

https://lore.kernel.org/all/20200511085205.GD73895@apalos.home/T/

Which reminds me: How similar is the protocol in this patch set to the 
one implemented in U-Boot? No need to reinvent the wheel over and over 
again.

>> The design idea is to reuse the request serialization protocol edk2 uses
>> for communication between SMM and non-SMM code, so large chunks of the
>> edk2 variable driver stack can be used unmodified.  Only the driver
>> which traps into SMM mode must be replaced by a driver which talks to
>> qemu instead.
>>
> I like this approach, but I will note that these protocols are not
> standardized: it is basically an EDK2 implementation detail, but this
> is fine, given that this targets firmware that is based on EDK2 (or
> its derivatives).
>
> Using a single shared communication buffer makes it feasible to
> paravirtualize this even under confidential compute scenarios (where
> the buffer needs special shared mapping semantics), and I think this
> might be useful, even if in principle, the VMM is untrusted in such
> scenarios. Paravirtualizing the individual variable services directly
> creates a problem here, given that the firmware cannot share mappings
> of arbitrary arguments passed via pointers.
>
> For the record, I've already acked the OVMF counterpart of this, and
> I've started working on adding support for this to my minimal EFI for
> mach-virt [0], which is another scenario (i.e., minimal EFI compatible
> firmware for micro VMs) where having this complexity in the VMM is
> preferred.


Amazing! :)


Alex