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
