[RFC] td-shim release with reference MRTD

[Xynnn007]

Now to support the full lifetime of confidential containers, we should start to think about the origin of the guest FW/kernel/rootfs. To have a reference, let's start with TDX stack.

Background

Now we have leveraged tdx verifier inside attestation-service. A end user can deploy an attestation-service to verify the quote sent from the attestation-agent inside the TEE guest. However, currently the attestation-service only verifies the validity/endorsement of the quote, s.t. the signature. The other fields, like MRTD, RTMR, etc are left and organized into a parsed claims. Among them, MRTD is related to td-shim. As a community, we should provide a reference solution of this. That is

• Publish td-shim binary every release cycle
• Togetherly, publish reference value (expected MRTD) of this td-shim binary

In this way a CSP could use this community-version td-shim to quickly set up a service, and the end user can use this published reference value to check if the guest firmware is as expected.

Rationality

Although reprodicible build is the most safe way for the user to ensure that no backdoors are embedded in the td-shim binary, there is still some work to do. reference to

• [RFC] td-shim release tagging process #502
• [RFC] Reference Value Generation trustee#187

If users trust the neutral CoCo community, they can directly use the component binaries from CoCo and use the published reference values to verify, without building them locally, which will save a lot of effort.

Roadmap

• Fix the release github action of td-shim
• Using tee-info-hash to calculate the expected MRTD of the td-shim binary to be published
• Leverage the github action to publish td-shim binary and its expected MRTD (reference value) in Sample format
• Use CoSWID or other more standard formats to publish the reference value.

Please give some suggestions. If it seems good, let me open related sub issues to track on this.

[jyao1]

@Xynnn007 , please submit issue and PR.

[Xynnn007]

I have made a test repo to build td-shim and reference values here https://github.com/Xynnn007/rim-generator/releases/tag/v0.1.0

IMO CoCo will have multiple components together with their reference value to be built. Let's take TDX for example:

• td-shim: final-boot-kernel.bin
• guest-kernel: bzImage
• guest-image: kata-containers.img

A first impression is that we use td-shim repo to publish td-shim and its reference value, and we use kata-containers repo to publish guest image and its reference value. However, putting the release processes of these components in different repositories will be unfriendly to users and also hard for community to maintain. Is it a good choice to use a separate repository to maintain the publishment related scripts and artifacts? like https://github.com/confidential-containers/infra or https://github.com/confidential-containers/confidential-containers or a new repo?

@sameo @fitzthum @fidencio @jyao1 @peterzcst @dcmiddle @mythi @arronwy @jialez0

[jyao1]

I am OK if it aligns to other project.

[fitzthum]

I think you're on the right track. My biggest question is how we can integrate reference artifacts with our existing build pipelines. For example for td-shim we use versions.yaml file to track which version will be built into the payload container. Should this also be where we generate reference measurements or should we try to decouple the building of our artifacts from the Kata CI?

Also, are we making some assumptions about how different platforms will measure components? For td-shim I guess we only have to worry about TDX (for now, at least), but for other components, like OVMF I'm a little fuzzy on how we can provide a reference measurement that will be compatible with different platforms or even different hypervisors.

[jyao1]

OVMF can support one binary for TDX/SEV/non-CC.

[Xynnn007]

I think you're on the right track. My biggest question is how we can integrate reference artifacts with our existing build pipelines. For example for td-shim we use versions.yaml file to track which version will be built into the payload container. Should this also be where we generate reference measurements or should we try to decouple the building of our artifacts from the Kata CI?

I think we get the same question. There are two ways

1. We integrate the reference value calculation part to current Kata CI.
2. We use a separate repo (a new one or like https://github.com/confidential-containers/confidential-containers) to maintain all the artifact releases, related GHA and scripts.

As we are planning to make a website for CoCo, it would be great to have a download page that points to the hyperlink of the artifacts together with their reference values. Thus I prefer to way 2.

I'd also like to hear some point views of @fidencio for this.

Also, are we making some assumptions about how different platforms will measure components? For td-shim I guess we only have to worry about TDX (for now, at least), but for other components, like OVMF I'm a little fuzzy on how we can provide a reference measurement that will be compatible with different platforms or even different hypervisors.

A reference value does not necessarily correspond to one component, it may correspond to multiple components, which depends on how TEE measures. For example, TDX measures guest firmware like td-shim/OVMF and store the measurements into MRTD register. Thus in RVPS we use key tdx.quote.body.mr_td to look up the reference value. However, SNP measures OVMF/kernel/kernel cmdline/guest rootfs togetherly and store the measurement into one register measurement. Thus in RVPS we use key snp.measurement to look up the reference value for a combination of OVMF/kernel/kernel cmdline/guest rootfs in RVPS.

This hints that we should release a binary bundle for different platforms together with the reference values. Back to the question itself. If we release a same OVMF binary for both TDX/SEV, we would have two reference value files for each platforms.

Other platforms should have their different mechanisms but we can fit well with the design.

[fitzthum]

I think we get the same question. There are two ways

Some components, like OVMF, seem like they could be decoupled from the Kata build system fairly easily. To me it seems a bit weird that Kata is building OVMF. Other components, like the rootfs, are more closely tied to Kata and would be tricky to replicate elsewhere. I suspect that Kata is somewhat attached to building components themselves, which does enable some significant tooling such as the kernel patching/building scripts.

On the other hand, we also have the image buiders for peer pods, which already duplicate some of the functionality of the kata tooling. That's another place we'll need to come up with some reference values.

This hints that we should release a binary bundle for different platforms together with the reference values.

Yeah, I agree. Reference values will have to be platform specific.

Btw this is something that igvm might be able to help out with.

[jyao1]

Btw this is something that igvm might be able to help out with.

I filed #610 for IGVM.
Does KVM/QEMU support IGVM format? or Hyper-V only?

[fitzthum]

Does KVM/QEMU support IGVM format? or Hyper-V only?

I don't think there is QEMU support yet, but I've heard a rumor that someone is working on it.

Hyper-V as well as CLH seem to be supported. There is some info here.

[fitzthum]

Btw another thing about the current release process is that the tagging of releases, which is typically done whenever we reach that step in the release checklist, is not really in sync with development. We just come through and tag the repo whenever the CoCo project happens to be doing a release. So far this doesn't seem to have caused any issues, but it doesn't seem ideal.