On Wed, Mar 26, 2025 at 8:52 PM Alexander Graf <g...@amazon.com> 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 a
> >> one-off fashion.
> >>
> >> I don't think "signing" is the correct way to address the latter. It's
> >> rather hashing. But I agree with you that it could (should?) be hashing at
> >> the PE loader level similar or identical to Secure Boot rather than a
> >> separate hashing mechanism.
> > Secure boot offers signing and hashing. You can add both signing
> > certificates and authenticode hashes to 'db'.
> >
> >>> Not sure I understand the point you are trying to raise. Add-ons
> >>> signatures are checked too.
> >> 2 points here here:
> >>
> >> 1) With add-ons, there are multiple binaries. We can't only pass a
> >> single
> >> one.
> > Sure. You'll go need some container, say a cpio archive, but that is
> > something vmfwupdate loader and loaded firmware have to agree on and not
> > something we have to worry about too much for the vmfwupdate interface
> > design.
> >
> >> 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 user needs to have the chance to differentiate
> >> between a system booted with or without verbose kernel output.
> > You easily get that by looking at the vTPM measurements. So not sure
> > what you are asking for, do you want be able to also do that without a
> > vTPM?
>
>
> All of this should work without vTPMs. Why add complexity when you don't
> need it? The industry is already struggling to deal with TPMs alone.
> There are way too many potential holes in a solution where you first
> have to reason about the integrity of your TPM before you can trust it.
> All of the vTPM in SEV-SNP talk is a house of cards I'm happy to push
> (blow to keep the analogy?) against as hard as I can.
>
>
> >
> >>>> So we need some equivalent of a hash page.
> >>> Ok. So two opaque blobs, one which is measured into the launch
> >>> measurement and one which is not? That gives you the option to pass
> >>> around hashes (or any other data) and leave a trace in the launch
> >>> measurement should you need that.
> >> Yes, I think you want to have one or multiple pages with what effectively
> >> is
> >> a db append variable update blob.
> > Makes sense to me.
> >
> >> Or even a full variable store blob.
> > Hmm, not sure. I'd rather go for passing efi signature database
> > appendix, probably for both allow ('db') and deny ('dbx'). That is
> > going to work better I think, variable store format is an
> > firmware-internal implementation detail I'd avoid encoding that in
> > some interface.
> >
> >> The IGVM should dictate the physical location of that blob so that you
> >> can precalculate the launch digest with the blob included.
> > Hmm, right. Physical location matters for the launch measurement, so
> > adding opaque_measured_addr to struct vmfwupdate isn't going to work
> > very well.
> >
> >> Ukify.py then generates the blob along with the FUKI.
> > Doesn't fly from a distro point of view. The UKI is signed, so RH ships
> > that and the customer can't modify it to update the blob, say with some
> > additional hashes for 'db'.
>
>
> I don't follow. Is RH going to ship a UKI or a FUKI? And if RH ships the
> UKI, ukify could still take a UKI as input and generate a FUKI based on
> it, no? During that process, it would generate a db which gets put at a
> fixed location in RAM so the (RH provided) firmware picks it up and
> validates the UKI it loads is exactly that one UKI.
>
> We can extend that with an additional signature flow, where the ukify
> generated db contains a signature for the UKI instead. But I would
> generally advise against optimizing for certificate based flows until
> revocation is sorted out. And since revocation requires a new dbx in
> this scheme and that means a different launch digest per revocation, you
> may as well just directly only use hashes.
>
>
> > Effectively we need something roughly equivalent to shim's MokList. The
> > distro ships a default configuration (like the cert compiled into the
> > shim binary) which works fine for most people. For IGVM that would be a
> > default efi variable store compiled into the firmware binary.
>
>
> This only makes sense in a world where RH ships an SVSM and that's all
> you want to attest. But that's a different flow from what we describe
> here. To actually get workload attestation, you need to include your
> rootfs in the attestation. And the only entity that can do that is the
> end customer. And they will typically do that through something like
> dm-verity or fs-verity and a hash provided on the kernel command line.
>
>
> >
> > If you need additional stuff (like the signer cert for the nvidia
> > driver) there must be some way to add hashes and certificates to db/dbx.
> >
> > Does it make sense to simply move the firmware update sections from the
> > main UKI to an add-on? That would allow customers to easily use their
> > own if they wish, without breaking the RH signature on the UKI.
>
>
> I'm still not convinced "RH signature" is a useful marker at execution
> time of confidential workloads. It may be an interesting one at assembly
> time, but after that we're folding everything into a single launch
> digest anyway, for good reasons.
>
>
> >
> >> I agree, from a vmfwupdate point of view, we would basically have an IGVM.
> >> The IGVM describes 2 special page (ranges?): One for the CPUID special
> >> page,
> >> one for the variable store seed. To precalculate the launch digest you
> >> would
> >> need the firmware IGVM, and the seed blob.
> > Guess we'll have to update the IGVM format spec for that, so we have
> > page types for 'db' and 'dbx'. With that it should be possible to load
> > the igvm, find + update the pages + write it out again. Then wrap it
> > into an UKI add-on + copy to ESP.
> >
> > RH default igvm/add-on would simply have empty 'db' and 'dbx' pages.
> >
> > Looks workable to me.
>
>
> I would personally consider the "RH binary adds RH signature into binary
> by default" a backdoor, but that's you call :).
>
> I agree with the plan to amend the IGVM spec with the UEFI variable
> update page. I don't think it should be "db" and "dbx" pages. It should
> be a more generic. In fact, why not make it a loader UEFI (PE) binary?
> The binary installs the db/dbx updates and chain loads the actual
> payload UKIs using a file format that's private between the loader
> binary and the sd-boot stub.
>
>
> >
> >> All unauthenticated data, such as locations of the UKI and its add-ons gets
> >> passed as parameter to the firmware IGVM.
> > i.e. have a IGVM parameter for opaque_addr + opaque_size instead of
> > placing this in the vmfwupdate struct?
>
>
> It would be a pretty natural fit for it, no?
>
>
> >
> > take care,
> > Gerd
> >
> > PS: in Berlin tomorrow?
>
>
> Yup, let's sync up! :)
Unfortunately I won't be there. Vitaly will be. So you three can sync
along with anyone else who is there. We should have a call after for
those who are not lucky to be attending.
