Hi,
> > The chicken-and-egg problem arises if you go for hashing and want embed
> > the igvm file in the UKI.
>
> I don't really see how signing the IGVM file for secure boot helps anything.
It doesn't help indeed. This comes from the original idea by Alex to
simply add a firmware image to th
Hi,
> > Well. If you want put the db into the igvm and the igvm into the uki
> > you've got a chicken-and-egg problem. Moving the firmware from the main
> > UKI to UKI add-on would solve that.
>
> Why is embedding a public key that will sign the IGVM in the IGVM a
> chicken-and-egg problem? I
Hi,
> Which means we are back to the single firmware image. I think it makes
> sense to continue supporting classic rom images (which can also be
> loaded via -bios). Any use case which needs more fine-grained control
> must use igvm. We can use format bits in both capabilities and control
>
On Thu, Mar 20, 2025 at 09:34:26AM +0100, Jörg Rödel wrote:
> On Tue, Mar 18, 2025 at 12:11:02PM +0100, Gerd Hoffman wrote:
> > Open questions:
> >
> > - Does the idea to use igvm parameters for the kernel hashes makes
> >sense? Are parameters part of the launch m
Hi,
> > >2) The security posture of the system may be different between 2
> > > validly
> > > signed images. Think of Daniel's example of verbose kernel output. Maybe I
> > > consider verbose kernel output already inacceptable, while RH thinks it's
> > > an
> > > ok posture to have. The us
Hi,
> The problem is that add-ons are
>
> 1) Separate binaries. So you need to match multiple files.
> 2) In this case, get generated out of the vendor (RH)'s control in a
> one-off fashion.
>
> I don't think "signing" is the correct way to address the latter. It's
> rather hashing. But I
Hi,
> > While digging around in the igvm spec I've seen there is the
> > concept of 'parameters'. Can this be used to pass on the memory
> > location of kernel + initrd + cmdline? Maybe the kernel hashes too?
>
> The find the locations of the kernel, initrd, cmdline, ... I thin
On Mon, Mar 24, 2025 at 05:31:30PM +0100, Alexander Graf wrote:
>
> > > > > What does all this mean for the hypervisor interface ?
> > > > That means we'll go scratch the region list idea and depend on igvm
> > > > instead.
> > > > Which means we are back to the single firmware image.
> > > So i
On Mon, Mar 24, 2025 at 04:42:28PM +0530, Ani Sinha wrote:
> On Mon, Mar 24, 2025 at 1:13 PM Gerd Hoffman wrote:
> >
> > Hi,
> >
> > > > Going ship the distro kernel as igvm image would work too. Will
> > > > simplify the measurement pr
Hi,
> > Going ship the distro kernel as igvm image would work too. Will
> > simplify the measurement pre-calculation. Also there is no need to pass
> > around any parameters, everything (how the firmware finds the UKI etc)
> > can be arranged at igvm build time then. Disadvantage: This introd
Hi,
> I think if we want to embrace IGVM, we should embrace it fully and make it
> replace the region list. At the end of the day, IGVM is effectively a region
> list plus data.
>
> How difficult would it be to put up a prototype that uses only IGVM as
> vmfwupdate payload? We can definitely a
Hi,
> Maybe not from the user's point of view, but surely for the vmfwupdate
> interface design and for the launch measurement calculations.
>
> When using igvm parameters for the kernel hashes we need to pass on (at
> least) two items via vmfwupdate API: The igvm image itself and the
> kernel
Hi,
> > (1) How we are going to load kernel + initrd in case the firmware is
> > igvm? Just update the igvm to also include linux kernel and
> > initrd (see parallel reply from Jörg)? If so, how does the
> > launched firmware find the kernel + initrd?
> > While diggin
On Fri, Mar 14, 2025 at 03:50:19PM +0100, Alexander Graf wrote:
>
> On 14.03.25 15:08, Gerd Hoffman wrote:
> >Hi,
> >
> > > > Ok, assuming we allow the guest submit a IGVM image (which makes sense
> > > > indeed, otherwise we'll probably e
Hi,
> > Ok, assuming we allow the guest submit a IGVM image (which makes sense
> > indeed, otherwise we'll probably end up re-inventing IGVM). How will
> > the kernel hashes be handled then? I assume they will not be part of
> > the igvm image, but they must be part of the launch measurement .
Hi,
> > > Open question is what we do about IGVM.
> > >
> > > One option would be the guest vmfwupdate tool loading and parsing igvm,
> > > preparing the region list, then invoke the update. Problem is that some
> > > igvm feaures such as initial register state can not be easily supported
> > >
> The devil lies in "same order of setup calls". Without a way to define
> this order through the vmfwupdate interface there is a lot of implicit
> knowledge required about how KVM/QEMU setup the TEE context to calculate
> the expected after-reset launch measurement. Even worse, the exact way
> thi
Hi,
> > 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 sh
Hi,
> > Part of the verification process can be that you already copy the
> > firmware to a host buffer.
>
> I think we decided early on that we would not want to do that - that
> is consume extra memory on the host side for boot components.
Fine with me, was just an idea, certainly not critic
On Tue, Feb 25, 2025 at 10:51:08AM +0530, Ani Sinha wrote:
> On Mon, Feb 24, 2025 at 9:17 PM Gerd Hoffman wrote:
> >
> > 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
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
> par
Hi,
> +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
Hi,
> AFAIU 'true' is the behavior you are proposing with your EFI changes?
> Saying that what's the difference between 'false' & 'default' wrt EFI
> firmware? Just wondering do we need default?
true/false will force the one or the other no matter what.
'default' allows the firmware to choose
On Mon, Jun 20, 2022 at 10:33:00PM +, Dionna Glaze wrote:
> For SEV-SNP, an OS is "SEV-SNP capable" without supporting this UEFI
> v2.9 memory type. In order for OVMF to be able to avoid pre-validating
> potentially hundreds of gibibytes of data before booting, it needs to
> know if the guest O
24 matches
Mail list logo
