Re: RFC i386/sev: kernel-hashes, reference measurements and event logs

[Dionna Amalie Glaze]

On Mon, Feb 12, 2024 at 12:57 PM James Bottomley <jejb@linux.ibm.com> wrote:
>
> On Mon, 2024-02-12 at 12:16 -0800, Dionna Amalie Glaze wrote:
> > This is not a patch but it felt inappropriate to derail a recent
> > patch that's just refactoring the kernel-hashes object_class_property
> > definition. Apologies if this has been discussed before, as I'm not
> > particularly active here.
>
> I haven't seen that patch, but I presume it's not relevant?
>
> > Regarding kernel-hashes, how is that load-time information passed
> > along to the guest beyond, say, OVMF? Can we require that these
> > hashes
> > are also present in fw_cfg so they can be read from the kernel? In
> > Linux it'd be nice to have /sys/firmware/qemu_fw_cfg/sev_kernel_hash,
> > /sys/firmware/qemu_fw_cfg/sev_cmdline_hash,
> > /sys/firmware/qemu_fw_cfg/sev_initrd_hash
>
> Are you referring to measured direct boot?  In that case, there's no
> point having hashes in the fw_cfg, because OVMF in the guest needs to
> hash the kernel itself and then compare to a trusted source (which the
> fw_cfg file wouldn't be because it's under the control of the

I'm not suggesting that OVMF uses the fw_cfg files to check, just to
use an interface that is readable by the guest OS. If the values are
wrong, then you can't reconstruct the measurement in the attestation
report and the host just DoSes the guest, which is already possible
without this change.

> hypervisor).  For SEV, the trusted source is a table in the launch
> measured ROM, but I'm sure TDX does something similar.

TDX measures information after launch into RTMRs, which SEV-SNP doesn't have.

>
> > I'm working on how to use standard document formats for providing
> > reference measurements of the Google Compute Engine virtual firmware
> > for remote attestation, and these hashes have an impact not just on
> > the measurement but on the entire model that the IETF RATS working
> > group is considering for authorizing attestation measurements.
> >
> > If you're assembling a VM launch configuration with firmware provided
> > by a trusted vendor (say Google), and your hashes are passed in from
> > an API, there's no easy rendezvous to state that the combination
> > produces the expected hardware measurement. This makes adding
> > kernel-hashes support unappetizing, since it makes the hardware
> > attestation report's measurement have no meaning, or at least, it
> > makes life difficult for people trying to assign it meaning.
>
> Well, no, since firmware tends to update on a longer timeframe than the
> kernel and the cmdline and initrd tend to have quicker update cycles

This is not true of our environment, where every release of the
hypervisor includes a fresh build of the firmware, which may have
codegen differences for multiple reasons. We don't have a way to
announce ahead of time which firmware an instance will get for them to
sign an initial measurement derived from it.

> than the kernel.  Thus there's no one golden reference.  Instead you
> give a tool (say the virtee sev_snp_measure tool
>
> https://github.com/virtee/sev-snp-measure
>
> ) the hashes of the firmware, kernel, command line and initrd and it
> caclulates the expected launch measure

Yes indeed, I've written one myself. Publishing it has been a bit
Kafkaesque as opposed to the go-sev-guest and go-configfs-tsm
libraries.
The problem is still preauthorization when it'd be much more
preferable to authorize components of a measurement and derive the
SEV-SNP attestation from the components.

>
> > The measurement is the product of two different entities as assembled
> > by the VMM given a trusted firmware and the kernel hashes. It's a bit
> > of a sandwich of (GCE) core firmware, (User) SEV hashes, (GCE) BSP
> > VMSA, AP VMSA*.
> >
> > When you collect "evidence" to verify locally or pass along to a
> > verification service, you need more than just the hardware
> > attestation report to make sense of the combined bits. You have a PCR
> > situation like with TPM, so you need an event log for these different
> > aspects of the ultimate measurement. There is no event log for this
> > -kernel-hashes construction.
>
> That's because it's a pre-launch measure.  The TCG log is only for post
> launch.  The idea being those values are needed for you to approve
> something in pre-launch, like key release, before the TPM starts
> running.
>
> That's not to say we shouldn't have log entries for pre-launch, but
> that's a generic problem and not specific to measured direct boot.
>

Okay, do you know which direction the solution is moving? I know
there's a measured TPM firmware change proposed to the TCG, but that's
a bit too specific.

> > We can use the TCG TPM event log to post EV_NO_ACTION events about
> > the PlatformRIM, specifically, to point at a UEFI variable that we
> > populate to store our signed document about the expected measurements
> > with the Qemu-SEV-SNP-boot-protocol, but I don't see how we might
> > collect the kernel-hashes values as extra evidence to combine and
> > derive the attestation report's MEASUREMENT field to accept
> > "evidence" objects for the core firmware component and the kernel
> > hashes component.
>
> This sounds like a first measurement thing.  In many ways, the pre-
> launch measurement is equivalent to the SRTM of a physical system which
> is collected in the EV_S_CRTM_* events.  But for that to happen, I
> think the TCG would have to bless it in some form.
>

Is that the pathway you'd recommend? I'm not sure a new EV_S_CRTM_*
event for each SEV hash table entry for Qemu (say) is going to be
ratified.

> James
>
> > So my question is if this feature is to be a long term feature, how
> > do you expect to collect the SEV hashes as a separate evidence object
> > to play nicely with IETF RATS?
> >
> > Is this a long term feature, or are we expecting it to be deprecated
> > by SVSM?
> >
> > I've tagged in people in CC that I could imagine would have something
> > to say about this.
> >
> > Thanks y'all
> >
> > --
> > -Dionna Glaze, PhD (she/her)
>


-- 
-Dionna Glaze, PhD (she/her)