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

[Alexander Graf]

Hey Gerd!

On 15.11.23 16:12, Gerd Hoffmann 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 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'm not sure I like the split :). If we cut things off at the SMM 
communication layer, we still have a lot of code inside the Runtime 
Services (RTS) code that is edk2 specific which means we're tying 
ourselves tightly to the edk2 data format. It also means we can not 
easily expose UEFI variables that QEMU owns, which can come in very 
handy when implementing MOR - another feature that depends on SMM today.

In EC2, we are simply serializing all variable RTS calls to the 
hypervisor, similar to the Xen implementation 
(https://www.youtube.com/watch?v=jiR8khaECEk).

The edk2 side code we have built is here: 
https://github.com/aws/uefi/tree/main/edk2-stable202211 (see anything 
with VarStore in the name).

For the vmm side, we currently have an AWS-internal C++ implementation 
that I can convert into QEMU code and send as patch if there is real 
interest. Given that we deal with untrusted input, I would strongly 
prefer if we could move it to a Rust implementation instead though. We 
started a Rust reimplementation of it that interface that can build as a 
library with C bindings which QEMU could then link against:

  https://github.com/Mimoja/rs-uefi-varstore/tree/for_main

The code never went beyond the initial stages, but if we're pulling the 
variable store to QEMU, this would be the best path forward IMHO.


If instead, we just want something we can quickly integrate while eating 
up the additional security risk, I think we should just reuse the Xen 
implementation.


Alex





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879