Google has recently announced the introduction of Confidential VMs as first, beta product in the Confidential Computing ecosystem.
The new concept of Google’s Confidential VMs builds on top of the existing shielded VMs technology and adds a layer of security to the Google Cloud Platform. Confidential VMs is a parallel effort to Google’s Asylo project for portable trusted execution environments.
At CanaryBit we already see these new technologies opening new avenues in the cloud business and Google has already some contenders in this race.
Both Enarx and Raksh have been making some remarkable progress lately. According to a project maturity update the Enarx team has produced demos for both AMD and Intel as well as a working binary application capable of running on top of both SEV and SGX. To get an initial grip in this new technology, this article will dive deeper into the details of Google’s implementation of confidential VMs.
Creating a confidential VM
Following the GCP documentation, creating a confidential VM in GCP is trivial – simply a matter of ticking the "Confidential VM" checkbox.
At this point, Confidential VMs come with a series of limitations as expected from a Beta version:
- The series is constrained to N2D (running on the AMD EPYC Rome CPU platform)
- Machine type still offers a wide choice of n2d-standard-, n2d-highcpu- and n2d-highmem- machines.
- Supported regions and zones are limited to:
- Europe-west-1 (Belgium)
- US-central1 (Iowa)
- Asia-east1 (Taiwan)
- Asia-southeast1 (Singapore)
- A limited set of Public images with support for confidential VMs
- And finally On-host maintenance to ‘Terminate VM instance
Confidential VM validation
Once the image is created, the next step is of course to launch an instance and see what is different about it in terms of security. The GCP docs describe how cloud monitoring can be used to validate the confidential VMs. The log entry of interest is
.sevLaunchAttestationReportEvent
[
{
"insertId": "0",
"jsonPayload": {
"@type": "type.googleapis.com/cloud_integrity.IntegrityEvent",
"sevLaunchAttestationReportEvent": {
"integrityEvaluationPassed": true,
"platformInfo": {
"apiMinor": 22,
"apiMajor": 0,
"build": 11
},
"launchUpdateEntries": [
{
"guestMemoryRegion": {
"digest": "z80Rd+n3Bza2Smi8syfQpnkelnRhAAKe9co0G1b8GGw=",
"size": "131072",
"guestPhysicalAddress": "917504"
},
"guestFirmwareInfo": {
"description": "UEFI"
}
},
{
"guestMemoryRegion": {
"digest": "4hrO0GVL6IbpDGOUcnCJtxkrdWYUG1cGlTSH4cxDiB8=",
"guestPhysicalAddress": "4292870144",
"size": "2097152"
},
"guestFirmwareInfo": {
"description": "UEFI"
}
}
],
"sevPolicy": {
"minApiMajor": 0,
"sendAllowed": true,
"minApiMinor": 0,
"esRequired": false,
"domainOnly": false,
"debugEnabled": false,
"keySharingAllowed": false,
"sevOnly": true
},
"finalDigest": "BBChvQwZ93l6aoEtTQnOU2zzum6DItzvePjo2jVbAF8="
},
"bootCounter": "0"
},
"resource": {
"type": "gce_instance",
"labels": {
"instance_id": "364922263557703989",
"zone": "us-central1-a",
"project_id": "confidentialvm"
}
},
"timestamp": "2020-08-01T12:12:12.874542678Z",
"severity": "NOTICE",
"logName": "projects/confidentialvm/logs/compute.googleapis.com%2Fshielded_vm_integrity",
"receiveTimestamp": "2020-08-01T12:12:56.889566511Z"
}
]
The GCP docs explain two of the fields from the log entry.
: The result of an integrity check performed by the Virtual Machine Monitor on the measurement computed by AMD SEV.integrityEvaluationPassed
: The AMD SEV policy bits set for this VM; policy bits are set at Confidential VM launch to enforce constraints such as whether debug mode is enabled.sevPolicy
The SEV API Spec provides us with some more details about the policy bits:
Note the setting
: indicating that the encrypted state (SEV-ES) feature is disabled. SEV-ES encrypts CPU register contents when a VM stops running (details here). GCP currently does not offer any options to enable SEV-ES."esRequired": false
By default
contain two entries recording the launchUpdateEntries
guestMemoryRegion
entry is consistently reproducing the same digest in the three scenarios we ran:
1. Launch an instance named 'Alice'.
2. Stop and relaunch instance 'Alice'.
3. Delete instance 'Alice', create a new VM instance named 'Alice'
4. Launch an instance named 'Bob'.
Based on this we can conclude that the
However, this is not the case with the guestMemoryRegion
finalDigest
includes a (potentially pseudorandom) value that is recalculated at each VM launch. which is different in all of the scenarios above. This implies that the finalDigest
includes a (potentially pseudorandom) value that is recalculated at each VM launch.
The GCP documentation does not clarify what the
measures and what its purpose is. We investigated this further, emailed the developers and raised an open question on StackOverflow, but the mystery remains unsolved.finalDigest
Finally, a search for "AMD" among the diagnostic messages logged by the VM instances reveals that the VM is running on an AMD CPU 7B12 with Secure Encrypted Virtualisation (SEV) active:
Conclusion
We still have some open questions we would like to answer, but overall we found the Confidential VM implementation in Google Cloud Platform very straightforward.
For certain threat models, the current GCP implementation of confidential VMs running on ADM SEV is a major step in improving cloud security. However, some crucial details are still missing and will hopefully be added in the future. A minimal wish list includes (1) improved validation, allowing the guest owner to directly validate the VM instance as described in the AMD SEV API Spec and (2) a clarification of how the ‘Final Digest’ is calculated, that would allow to pre-calculate it for a given VM image before instantiation.
In part two of this series, we will review the AMDs SEV specification and compare it with the GCP Confidential VM implementation.