Skip to main content
Version: 1.1

Hardware attestation

Continuum verifies the CVM's attestation statement to ensure that the involved services and workloads run on trusted hardware. Only attested worker machines are given access to secrets to decrypt the inference requests.

For more general information on remote attestation, take a look at our confidential computing wiki.

Measured boot

When a Continuum OS image boots inside a CVM, it uses measured boot for all stages and components of the boot chain. This process goes up to the root filesystem. The root filesystem is mounted read-only with integrity protection, guaranteeing forward integrity. Any changes to the image will inevitably also change the measured boot's PCR values.

The runtime measurements consist of two types of values:

  • Measurements produced by cloud infrastructure and firmware of the CVM: These are measurements of closed-source firmware and other values controlled by your cloud provider. While not reproducible for the user, some of them can be compared against previously observed values. Others may change frequently and aren't suitable for verification.

  • Measurements produced by the Continuum bootloader and boot chain: The Continuum Bootloader takes over from the CVM firmware and measures the rest of the boot chain.

Continuum allows users to specify in the manifest which measurements should be enforced during the attestation process. Enforcing non-reproducible measurements controlled by your cloud provider means that changes in these values will block VMs from joining the Continuum deployment. By default, Continuum only enforces measurements that are stable values produced by the infrastructure or by Continuum directly.

Continuum uses the vTPM feature of Azure CVMs for runtime measurements. This vTPM adheres to the TPM 2.0 specification. It provides a measured boot verification that's based on the trusted launch feature of Trusted Launch VMs.

The following table lists all PCR values of the vTPM and the measured components. It also lists what components of the boot chain did the measurements and if the value is reproducible and verifiable. The latter means that the value can be generated offline and compared to the one in the vTPM.

PCRComponentsMeasured byReproducible and verifiable
0FirmwareAzureNo
1FirmwareAzureNo
2FirmwareAzureNo
3FirmwareAzureNo
4Continuum Bootloader, Kernel, initramfs, Kernel command lineAzure, Continuum BootloaderYes
5ReservedAzureNo
6VM Unique IDAzureNo
7Secure Boot StateAzure, Continuum BootloaderNo
8Reserved(Continuum Bootloader)Yes
9initramfs, Kernel command lineLinux KernelYes
10User spaceLinux IMANo1
11Unified Kernel Image componentsContinuum BootloaderYes
12Reserved(User space, Continuum Bootloader)Yes
13Reserved(Continuum Bootloader)Yes
14Secure Boot StateContinuum BootloaderNo
15Reserved(Continuum Bootloader)Yes
16–23Unused--

GPU attestation

Continuum relies on GPUs to accelerate machine learning workloads. Because GPUs are dedicated devices with their own hard- and software, the state of each GPU needs to be verified in addition to the VM's state. To support this, the GPU needs to be equipped with confidential computing features. NVIDIA's H100 is the first GPU with such support.

Before a GPU is used for Continuum workloads, Continuum OS resets the GPU and requests attestation evidence from the GPU. The evidence is sent to the NVIDIA Remote Attestation Service (NRAS), where it's verified. The GPU will only become available to workloads after that verification is successful.

Footnotes

  1. Linux IMA produces runtime measurements of user-space binaries. However, these measurements aren't deterministic and thus, PCR[10] can't be compared to a constant value. Instead, a policy engine must be used to verify the TPM event log against a policy.