search

google / gce-tcb-verifier

Reference code for creating and verifying a GCE firmware signed reference value message.
Apache License 2.0
9 stars 2 forks source link

OVMF source code and binaries #38

Open eduardolfalcao opened 4 weeks ago

eduardolfalcao commented 4 weeks ago

Hello @deeglaze

I would like to reproduce the measurements of Intel TDX (MRTD) and AMD SEV-SNP (launch_measurement) CVMs, and I just came across your repo. You mentioned, "Google publishes its production virtual firmware binaries." However, I didn't find the OVMF code or binaries in your repo or any information about where to obtain them.

Could you help me by showing me where it is located? Does Google use the OVMF provided by the EDK2 project (https://github.com/tianocore/edk2) for SEV SNP and TDX CVMs? If so, which version do they use in production?

Regards

deeglaze commented 4 weeks ago

The OVMF code is not yet published. We still build our production virtual firmware with an internally managed clang toolchain and "blaze" (the monorepo version of bazel), so it diverges a fair amount from tianocore/edk2 with respect to producing the bits. If we publish the code with the intention of showing the full build attestation from a public toolchain container, then we either maintain a weird build process or shift over to using stuart_build and all the submodule fun there. It's a significant slog that I haven't had time get allocated to yet. Not to mention ovmf upstream does not have reproducible builds. We'd need to dig into that more to make the transparency story better, since even with verifiable build attestations, folks wouldn't trust our builder to do what it said from the inputs. Sooo the inputs themselves need to lead to the same outputs regardless of which build platform runs the container. Doable work not yet done.

The firmware binaries are in a GCS bucket that I've been waiting for approval to add public readability to for several months, but it should happen soon (TM). Binaries are reverse-engineerable but certainly that's not a particularly compelling transparency story just yet.

deeglaze commented 4 weeks ago

Does Google use the OVMF provided by the EDK2 project (https://github.com/tianocore/edk2) for SEV SNP and TDX CVMs? If so, which version do they use in production?

We do and don't. We maintain patches on EDK2 with the latest rebase being on top of edk2-stable202302. I don't have the commit SHA1 of this baseline in the signed firmware provenance since it's not representative of all the changes.

The relevant changes are primarily around supporting our paravirtualization device backend for providing persistent UEFI variables in the cloud, and some finagling for QemuFwCfg files to allow configuring x2apic support, some MTRR stuff since we use all 8 and give none to the OS, some ARM bringup stuff that's irrelevant to TDX and SEV-SNP, and most importantly TCG and secure boot changes.

Authenticode PKCS#7 verification logic is currently delegated to the host to do because getting Boringssl to do it in UEFI was hard at the time and we didn't get around to bringing the logic back into the guest for the SEV-SNP/TDX threat model. We have someone working on that now.

The EV_POST_CODE events are not measured to PCR0 because Google wants to reserve the right to change the firmware and ACPI tables across reboots and not destabilize folks' TPM sealing policies. Of course that ought to change with CVMs. To get back to full TCG compliance would require a very different story for how we deliver the UEFI and how customers can upgrade their firmware. I've been working this angle to allow for the option to use the firmware maintenance protocol to install Google-signed firmwares we publish, but it's yet more work that needs to get prioritized over AI GPU stuff.

With TDX/SEV-SNP you can handle firmware measurement appraisal separately from PCR0 by using our signed measurements. For measured ACPI tables... well you're a bit out of luck at the moment I'm afraid. I still don't have the ACPI table digest signing scoped to get done, but it's another pet project.

eduardolfalcao commented 4 weeks ago

Thank you for such a detailed response, @deeglaze :)

In summary: 1) the code is still closed, 2) google's ovmf build process is different from tianocore/edk2, 3) ovmf builds are not reproducible (yet), 4) ovmf binaries are not published (yet, but close to becoming public), 5) google reuses tianocore/edk2 with some patches.

If I understood well, you are saying I could learn about firmware measurement by observing TPM PCR 0. I appreciate your suggestion, but despite I care about the firmware measurement, in this moment I am prioritizing this verification to take place in a CVM TEE instead of the TPM because the former is more secure.

Regards

deeglaze commented 3 weeks ago

I bits I'm talking about are our changes to EDK2's implementation of the TCG PCClient Platform Firmware Profile. Even when run under an SVSM with a protected vTPM implementation, the lack of measurement of the ACPI tables will create an attack vector given the ACPI machine language the OS evaluates will be of unmeasured (untrusted) code in the trusted environment.

The EV_POST_CODE for the EFI_FIRMWARE_BLOB2 measurement to PCR0 I agree is pretty much irrelevant in TEEs that measure the firmware at launch and include that measurement in their quotes.