Google Cloud Research Tooling

Overview

Researching a Google Cloud node uses the same verification model as researching an Apple silicon node, but almost none of the same host tooling. The one shared base is inspecting the transparency log with pccvre, described in Inspecting Releases. Everything else differs because the platforms differ:

• Attestation is rooted in Intel TDX, NVIDIA confidential computing, and Google’s Titan security chip rather than the Secure Enclave and Image4.

• The workload is a measured container, not a set of cryptexes.

• There are no ensembles.

• The Google Cloud control plane manages instance life cycle.

Understand what the research tooling covers

Your approach to Google Cloud research depends on whether you provision and manage your own Google Cloud instances or work within a managed environment provided by Apple:

You manage your own infrastructure

You provision your own Google Cloud confidential-computing instances, run inference requests against them, and verify the resulting attestations against the transparency log.

Apple provides your infrastructure

Apple grants you access to a managed research environment during scheduled time windows, where you manage your allocated instances, customize the workload, and recover an instance if it becomes unresponsive.

These tools cover that work, with separate scopes:

You continue to use pccvre for platform-independent analysis workflows, such as transparency log, release, and attestation analysis. Instance life cycle on Google Cloud is left to standard tools such as gcloud and container (or docker, which works similarly), which already cover what you can do on your own infrastructure.

Understand attestation, the transparency log, and releases

pccvre ships with macOS and covers the Google Cloud research operations that are independent of instance management. The commands are the same ones you use to analyze an Apple silicon node; they detect the Google Cloud evidence format and need no platform-specific flags.

The Appendix: Apple Intelligence Report contains a Request execution log. Each time a proxy node sends the request to another node, the log records that node’s attestation. Google Cloud inference nodes appear as transitively attested nodes in those logs, and pccvre handles their attestation format to process the report. An Apple silicon proxy and a Google Cloud inference node can serve a single request together, producing one report that carries both attestation types in the same log; pccvre validates each against its own root of trust and verifies both for inclusion in the shared transparency log.

These extensions to pccvre are specific to Google Cloud:

Attestation format support

The attestation commands parse and verify the evidence in a Google Cloud node’s bundle: its Intel TDX quotes, its Titan-rooted host attestation, and its NVIDIA confidential-computing reports. Google Cloud Node Attestation describes the evidence, and Appendix: Google Cloud Attestation Bundle Contents gives its wire format.

Typed release entries

In the release commands, so that a Google Cloud release renders correctly alongside an Apple silicon release. A Release structures carries the boot measurements of each operating system on the node and the container image digest; a firmware release carries the Titan, BMC, and BIOS digests along with the Intel TDX and NVIDIA GPU measurements. Both platforms publish to the same transparency log.

Requests to an instance go through pcc-curl rather than pccvre. It takes an explicit endpoint URL rather than a named instance, so it reaches a Google Cloud instance through a network tunnel without any instance-management integration: it validates the bundle the node returns on the request path, submits the request, and streams the response back. It evaluates no environment policy; this is why deciding whether to trust a bundle stays with pccvre.

The pccvre subcommands for instance, ensemble, and workload management, and its Image4, cryptex, and darwin-init operations, have no Google Cloud equivalent; instance life cycle is external, and the configuration that those subcommands manipulate lives in the measured container instead. For the analysis workflows themselves (parsing an attestation, verifying it, and confirming transparency-log inclusion), you need no Apple-provided tool beyond pccvre and pccvre-container-export.

Manage workload containers

container is a tool you can use to create, download, publish, and run Linux containers on your Mac. Apple distributes it as open source. The tool consumes and produces OCI-compatible container images, so you can pull and run images from any standard container registry. You can push images that you build to those registries as well, and run the images in any other OCI-compatible application.

Modify the workload

A Google Cloud node’s Apple runtime is delivered as a single measured container, the Workload Megacontainer. Google Cloud Software Transparency describes how the container is measured and published. Because a root container embeds component containers as tarballs and manages their life cycle with systemd and runc, container build alone cannot correctly unpack, modify, and repack the image. Use pccvre-container-export to manipulate that format directly.

pccvre-container-export is specific to Google Cloud research, and pccvre installs it for you. By default pccvre downloads it from the transparency-log entry for the most recent release, so the tool you run is covered by the log you audit.

With the pccvre-container-export tool you can:

• Extract the component tarballs from the container and repack a correctly structured container ready to push and deploy.

• Swap in a different prebuilt component image, building the component itself with standard container tooling and using pccvre-container-export for the swap.

• Modify the Measured, unmeasured, and dynamic configuration inside the container, and confirm that a change to it produces a different measurement.

• Modify the container’s systemd unit definitions where the workload’s process management needs to differ.

This tool is relevant to every Google Cloud researcher regardless of how you provision instances, because it operates on the container image rather than on any Apple-managed infrastructure. Container registry operations (pulling, tagging, and pushing images) are supported by container, so pccvre-container-export doesn’t duplicate them.

You also control what a cloud app returns by swapping a component. To force a particular response, a failure, or a code path that production traffic rarely reaches, you build a replacement component and swap it in. Running the Workload Without a GPU on Google Cloud works through an example, swapping in a model back end that streams synthetic tokens and computes nothing. Your replacement is measured like any other component, and the node’s attestation reports it.

The security-relevant property you exercise here is the configuration split. On a Google Cloud node, the container build fixes security- and privacy-sensitive configuration into the image, so attestation covers that configuration; changing it requires rebuilding the container and re-imaging the instance. Runtime configuration the control plane delivers is not part of the release, and PCC treats it as attacker-controlled, so it must not change the node’s security or privacy properties. You can verify this boundary directly: use pccvre-container-export to change a measured setting and confirm that the node’s attestation changes.

Interact with instances in the Apple-provided environment

Interactions with Google Cloud go through Google’s own gcloud command-line tool rather than an Apple wrapper. In the Apple-provided environment, Apple restricts your permissions to the operations required for security research, so gcloud reaches only the instances allocated to you. If you provision your own infrastructure, you can use the same commands, or manage your instances however you prefer.

The environment allocates you a single confidential-computing instance that runs the requested workload and is reachable over SSH during a scheduled time window. The instance is not directly reachable from the internet. Google’s Identity-Aware Proxy routes all connectivity and enforces authenticated, identity-scoped access, so you establish a tunnel with gcloud before connecting with any other tool.

A change you make inside a running instance is unmeasured and doesn’t survive a restart, so you customize an instance by rebuilding the container with pccvre-container-export, pushing it to a registry, and re-imaging the instance. You recover an unresponsive instance the same way. For a quick experiment on a debug image, follow Edit a configuration file on a running node instead.

Once your instance is running and you establish the tunnel, the analysis workflow is the same as on your own infrastructure: submit inference requests with pcc-curl against the local tunnel endpoint and verify attestations and transparency-log inclusion with pccvre.

Understand the setup workflow

The analysis half of the workflow is the same whichever platform served the request. The setup half is specific to Google Cloud:

• Instance life cycle is external. There is no create, start, or remove step in the Apple research tooling; you provision instances yourself with gcloud, or they are provisioned for you in the Apple-provided environment.

• Measured configuration lives in the container. You change it by rebuilding the container with pccvre-container-export. You can override unmeasured configuration per instance.

• A debug image is a separate artifact. Appendix: Google Cloud Debug and Hardened Images documents the security properties that each debug image weakens. You choose the image when you provision or re-image the instance; there is no runtime switch.

• You cannot add debug capability to a production-configured instance. SSH access requires a debug image, so gaining SSH access means re-imaging, and the new image’s measurements differ from the production image’s. Once you have a debug image, that access is ordinary Linux SSH over a tunnel.

• A tunnel comes before any other tool. You establish it with gcloud before pointing pcc-curl or SSH at an instance. In the Apple-provided environment, Google’s Identity-Aware Proxy carries the tunnel; on your own infrastructure you need an equivalent.

To reproduce a node’s published measurements, and for the third-party-firmware cases where reproduction falls short, see Reproducing Google Cloud Measurements.