Google Cloud Software Transparency

A node measures and publishes the platform firmware, operating systems, and container image it runs.

Overview

Verifiable Transparency is a core requirement of Private Cloud Compute: every production build that runs on PCC infrastructure is published to an append-only Release Transparency, and security researchers can inspect and analyze those builds. A node measures every layer of its launch: platform firmware, the host operating system, the guest operating system, and the workload container image. User data reaches a node only after Node validation confirms that the node’s attested runtime measurements match an entry published in the transparency log.

Software layers

The software on a node falls into three layers, each with different owners and update cadences:

The hardware trusted computing base (TCB): Consists of the Multiple hardware roots of trust firmware, the Baseboard Management Controller (BMC) firmware, the GPU firmware, and the BIOS. Google builds and deploys it during scheduled maintenance windows. The BMC firmware and the BIOS are ratcheted into the Titan TPM’s Host measurements (PCRs); Titan and the GPUs attest to their own firmware separately. Apple’s control plane receives advance maintenance notifications and can query the versions that will be active after the window, so Apple can publish reference measurements to the log before an update takes effect.
The operating system: Consists of the host operating system and its KVM and QEMU hypervisor, the guest operating system, the guest firmware, the Protecting request keys, the workload launcher, and the system monitoring agents, packaged as a single measured boot-disk image. Google builds and publishes it as image families, and Apple selects an image for deployment. Security updates roll out as complete new images rather than in-place patches, and Apple can publish reference measurements to the log as soon as an image version is available.
The workload: Consists of the Workload Megacontainer that packages Apple’s runtime. Built, published, and deployed by Apple. A node downloads, measures, and runs the referenced version on its next boot.

Restarting the whole host to pick up a new workload or operating-system version resets machine state between deployments, helping ensure that the node boots from known reference measurements.

Composing and publishing a release

The three software layers map to two independently published release types in the transparency log, because different parties control their deployment:

Firmware release: Covers the hardware TCB.
Software release: Bundles the operating system and the workload into a single log entry.

Recording the layers as two separate release types reflects deployment boundaries while keeping release verification independent. Google builds and releases the hardware TCB, but Apple approves a firmware update by publishing its reference measurements to the transparency log. Because node validation verifies a node’s measurements against the log before traffic routes to it, an unapproved firmware update prevents the node from accepting requests. Apple also coordinates the maintenance windows when updates are applied. For the software release, Apple builds the workload, selects the operating-system image, and deploys both together.

Within each release, components are bundled so that a single measurement covers several of them: the hardware TCB updates as one bundle with one endorsement, and the software release pairs the operating-system boot-disk measurements with the workload container image digest. Because the container image also encapsulates startup asset digests, an update to runtime code or assets produces a new container image measurement and a corresponding log entry. Across releases, a verifier checks a firmware entry and a software entry independently rather than every pairing of the two. Because the hardware TCB updates infrequently and isn’t pinned to a particular software release, a node can run a newly deployed software release against the current hardware TCB without requiring new firmware measurements.

Each release is recorded in the log as a structured record of its measurements, and the log entry is a digest over that record. The verifying client parses the measurement records in the node’s attestation and confirms that the record digest matches a published entry in the log, so that a component is trusted only when it is both present in the attestation and recorded in the log. Researchers can Reproducing Google Cloud Measurements to independently verify the host image, the nested guest images, and the guest firmware.

Release structures

Both release types travel in one ASN.1 envelope. A release is identified by the SHA-256 digest of that envelope’s DER encoding, not of the inner structure alone, so reproducing a digest means encoding the wrapper too:

ReleaseV2 ::= SEQUENCE {
    version        INTEGER(2),
    appleSiliconV1 [0] AppleSiliconV1 OPTIONAL,
    gcpV1Workload  [1] GCPv1Workload OPTIONAL,
    gcpV1Platform  [2] GCPv1Platform OPTIONAL
}

The envelope defines an appleSiliconV1 member; an Apple silicon node’s release is recorded in the version 1 Release data structure structure.

A software release carries GCPv1Workload, holding the boot measurements of each operating system on the node alongside the container identity:

GCPv1Workload ::= SEQUENCE {
    workloadVMMeasurements      [0] LinuxV1Measurements OPTIONAL,
    keyProtectionVMMeasurements [1] LinuxV1Measurements OPTIONAL,
    hostMeasurements            [2] LinuxV1Measurements OPTIONAL,
    containerImageDigest        [3] UTF8String OPTIONAL,       -- OCI form, "sha256:…"
    variant                     [4] UTF8String OPTIONAL,       -- afm, adm, …
    quotingEnclave              [5] IntelTDXQuotingEnclave OPTIONAL
}

The verifier fills each LinuxV1Measurements block from the replayed boot log of the corresponding operating system: the SHA-384 digest of the unified kernel image, plus the OVMF digest that the quote body reports as that domain’s MRTD. The Workload VM’s block additionally carries the NVIDIA driver measurement. The host’s block holds the single boot-services application digest from its replayed boot log, using SHA-256 rather than SHA-384. The container image digest and the deployment variant come from the replayed launch log. The quotingEnclave block records the identity of the SGX quoting enclave that signed both TDX quotes: its MRENCLAVE, MRSIGNER, ISVPRODID, and ISVSVN. It belongs to the software release rather than the firmware release because the enclave binary ships in the host image that this release pins.

A firmware release carries GCPv1Platform, holding the hardware TCB:

GCPv1Platform ::= SEQUENCE {
    titan     [0] OCTET STRING OPTIONAL,       -- SHA256, Titan RW firmware hash from its EK cert
    bmc       [1] OCTET STRING OPTIONAL,       -- SHA256, EV_EFI_HCRTM_EVENT digest at PCR[0]
    bios      [2] OCTET STRING OPTIONAL,       -- SHA256, Google DRTM event digest at PCR[17]
    intelTDX  [3] IntelTDXPlatform OPTIONAL,
    nvidiaGPU [4] NvidiaGPUMeasurement OPTIONAL
}

IntelTDXPlatform pins the TDX module and its security version with MRSEAM, MRSIGNERSEAM, and teeTcbSvn from the workload quote body. The FMSPC comes from the PCK certificate, and the CPUSVN — the running platform TCB — comes from the quoting enclave’s report. IntelTDXPlatform doesn’t record the enclave’s own identity; the software release carries it, as described above. The nvidiaGPU block carries the GPU product and VBIOS version with its attributed SPDM measurement blocks: the verifier splits the verified blocks between driver and VBIOS by fixed index sets, and skips all-zero digests. Because one GPU’s measurements stand in for all eight here, the verifier refuses to build a release when any GPU diverges from the rest.

No field in either structure is compared against a reference value on its own. A verifier projects the values it reads out of the quotes, certificates, and event logs into the release structure, digests the encoded result, and checks that digest for inclusion in the log. A single divergent field, such as a different MRSEAM or a rolled-back teeTcbSvn, therefore produces a digest that matches no entry. IntelTDXPlatform defines a seamVersion field that the current projection leaves absent, because the first byte of teeTcbSvn already carries that value.

Binary transparency

The reference measurements in the log record which software states PCC accepts. Confirming that a measurement corresponds to code that behaves faithfully requires the binaries themselves. The metadata that accompanies each release in the log lists where to download the artifacts measured by the release, so Downloading available releases can retrieve them.

Apple and Google publish those artifacts:

Apple: The workload container image, published to the Apple CDN.
Google: The host and guest operating-system images, published alongside their source code, and the Titan, BMC, BIOS, and GPU firmware, published to Google’s public artifact storage.

Google’s artifacts contain components that third parties build, including those from Intel and NVIDIA:

Operating-system images: The host image contains Intel’s SGX quoting enclave and the Open Virtual Machine Firmware (OVMF) that serves as each guest’s firmware. The Workload VM guest image contains NVIDIA’s GPU driver, consisting of a kernel module built from NVIDIA’s published open source code and a user-space driver binary.
BIOS image: Contains Intel’s Minimum Platform firmware and CPU microcode.
GPU firmware archive: Contains NVIDIA’s firmware for the GPU, including its VBIOS.

Intel publishes the TDX module’s source, and the module builds reproducibly from it.

The foundation models a node loads are measured through their Startup assets and attested like the rest of a release, but they are considered proprietary and not published as part of PCC’s transparency commitment.

Third-party firmware

Some third-party firmware presents additional challenges for independent verification:

Non-reproducible measurements: A firmware measurement is not a digest of the update file. Anyone can measure the artifacts Apple’s build pipeline produces and compare them against the log, but some third-party firmware measurements originate as a golden measurement captured from a known-good device. Each vendor publishes that value as signed reference data, so a researcher can check a release against it without re-deriving it from the firmware.
Encrypted binaries: The binaries are at least partly encrypted, which limits a researcher’s ability to disassemble and audit the code that runs at the highest privilege levels on the platform.

Each vendor’s firmware presents these challenges differently:

NVIDIA firmware

The NVIDIA GPU firmware is published, but encrypted, so the publication supports only dynamic research on procured hardware rather than static analysis. Even with encrypted firmware, researchers can verify that the GPU driver and host attestation match published measurements.

Intel firmware

Some Intel firmware is encrypted, and dynamic research faces additional challenges. Google Cloud nodes run Google-exclusive Xeon SKUs, so a researcher cannot acquire the same parts to generate golden measurements independently. Because Google controls firmware deployment on the fleet, a researcher cannot request that an older firmware version be flashed to a node to reproduce a historical measurement.

The TDX attestation also leaves a gap in microcode coverage: the TDX report includes only a security version number set by the microcode, not a digest of the microcode image itself, so malicious microcode could disable TDX protections while still reporting a valid security version number. PCC on Google Cloud mitigates this through its attestation of the BIOS image: the image contains the microcode, and the BMC measures the image into a Platform Configuration Register in the Titan quote, so the host attestation covers the microcode indirectly. Google publishes the BIOS image, so a researcher can obtain the artifact that contains the microcode, although the microcode inside it remains encrypted.