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

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

Hi Alex, Ard, Gerd,

Thanks for roping me in,

On Thu, 13 Feb 2025 at 12:13, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 13 Feb 2025 at 11:11, Alexander Graf <graf@amazon.com> wrote:
> >
> >
> > 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.
> >
>
> Identical afaik

I don't know what I can do to help here but I'll explain what we have
in case we can figure something out .
The idea is very close indeed and in fact it works on QEMU with some
hacks for arm(7/8). [0]. Since QEMU doesn't have an RPMB emulation I
am providing one in software in U-Boot. That's obviously useless in
real use usecases, since the memory backend disappears when we leave
the firmware, but still useful for testing.

I also have a blog explaining the arm specific bits here [1].

The TL;DR is that we set up everything StMM needs inside OP-TEE and
execute it in S-EL1. For storage, we have a 'special' StMM driver that
sends requests to OP-TEE and uses its RPMB support to write sensitive
data on the device.

[0] https://git.linaro.org/people/ilias.apalodimas/efi_optee_variables.git/
[1] https://old.linaro.org/blog/protected-uefi-variables-with-u-boot/

Let me know if you need anything else

Cheers
/Ilias