On Mon, Feb 24, 2025 at 9:17 PM 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
yeah if I can't get my unit test working we can make this an integration test. or best case scenario, we can have both. > > > +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). The actual implementation detail can vary slightly with the spec no? I will try to bring them as close as I can. > > 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. Right, For implementation, I suggest we combine FILE_VMFWUPDATE_OBLOB and FILE_VMFWUPDATE_FWBLOB together and also make FILE_VMFWUPDATE_CONTROL part of the same structure. These are all writable by the guest so makes sense to have one fwcfg for it. We can have another read-only fwcfg for FILE_VMFWUPDATE_BIOS_SIZE and FILE_VMFWUPDATE_CAP. Alex, what do you think? > > 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 >
