Google Cloud Research Environment

Inspect independently, exercise, and attempt to break the software running on Google Cloud nodes.

Overview

Google publishes a node’s host image and Apple publishes its workload container; pccvre downloads both, and you can inspect them on your own Mac. Exercising a node is different: its trusted computing base is an x86 confidential-computing stack rooted in Intel TDX, the Titan security chip, and NVIDIA confidential computing, none of which a Mac can emulate. Full-fidelity research therefore runs against real Google Cloud infrastructure rather than a virtualized node on your own machine.

The tools and procedures for Inspecting Releases are shared across both platforms. Everything else described here is specific to Google Cloud. Google Cloud Research Tooling covers the tools you use; to independently reproduce a node’s software measurements, see Reproducing Google Cloud Measurements.

Research these areas to check PCC’s principles

The environment supports these kinds of investigation:

Transparency auditing: Verify that no one, including Apple, can run undisclosed code on a Google Cloud node without detection: every production software release appears in the public transparency log, the log’s Merkle structure makes retroactive tampering detectable, and the attestations a device relies on correspond to publicly inspectable releases. This work uses the shared transparency-log tooling described in Inspecting Releases. For details on what is published for a Google Cloud node, and how you reproduce its measurements, see Google Cloud Software Transparency and Reproducing Google Cloud Measurements.
Binary analysis: Confirm that the binaries a node runs contain no backdoors or data-exfiltration paths: no remote shell or interactive debugging interface is present, logging and metrics code uses privacy-preserving filters, and the encryption and decryption paths match the documented architecture. Because a Google Cloud node packages its runtime into a single measured container image (see Workload Megacontainer), you extract and inspect that image’s contents.
Runtime security research: Look for exploitable flaws in request processing and data handling: memory-corruption bugs, side channels, residual-memory leakage, sandbox escapes, and any state that, in violation of the stateless-computation guarantee, persists after a request completes. For this work, you run workloads on a provisioned node and exercise its request path.
Privacy engineering: Verify that user data is not accessible to Apple staff or to external parties: the observability paths don’t export request contents, no data survives a node reboot, and the node’s execution controls and network isolation block unauthorized outbound connections. For the relevant node properties, see Node network isolation and Management and Observability.
Non-targetability analysis: Verify that no one can steer node selection toward a specific user or device, and that request metadata excludes personally identifiable information. Node selection includes the choice of platform; for the routing and node-selection model, see Anonymous Request Routing and Non-Targetability.
Attestation analysis: Confirm that no one can forge or bypass a node’s attestations: they cryptographically bind the running software’s measurements to independent hardware roots of trust, the measured-boot chain captures the code that executes, and a device can validate the evidence against the transparency log. For the evidence chain and its verification, see Google Cloud Node Attestation and Google Cloud Roots of Trust.

Understand how the environment works

A Google Cloud node runs on real cloud hardware, and its attestation covers that hardware’s roots of trust. That shapes both how you get access to a node and how you configure its workload:

You work against real cloud infrastructure, not a local virtual node. Full-fidelity research requires access to Google Cloud and to managed instances. Running the workload on a Linux VM on a Mac exercises only part of the node’s trusted computing base; it omits the confidential-computing hardware, the multi-vendor roots of trust, and the third-party firmware and drivers that a node’s attestation covers.
The environment is expensive to run, so Apple shares reserved capacity. The accelerator-optimized instances a node uses are costly and not always immediately available, which makes a research environment impractical for an individual to run continuously. Apple shares its reserved capacity with invited researchers through time-based reservations. You can instead pay for your own cloud usage and provision the environment yourself, in which case you set up the entire cloud environment rather than draw on Apple’s capacity. An instance you provision runs on a machine type with no GPU attached and no host-attestation support, so its evidence omits both the GPU measurements and the host attestation.
Instance management is narrowly scoped and isolated. The Apple-provided environment exposes only specific instance-management operations, for example, launching an instance and changing its configuration. You reach an instance through a tunnel, both for the request data path and for SSH access to a debug-image instance. Google’s Identity-Aware Proxy mediates both network paths, which limits who can reach an instance and keeps the research environment isolated from Apple’s own infrastructure. Authenticating to the proxy requires a Google identity.
The workload is a single container, with no separate configuration or tooling delivery. A Google Cloud node packages Apple’s measured runtime, configuration, and tooling into a single attested container image (see Workload Megacontainer), and an instance runs one such workload container. To modify measured configuration or bring your own tools, you modify the workload container.

Understand the tooling boundary

The pccvre command-line tool that ships with macOS is your starting point for the interactions it covers on both platforms: the transparency log, binary-asset downloads, and request-execution log validation. Use pcc-curl to submit requests to an instance. The boundary between the Apple-provided tools and the rest of the Google Cloud environment falls at interactions with Google Cloud itself.

For the infrastructure Apple provides, you interact with the environment through:

Apple Security Research site: Request access by supplying the email address registered with your Google account and your public SSH key, then receive information about the instances provisioned for you.
gcloud: Establish tunnels that carry SSH and request traffic to your provisioned instances.
pcc-curl: Submit requests to the instances and fetch their attestations.
pccvre: Parse and verify the returned attestations.
pccvre-container-export: Modify the workload container.