Delegate measurement information to TCG standards

[deeglaze]

Hi y'all, I'm not particularly familiar with this format but did learn from Jon Lange on the SVSM call that this is carrying measurement-specific data. I'd like to see what we can do about delegating those measurement specifics to the reference integrity manifest (RIM) information model that you can feed through the SP800155 unmeasured event type. The IETF is working on standardizing a CBOR-based actualization of the information model to deprecate the signed XML format the TCG previously specified, which they call CoRIM.

If IGVM can be expanded to specify QemuFwCfg file contents, then we can pass along signed IGVM measurement information to the user through a standard channel via the tcgSp800155PlatformIdEvent3 unmeasured event added in the TCG PC Client Platform Firmware Profile Version 1.06 Revision 52. Say we pass in the events via etc/sp800155evts, vis a vis https://github.com/tianocore/edk2/pull/5738.

I don't know how "generic" IGVM needs to be, since QemuFwCfg is something we use in our non-Qemu VMM at Google. Is this something y'all think is within IGVM's scope?

[chris-oo]

I'm not too familiar with QemuFwCfg files, how do those get exposed from the host to the guest? Are those via some shared guest physical address, or exposed through something else? I could see us describing some payload data that the host could report via QemuFwConfig via some new header type, as long as we define it as optionally ignored for platforms that do not need/support it.

I'm not against adding standard measurement information to the file. The intention of IGVM is that it's host virtstack and guest OS generic, so if there's some TCG measurement log that's based on the initial contents of guest memory and cpu state, then I think we could include it.

What does CBOR mean?

[deeglaze]

QemuFwCfg is not entirely necessary to be part of the specification of IGVM so long as the intended meaning of the data blob is in-tact. We need some unmeasured channel for providing the SP800-155 information to the TCG or CC event log. The format of that data I've kept as a mix between the UEFI Platform Initialization definition of an EFI_HOB_GUID_TYPE and the TCG PC Client Platform Firmware Profile definition of a TCG_Sp800_155_PlatformId_Event2 or TCG_Sp800_155_PlatformId_Event3 just for the read into a created hob to avoid having to allocate temporary memory before populating the hob data. It is a bit redundant as a representation since it will always have HobType = 4 and Guid = gTcg800155PlatformIdEventHobGuid.

If the goal is not to even reference UEFI, then the TPM firmware profile for UEFI is irrelevant. Still it would be nice to at least have some notion of reference values that can be passed along however the host virt stack determines. I don't see the virt stack independence respected given the all the Vbs specifics in the implementation. I would more expect to see a Content Media type and a binary blob in something tagged "reference measurements" for the virt stack to interpret. Your Vbs measurements can then be application/vnd.msft.vbs-measurements or however you decide to assign it a media type.

[chris-oo]

I think i've misunderstood - you're proposing we embed QemuFwCfg (it's like a defined filesystem format/volume?) for the host to be associated with a given IGVM file? And in that, a file builder could put whatever it wants (like measurements, TCG logs, etc)? And this isn't related to whats deposited into the guest at launch time, but could be provided afterwards via other channels?

[deeglaze]

The QemuFwCfg is an implementation detail for the VMM to provide some configuration values post-launch through a relatively simple interface https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c

So for a firmware to express that it should be presented with this SP800155 data through a specific protocol that Qemu (and other VMMs) implements, I'm not sure how we express that with IGVM. The implementation itself is expecting this data, but the implementation may be implemented to expect any number of protocols depending on the host VMM it's able to determine through a protocol.

At the most basic level, I'd like for signed measurements to be expressible in some earmarked blob with a given content type so the hypervisor can extract whatever meaning it needs from it to pass along that information about the firmware it's launching.

[chris-oo]

I think there's two orthogonal questions/decisions here:

1. Report an industry standard measurement (CoRIM?) via a new header type for any given platform.
2. Add the ability to embed a QemuFwCfg (or some sort of filesystem?) for arbitrary data the host can use, and also potentially expose to the guest, via a new header type.

I think that (1) is completely reasonable and great to include. I'm not yet sold on (2). For this specific usecase, couldn't the VMM decide what it wants to expose if it had access to (1)?

[deeglaze]

Yes, I think I'm only really asking for something like (1), but not even require a format. The header would indicate the section is meant for measurements, and it has an optional string for the format as an IANA Media Type, and the payload as a byte string.

[chris-oo]

Putting things into code, something like:

struct IGVM_MEASUREMENT_HEADER {
typ: MeasurementType, //non-exhaustive
payload: FileOffset,
}

#[repr(u32)
enum MeasurementType {
CoRIM,
SomeOtherFormat, 
}

Basically, you want some way to be able to embed whatever measurement data you want without needing an igvm spec revision?

[deeglaze]

I think for MeasurementType I'd have MediaType(String) instead of CoRIM, SomeOtherFormat in order for the payload to be more open-ended without needing to change the IGVM representation at all. Note CoRIM is planned to have IANA assign the media type application/corim-signed+cbor

[chris-oo]

At that point, should we just say "This header describes a null terminated string in the file_data section to be parsed as JSON/something/whatever, intended to be used for measurement"?

[deeglaze]

I don’t expect the payload to be a null-terminated string, no. But the header is meant for signed reference measurements.

[chris-oo]

While we provide a rust interface to the standard via igvm ultimately the structures are binary defined by igvm_defs. I guess the string need not be null terminated, we could encode both the starting file_offset and length.

I think I've misunderstood though, you want both the identifier to be a string, and then the payload to be variable length, and it for to be just for measurements? So the string would define the measurement type (id of some sorts), then the payload would be up to the loader to figure out how to parse that, and I assume we'd link to some common types for given names with their corresponding specification?

[deeglaze]

Correct

[chris-oo]

Sorry back from vacation now - do you want to propose a draft PR to igvm_defs or would you like me to? I should be able to find some time for this later this week.