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.
Works nicely for me. Test case: https://kraxel.gitlab.io/uefi-tools-rs/seabios.efi > +Fw-cfg Files > +************ > + > +Guests drive vmfwupdate through special ``fw-cfg`` files that control its > flow > +followed by a standard system reset operation. When vmfwupdate is available, > +it provides the following ``fw-cfg`` files: > + > +* ``vmfwupdate/cap`` (``u64``) - Read-only Little Endian encoded bitmap of > additional > +* ``vmfwupdate/bios-size`` (``u64``) - Little Endian encoded size of the > BIOS region. > +* ``vmfwupdate/opaque`` (``4096 bytes``) - A 4 KiB buffer that survives the > BIOS replacement > +* ``vmfwupdate/disable`` (``u8``) - Indicates whether the interface is > disabled. > +* ``vmfwupdate/bios-addr`` (``u64``) - A 64bit Little Endian encoded guest > physical address This is out of sync with the actual code (vmfwupdate/bios-addr does not exist there). Also this adds five fw_cfg files. Given that the number of fw_cfg files we can have is limited I'm not convinced this is the best idea to move forward. Alternatives I see: (1) Place everything in a single fw_cfg file. ramfb does this for example, the guest writes a struct with a bunch of values. (2) Go for a mmio register interface. The EFI variable store I'm working on does this. fw_cfg is used for hardware discovery, via etc/hardware-info file (which can carry entries for multiple devices). See https://lore.kernel.org/qemu-devel/20250219071431.50626-2-kra...@redhat.com/ and https://lore.kernel.org/qemu-devel/20250219071431.50626-21-kra...@redhat.com/ (v4 has a double-free bug in patch #1 which will be fixed in v5 of the series). take care, Gerd
