Open source OVMF binaries

[andy-ab]

Do you open source the code for your OVMF binaries within gs://gce_tcb_integrity/ovmf_x64_csm/ in a way that could be reproduced (ideally byte for byte)?
Could you provide the version of the TDX Module code so we can request the source code from Intel?
Running this produces the wrong MRTDs for Google Cloud OVMF binaries. Could you comment?
Why do RTMR[0,1] change on Google Cloud when launching the same image with different machine sizes?

[DionnaGlaze · Accepted solution]

> Do you open source the code for your OVMF binaries within gs://gce_tcb_integrity/ovmf_x64_csm/ in a way that could be reproduced (ideally byte for byte)?

Not currently. And while we can try to achieve reproducible builds, it's not a durable property without also debugging any non-determinism that comes from upstream EDK2 after a rebase, or from any other toolchain updates. I'd like to at least provide SLSA provenance with at least one verified summary attestation run on the public sources.

TDX Module code and signed binaries are from Intel https://github.com/intel/tdx-module. I haven't yet tried to reproduce the MRSEAM from the signed binary, though it should be a matter of inspecting SEAM_SIGSTRUCT.MRSEAM.. though Section 3.1 of "Intel® Trust Domain Extensions - SEAM Loader (SEAMLDR) Interface Specification" provides no definition of MRSEAM. Perhaps it's SEAMHASH.

How are you determining which firmware you want to calculate the MRTD from? If you're downloading the signed measurements as derived from the MRTD value, and the MRTD isn't present in the file, that's a bug. I'd like to know which one that is.

If you're getting the signed measurement from the MRTD, and it's there, and you're downloading the firmware it points to and are trying to recreate the MRTD using the gce-tcb-verifier, I'd like to know which that is, the command you're using to create a TDX VM that exhibits this MRTD that differs from expectations, and the way you're using the library to recompute the MRTD.

The RTMR bit I can answer: https://github.com/tianocore/edk2/blob/7e7492fa12fa924e4e3699ecf1e456e1f641dea4/OvmfPkg/IntelTdx/Tdx... the TDHOB gets measured into RTMR0. And  you can see from the gce-tcb-verifier code that the TDHOB is constructed with memory range descriptions that differ based on machine shape due to NUMA node sizes and RAM scaling based on standard/highmem/highcpu profiles. A recent release of the hypervisor should have corrected the mistake that measures TDHOB into the MRTD.

We don't make any specific guarantees about the RTMR measurements yet. The CoRIM specification is incomplete, and there's no profile yet for signing specific CCEL event records.

[jm9a8a]

Is my understanding correct, then, that we ultimately must trust Google's OVMF binaries to be non-compromised? My understanding of the benefit of Confidential Computing was that the trust boundary (mostly) shifts from the cloud service provider to the hardware manufacturer. But, if we have to have faith in the OVMF binary, then that doesn't really happen. Of course, it's still a reduction in trust because OVMF is a much smaller surface... but still.

Let me know if I'm thinking about this incorrectly.

[DionnaGlaze]

There is considerable difficulty in satisfying different users' risk appetites with a single firmware binary, and a single firmware build is what we have scoped. Expanding that scope is possible with enough customer demand, so if it's enough to block your spending on GCP, then do register those deal blockers with your sales representative. You may find my discussion of the costs that need business justification to pay for from my talk at the Confidential Computing Consortium https://www.youtube.com/watch?v=1pHFN97XIpo

For the time being, our firmware releases are signed, so you can at least be assured that you are getting institutionally-endorsed firmwares that have gone through all of our qualification and governance policies, and not one-offs that could be construed as a targeted attack.