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 in this model, how are we passing the hashes of kernel, initrd and cmdline?
Are they going to be part of the firmware image as was previously thought?
Either scratch the idea of using hashes to verify kernel + initrd +
cmdline and use a secure boot signed UKI instead, or use IGVM firmware
images and add the kernel hashes page to the igvm.
It's a nice idea to have a firmware IGVM file that contains a signature, so
you can for example have a RHEL provided IGVM that only runs UKIs that are
signed by Red Hat.
Yep, that is what should be possible when all this is ready.
- Attestable Bootable Containers. In that case, the command line contains
a hash of the target fs-verity protected partition. Red Hat can not be the
entity signing that UKI. It must be the user.
Well, add-ons have been created to address exactly that: Allow the UKI
being configured without changing it, so the UKI can be signed by redhat.
You'll go add user-signed add-on for the command line.
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.
- Add-ons. How do you provide a "debug add-on" and prevent it to gain any
access to confidential data?
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.
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.
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. Or even a full variable
store blob. Then a built-in always-on UEFI Secure Boot that runs in
kernel mode rather than SMM. The IGVM should dictate the physical
location of that blob so that you can precalculate the launch digest
with the blob included. Ukify.py then generates the blob along with the
FUKI.
That can absolutely integrate more deeply into UEFI and be actual PE
hashes rather than the icky thing the OVMF code does today.
How the measured opaque blob is actually used is not something
vmfwupdate needs to care about.
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.
All unauthenticated data, such as locations of the UKI and its add-ons
gets passed as parameter to the firmware IGVM.
But we need to support a way to embed the hash in the ukify.py
generated IGVM on the fly. With add-ons, maybe even multiple ones.
I'd prefer not patch the IGVM on the fly at boot time.
Does the flow above align with your preferences? :)
Alex
