On Mon, 24 Feb 2025 16:47:31 +0100 Gerd Hoffman <kra...@redhat.com> wrote:
> 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/ After looking at it, it seems to me that data will be in host byte order and guest has no idea what that is. Probably it should advertise byteorder as part of the structure, and guest side should then do conversion if necessary. > 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 >
