Hi Alex, Ard, Gerd, Thanks for roping me in,
On Thu, 13 Feb 2025 at 12:13, Ard Biesheuvel <a...@kernel.org> wrote: > > On Thu, 13 Feb 2025 at 11:11, Alexander Graf <g...@amazon.com> wrote: > > > > > > On 13.02.25 10:41, Ard Biesheuvel wrote: > > > On Tue, 11 Feb 2025 at 10:23, Gerd Hoffmann <kra...@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.gd73...@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
