Google Cloud Node Architecture

Overview

For the most demanding Apple Intelligence tasks, including agentic tool use and complex reasoning, we worked with Google and NVIDIA to extend PCC infrastructure to Google Cloud systems that use NVIDIA GPUs.

A node satisfies PCC’s Core Security and Privacy Requirements using a Google Cloud Node Hardening composed of elements from Apple, Intel, NVIDIA, and Google. The node presents attested measurements that match a release recorded in the public Release Transparency, and user data reaches it only if that proof holds.

Bare-metal A4 instances

PCC on Google Cloud uses the A4 machine type with eight NVIDIA Blackwell B200 GPUs. To meet PCC’s requirements for Frontier security and privacy, we use a bare-metal variant of that machine type.

In this model, Google supplies and physically operates the hardware, dedicating the whole physical machine to PCC with no other co-resident workloads and no cloud-operator software layer beneath the node’s own stack. The node’s attestation covers the software on the machine from firmware through the host and guest operating systems to the application code; Google Cloud Software Transparency records how far each layer can be independently verified.

The A4 instance combines hardware from three vendors, each providing its own root of trust:

Google Titan chip

The host’s Trusted Platform Module and the system’s first Google Cloud Roots of Trust. The Titan chip attests to the initial boot chain, including the system’s firmware and the host operating system.

Intel CPUs

Two Intel Emerald Rapids CPUs run the node’s software stack. Trust Domain Extensions (TDX) isolate the workload in a memory-encrypted virtual machine. Intel registers the two CPUs as one multi-package platform and issues a single Provisioning Certification Key (PCK) certificate for it; the TDX quote that reports the virtual machine’s measurements chains to that certificate.

NVIDIA GPUs

The B200 GPUs are the node’s inference accelerators, providing the memory and compute required by the inference engine. They run in NVIDIA Confidential Computing mode, and each GPU carries a root of trust that attests to its own firmware.

[Image]

The PCC node’s configuration doesn’t use two features typical of the A4 machine type:

• Local SSDs, the machine type’s directly attached scratch disks, are not available.

• ConnectX-7 NICs, which ordinarily provide GPUDirect remote direct memory access (RDMA), carry no node traffic. Node traffic uses the Infrastructure Data Plane Function (IDPF) network interfaces, and the host passes only those interfaces and the GPUs through to the Workload VM. Neither the host nor the Workload VM loads the NVIDIA peer-memory module that GPUDirect RDMA requires, and the host’s kernel denies the NVIDIA driver outright.

Confidential computing

Intel TDX and NVIDIA Confidential Computing together put a hardware-enforced boundary around a running workload. TDX runs that workload in a Confidential VM (CVM), a virtual machine whose memory the CPUs encrypt in DRAM. No software outside the CVM can read its private memory, not even the hypervisor or the host operating system.

CVMs provide three properties for PCC:

Measured and attested environment

TDX measures what runs inside the CVM and each GPU measures its own firmware, so a node can Google Cloud Node Attestation both the software in the CVM and the firmware on its accelerators.

Memory and bus encryption

Memory encryption covers the request as the CPUs work on it. On the GPUs, model weights and activations sit in high-bandwidth memory that the GPUs isolate from the host but don’t encrypt. The GPUs negotiate keys with the CVM and with each other, so user data is encrypted crossing PCIe between the CPUs and the GPUs, and crossing NVLink between the GPUs.

Isolation from privileged software

Compromising the hypervisor or the host operating system does not yield the Workload VM’s private memory.

Confidential computing provides two foundational properties for PCC: it can attest to the workload’s software stack, and it keeps data encrypted against physical attack. Two limitations of a traditional confidential VM setup remain, and neither is acceptable under PCC’s requirements for Frontier security and privacy:

A single vendor’s root of trust

A TDX quote chains only to Intel, so compromising that one root lets an attacker forge a valid attestation for a node running malicious software.

Side channels out of scope

Confidential computing protects the contents of a CVM’s memory, but an adversary running code on the same machine can attack the confidentiality of the CVM through Resisting side-channel extraction, without needing any flaw in the workload.

Bare-metal instances mitigate both concerns: attestation requires valid quotes from Google’s Titan as well as Intel TDX, and sole tenancy leaves no untrusted co-resident workload that could exploit microarchitectural side channels. Bringing the host OS and hypervisor into the Hermetic environment expands the volume of software to measure and, in exchange, places the host firmware, both operating systems, and the application code inside the attested boundary.

The software on a node

The bare-metal instances boot an image of Google’s attested Container-Optimized OS (aCOS), which bootstraps the workload.

[Image]

The aCOS image includes:

• Host operating system

• KVM and QEMU hypervisor stack, which creates the node’s CVMs

• Guest operating system that runs inside the Workload VM

• Protecting request keys, which runs in a CVM of its own

Acting through Google’s Compute Engine control plane, Apple’s fleet control plane creates A4 instances much as Google Cloud Confidential Space does: it specifies an aCOS version and passes a workload container image in the instance metadata. Apple builds a single Workload Megacontainer containing the entire PCC application stack: request handling, the inference engine, and their supporting daemons. At boot, aCOS downloads, measures, and launches that image inside the Workload VM.