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 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.
- Azure
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.
| PCR | Components | Measured by | Reproducible and verifiable |
|---|---|---|---|
| 0 | Firmware | Azure | No |
| 1 | Firmware | Azure | No |
| 2 | Firmware | Azure | No |
| 3 | Firmware | Azure | No |
| 4 | Continuum Bootloader, Kernel, initramfs, Kernel command line | Azure, Continuum Bootloader | Yes |
| 5 | Reserved | Azure | No |
| 6 | VM Unique ID | Azure | No |
| 7 | Secure Boot State | Azure, Continuum Bootloader | No |
| 8 | Reserved | (Continuum Bootloader) | Yes |
| 9 | initramfs, Kernel command line | Linux Kernel | Yes |
| 10 | User space | Linux IMA | No1 |
| 11 | Unified Kernel Image components | Continuum Bootloader | Yes |
| 12 | Reserved | (User space, Continuum Bootloader) | Yes |
| 13 | Reserved | (Continuum Bootloader) | Yes |
| 14 | Secure Boot State | Continuum Bootloader | No |
| 15 | Reserved | (Continuum Bootloader) | Yes |
| 16–23 | Unused | - | - |
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.