On Thu, Mar 13, 2025 at 2:40 PM Jörg Rödel <j...@8bytes.org> wrote: > > Hi Ani, > > On Fri, Feb 14, 2025 at 09:04:07PM +0530, Ani Sinha wrote: > > VM firmware update is a mechanism where the virtual machines can use their > > preferred and trusted firmware image in their execution environment without > > having to depend on a untrusted party to provide the firmware bundle. This > > is > > particularly useful for confidential virtual machines that are deployed in > > the > > cloud where the tenant and the cloud provider are two different entities. In > > this scenario, virtual machines can bring their own trusted firmware image > > bundled as a part of their filesystem (using UKIs for example[1]) and then > > use > > this hypervisor interface to update to their trusted firmware image. This > > also > > allows the guests to have a consistent measurements on the firmware image. > > We discussed the implications of the vmfwupdate mechanism as currently > proposed in yesterdays SVSM Development Call[1]. The reason this came to my > attention was a request to support a non-IGVM boot protocol in > COCONUT-SVSM, so I started to look into the vmfwupdate. > > I do not claim to have a full picture yet, but what I'd like to better > understand is how the proposed update mechanism plans to guarantee > predictable launch measurements for confidential VMs, especially since > the measurements depend on the exact order of setup calls for the TEE > and data the vmfwupdate mechanism can currently not pass on to the > state-after-reset. Can you please share some details on that?
The state before reset is the state that uses stock firmware from the hyperscaler. The state after reset is a fresh new state that uses the "trusted and known firmware" from the end user. So the launch measurements would not match between the state before reset and the state after reset and there is no guarantee that there would be "predictable launch measurements" across the reset. What we do guarantee is that after reset, the launch measurements that include the "trusted and known firmware" (whatever that is, not necessarily edk2), is understood and expected. If you were to calculate offline the measurements that include this "trusted and known firmware" using the same order of setup calls as the target system and then derive the launch digest, it should match that of what the hardware would produce in the target. I hope I understood your question correctly. Otherwise Alex can perhaps explain better. > > Regards, > > Joerg > > [1] > https://github.com/joergroedel/svsm-governance/blob/main/Meetings/devel-call-2025-03-12.md >
