On Tue, Feb 14, 2023 at 09:28:49AM -0800, Dionna Amalie Glaze wrote: > > > > Do you have any pointers on the IVARS service? Documentation, guest > > code, host code? > > > > Agh, I thought for sure there was a public API for VM owners to view > or change their UEFI variables, but I guess not. It's an > instance-specific small data store for nonvolatile memory like vTPM > and UEFI variables. It appears you can only set the variables through > cloud API at instance creation time. But this is how instances can be > shut down and brought back up on different machines and/or live > migrate to other machines and still have access to UEFI variables' > current values. Host code is all in Google's proprietary VMM, > Vanadium, but the device backend is really rather simple. The data > store service though, that's a matter of Cloud Scale Engineering.
The device backend would be a good start (host code being part of the google vmm is expected ...). > > Background: When moving to a SVSM-based setup where the svsm (with > > vtpm emulation) runs in vmpl0 and the edk2 firmware in vmpl1 we might > > likewise add a efi variable service to the svsm. > > I thought EFI variables in Qemu were loaded and measured at launch > (OVMF_VARS.fd). Yes, that is the current state of affairs. Variables are fixed and are measured (launch measurement for SEV, runtime measurement for TDX). The variable store lives in RAM and all changes are gone when the guest is stopped. So we don't really have persistent EFI variables. For persistent EFI variables we need to have the variables stored in some secure place, so the OS can't change -- for example -- secure boot configuration as it pleases. In traditional VMs that happens to be SMM mode. For SEV-SNP the SVSM could handle this, and we need some protocol used by SVSM efi variable service and ovmf to talk to each other. Here the protocol used by google vmm could eventually be reused. And possibly the very same protocol could be used to simply run the efi variable service on the host (for traditional VMs) and ditch SMM mode then. > Or is it specifically going to be an SVSM service that attests itself > with current stored variables, or at least variables that are > considered important enough to measure? The variables considered important for secure boot (db etc.) are measured (by edk2) anyway. > In any case, persistence in The Cloud (TM) remains a challenge in the > CC space. Indeed. One idea is to hand out some (virtual) flash to the SVSM for persistent data. Which would need to be encrypted, and we need to manage the keys for that. Not fully sure where we stand here, it's not my main focus. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100233): https://edk2.groups.io/g/devel/message/100233 Mute This Topic: https://groups.io/mt/96534752/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
