> On 8 Apr 2025, at 1:41 PM, Gerd Hoffman wrote:
>
> 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 ig
> On 10 Apr 2025, at 4:14 PM, Gerd Hoffmann wrote:
>
> On Thu, Apr 10, 2025 at 12:01:18PM +0530, Ani Sinha wrote:
>>
>>
>>> On 9 Apr 2025, at 11:51 AM, Gerd Hoffman wrote:
>>>
>>> Hi,
>>>
> The chicken-and-egg problem arises if you go for hashing and want embed
> the igvm file in
On Thu, Apr 10, 2025 at 12:01:18PM +0530, Ani Sinha wrote:
>
>
> > On 9 Apr 2025, at 11:51 AM, Gerd Hoffman wrote:
> >
> > 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 f
> On 9 Apr 2025, at 11:51 AM, Gerd Hoffman wrote:
>
> 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 f
> On Apr 9, 2025, at 03:12, Dionna Amalie Glaze wrote:
>
> On Tue, Apr 8, 2025 at 1:33 AM Gerd Hoffman wrote:
>>
>> 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 UK
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
On Tue, Apr 8, 2025 at 1:33 AM Gerd Hoffman wrote:
>
> 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
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 Wed, Mar 26, 2025 at 2:53 PM Gerd Hoffman wrote:
>
> 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 in
On 26.03.25 13:27, Gerd Hoffman wrote:
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 latt
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 measurement?
Parameters itself are fully measured, their presence is, but not their
data. This is
On Fri, Mar 21, 2025 at 11:08:11AM +0100, Gerd Hoffman wrote:
> 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
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 measurement?
>
> Parameters
Hey Gerd,
On 18.03.25 12:11, Gerd Hoffman wrote:
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
On Fri, 21 Mar, 2025, 3:38 pm Gerd Hoffman, wrote:
> 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?
> >
>
On Wed, Mar 26, 2025 at 8:52 PM Alexander Graf wrote:
>
>
> On 26.03.25 13:27, Gerd Hoffman wrote:
> >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
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 24.03.25 18:53, Gerd Hoffman wrote:
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
On Mon, Mar 24, 2025 at 06:53:59PM +0100, Gerd Hoffman wrote:
> 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.
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 24.03.25 16:48, Gerd Hoffman wrote:
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 pre-calculation. Also there is no need to
On Fri, Mar 21, 2025 at 09:22:59AM +0100, Gerd Hoffman wrote:
> 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
> > >
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 pre-calculation. Also there is no need to pass
> > > > aroun
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 pre-calculation. Also there is no need to pass
> > > around any parameters, everything (how the firmware finds the UKI etc)
> > > c
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
On 21.03.25 04:36, Ani Sinha wrote:
On Thu, Mar 20, 2025 at 7:24 PM Alexander Graf wrote:
Hey Gerd,
On 18.03.25 12:11, Gerd Hoffman wrote:
Hi,
Maybe not from the user's point of view, but surely for the vmfwupdate
interface design and for the launch measurement calculations.
When usi
On Thu, Mar 20, 2025 at 7:24 PM Alexander Graf wrote:
>
> Hey Gerd,
>
> On 18.03.25 12:11, Gerd Hoffman wrote:
> >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 par
(Excuse my delayed reply, still suffering from some flu or whatever...)
On Mon, Mar 17, 2025 at 10:56:04AM +0100, Gerd Hoffman wrote:
> Yep. But we have to sort the details.
>
> (1) How we are going to load kernel + initrd in case the firmware is
> igvm? Just update the igvm to also inclu
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 17.03.25 10:56, Gerd Hoffman wrote:
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 end up re-inventing IGVM). How will
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 end up re-inventing IGVM). How will
> > > > the kernel
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 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 par
On Fri, Mar 14, 2025 at 8:47 PM Jörg Rödel wrote:
>
> On Fri, Mar 14, 2025 at 03:08:43PM +0100, Gerd Hoffman wrote:
> > If your input firmware image already is an IGVM (say coconut), what is
> > supposed to happen?
>
> The COCONUT igvmbuilder has the ability to take another IGVM file as
> input an
On Fri, Mar 14, 2025 at 03:08:43PM +0100, Gerd Hoffman wrote:
> If your input firmware image already is an IGVM (say coconut), what is
> supposed to happen?
The COCONUT igvmbuilder has the ability to take another IGVM file as
input and add its directive and contents to the output file. This is
nee
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 .
On 14.03.25 12:27, Gerd Hoffman wrote:
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
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
> > >
On Thu, Mar 13, 2025 at 06:38:44PM +0100, Jörg Rödel wrote:
> 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
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 propose
Hi Ani,
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
Hi Jörg,
On 13.03.25 16:39, Jörg Rödel wrote:
On Thu, Mar 13, 2025 at 08:23:44PM +0530, Ani Sinha wrote:
Note that even with this approach where the hypervisor *thinks* it's
dealing with a real firmware, you can imagine a small rust based
firmware image that is loaded by the guest in the firmwa
On Thu, Mar 13, 2025 at 08:23:44PM +0530, Ani Sinha wrote:
> Note that even with this approach where the hypervisor *thinks* it's
> dealing with a real firmware, you can imagine a small rust based
> firmware image that is loaded by the guest in the firmware region.
> This tiny firmware then jumps t
On Thu, Mar 13, 2025 at 4:57 PM Jörg Rödel wrote:
>
> On Thu, Mar 13, 2025 at 04:39:15PM +0530, Ani Sinha wrote:
> > Right so what we are proposing is generic enough so that if the VM
> > wants to use an IGVM container as opposed to an actual firmware image
> > in a FUKI, that is totally possible.
On Thu, Mar 13, 2025 at 7:01 PM Jörg Rödel wrote:
>
> Hi Gerd,
>
> On Thu, Mar 13, 2025 at 01:05:13PM +0100, Gerd Hoffman wrote:
> > // regions_addr points to an array of this structure
> > struct vmfwupdate_regions {
> > uint64_t size;
> > uint64_t src_addr; // source address (befor
Hi Gerd,
On Thu, Mar 13, 2025 at 01:05:13PM +0100, Gerd Hoffman wrote:
> // regions_addr points to an array of this structure
> struct vmfwupdate_regions {
> uint64_t size;
> uint64_t src_addr; // source address (before update)
> uint64_t dst_addr; // destination address (a
On Thu, Mar 13, 2025 at 04:39:15PM +0530, Ani Sinha wrote:
> Right so what we are proposing is generic enough so that if the VM
> wants to use an IGVM container as opposed to an actual firmware image
> in a FUKI, that is totally possible. Then you need to have that IGVM
> setup the memory in a well
> 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
On Thu, Mar 13, 2025 at 4:57 PM Jörg Rödel wrote:
>
> On Thu, Mar 13, 2025 at 04:39:15PM +0530, Ani Sinha wrote:
> > Right so what we are proposing is generic enough so that if the VM
> > wants to use an IGVM container as opposed to an actual firmware image
> > in a FUKI, that is totally possible.
On Thu, Mar 13, 2025 at 12:27:13PM +0100, Jörg Rödel wrote:
> Fine with me. Just note that supporting the current non-IGVM process for
> confidential guests still causes the implicit ABI issue I mentioned
> before. But not being a KVM/QEMU maintainer I can live with that :)
Small addition: Note th
On Thu, Mar 13, 2025 at 4:29 PM Jörg Rödel wrote:
>
> Hi Ani,
>
> Don't get me wrong, I really like the general idea of vmfwupdate as
> a way to implement BYOFW, and for non-confidential VMs it is great. I
> just think the interface design is not well suited for confidential VMs
> yet and want to
Hi Ani,
Don't get me wrong, I really like the general idea of vmfwupdate as
a way to implement BYOFW, and for non-confidential VMs it is great. I
just think the interface design is not well suited for confidential VMs
yet and want to discuss how to change that.
On Thu, Mar 13, 2025 at 04:02:11PM
On Thu, Mar 13, 2025 at 3:40 PM Jörg Rödel wrote:
>
> Hi Ani,
>
> On Thu, Mar 13, 2025 at 03:07:42PM +0530, Ani Sinha wrote:
> > The state before reset is the state that uses stock firmware from the
> > hyperscaler. The state after reset is a fresh new state that uses the
> > "trusted and known fi
Hi Ani,
On Thu, Mar 13, 2025 at 03:07:42PM +0530, Ani Sinha wrote:
> The state before reset is the state that uses stock firmware from the
> hyperscaler. The state after reset is a fresh new state that uses the
> "trusted and known firmware" from the end user. So the launch
> measurements would no
On Thu, Mar 13, 2025 at 2:40 PM Jörg Rödel wrote:
>
> Hi Ani,
>
> 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
On Tue, 25 Feb 2025 12:00:12 +0100
Gerd Hoffman wrote:
> 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.
> > Pr
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
On Mon, 24 Feb 2025 16:47:31 +0100
Gerd Hoffman 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 o
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 2:09 PM Gerd Hoffman wrote:
>
> 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'
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 make this an
> integration test. o
On Mon, Feb 24, 2025 at 9:17 PM Gerd Hoffman 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
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
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 deploye
68 matches
Mail list logo
