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?
Regards,
Joerg
[1]
https://github.com/joergroedel/svsm-governance/blob/main/Meetings/devel-call-2025-03-12.md
