On 2/14/23 11:28, 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.
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). If you want the current values of all uefi variables
The variables are not encrypted and not measured at launch because they
need to be modified and stored on the host side.
You can choose to use a single vars/code file, which keeps the variables
in memory, but you then lose any changes made to them upon VM termination.
Thanks,
Tom
in your SVSM attestation report, I think it's probably better to use
the EFI_CC_MEASUREMENT_PROTOCOL, right? 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?
In any case, persistence in The Cloud (TM) remains a challenge in the
CC space. Discussion about what we should do about that should remain
on the coco mailing list. IVARS encrypts data with Google-managed
keys, so it wouldn't be directly applicable to SVSM NVRAM.
If something usable already exists we don't need to reinvent the wheel.
Don't have to tell me twice. In the spirit of OSS collaboration and
product integrity, I think any CC offering's firmware should be public
and verifiably built. I'll keep pushing for that.
thanks & take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100197): https://edk2.groups.io/g/devel/message/100197
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]
-=-=-=-=-=-=-=-=-=-=-=-
