Runtime Configuration and Assets

Overview

An attestation fixed at boot cannot cover data that changes while a node runs, so PCC requires that a node’s Hermetic environment rest on its attested state alone. Data delivered after boot must not change them. Each component that consumes such data treats it as untrusted input.

The delivery mechanisms differ by platform:

Apple silicon nodes

The CloudConfigurationPreferences, ServiceControl, and CloudAssetDownloader frameworks deliver that data; an Appendix: Apple Silicon Runtime Configuration Consumers lists the consumers of each mechanism.

Google Cloud nodes

The control-plane agent renders Measured, unmeasured, and dynamic configuration into the container, and digests of a node’s Startup assets travel in the measured container image, so the attestation covers the asset set that node loaded.

CloudConfigurationPreferences framework

The CloudConfigurationPreferences framework manages the state of the runtime-configurable properties through the cloudconfigurationd daemon. This daemon periodically checks for new configuration updates and applies them, keeping a cache of the current state locally.

To keep runtime-configurable properties auditable, consumers must use the CloudConfigurationPreferences framework and the cloudconfigurationd daemon to access configuration data. Because CloudConfigurationPreferences is deployed in a cryptex, no OS components use it; only other cryptex daemons do. Auditors can identify these client components by checking for the com.apple.security.exception.mach-lookup.global-name entitlement containing com.apple.cloudos.cloudconfigurationd.

ServiceControl framework

The ServiceControl framework configures properties at runtime that involve service-state changes that are orchestrated by the PCC control plane. The framework communicates with the controlplaneagent daemon, which manages the state of the services on the PCC node on behalf of the PCC control plane.

controlplaneagent periodically checks the current states of services and their properties, reporting them to the PCC control plane. The daemon also checks for control-plane instructions and applies them to the corresponding on-node services. Each service that uses the ServiceControl framework defines its behavior for each instruction type, and the framework caches the resulting state.

Cloud asset distribution

The PCC infrastructure provides PCC nodes with data-only assets that the PCC control plane may need to update during the boot session.

The cloudassetdownloaderd daemon listens for asset-information updates from the PCC control plane using the ServiceControl framework. For each update, this daemon downloads the specified assets from the cloud, and extracts them to the file system. The processes that require these assets use the CloudAssetDownloader framework to subscribe to asset updates from cloudassetdownloaderd. When a new set of assets for a consumer becomes available on the PCC node, this daemon notifies the consumer with the updated asset information, including the file paths.

CloudBoard subscribes to updates for assets that cb_jobhelper and the paired application require. When cloudboardd receives an update from cloudassetdownloaderd, it relaunches the cb_jobhelper and application instances, and prewarms them with the new assets.

To provide transparency about the assets that may be used in processing a user’s request, each node that loads them adds asset metadata to the Request execution log. The metadata includes a hash that uniquely identifies the asset. For assets downloaded as Apple Encrypted Archive (AEA) files, the hash is the SHA-256 of the AEA container prologue. For assets downloaded in other formats, the hash is the SHA-256 of the file content.