Hey Alex,
On Thu, Mar 13, 2025 at 05:30:30PM +0100, Alexander Graf wrote:
> I have a few concerns with IGVM:
>
> 1) Parsing is non-trivial. Parsing them in QEMU may open security issues.
There is an IGVM parsing library under MIT license and written in Rust
with C-bindings. The currently proposed IGVM support patches for
QEMU also make of it as well as (I believe) the implementations in the
two other hypervisors I am aware of.
That it's written in Rust is no guarantee that there are no issues, but
certain classes of common security bugs should already be avoided by
that.
> 2) Their data structures are tied to the target CPU structures like VMSA
> which FWIW are not fully owned by QEMU, are they?
Yes, those data structures are aligned with what the hardware consumes.
That makes it a lot easier to pre-calculate the launch-measurements, as
the tooling just needs to hash what is in the file without constructing
the hardware representation first.
Not sure what you mean by "owned by QEMU", all data in the IGVM file is
at least _consumed_ by QEMU and KVM to build the initial memory image of
the CVM. Once the CVM is launched all of the data belongs to the guest.
> 3) I don't want to allocate a bounce buffer for an IGVM in the hypervisor.
> So we would need to ensure that the memory allocated by the loader for the
> IGVM does not overlap any memory the IGVM wants to consume. If the loader
> considers the IGVM as opaque, that is difficult to achieve.
Right, I think that is a reasonable constraint that should be built into
the vmfwupdate protocol. The placement of the file in guest memory must
not overlap with any memory region that is deployed by the file. That
saves QEMU from the copying and allocating the space on the host side.
Regards,
Joerg
