Google Cloud Platform (GCP) recently announced Confidential VMs as first, beta product in the Confidential Computing ecosystem.

Google’s Confidential VMs build on top of the existing shielded VMs technology. This efforts adds a layer of security to the Google Cloud Platform. Confidential VMs complement Google’s Asylo project which slowed down a lot recently.

At CanaryBit we see these new technologies as opening new avenues in the confidential cloud computing business. 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

According to the GCP documentation, creating a confidential VM in GCP is trivial – simply a matter of ticking the “Confidential VM” checkbox.

Image: checkbox to enable confidential VMs in GCP

At this point, Confidential VMs come with a series of limitations:

Constraints on instances launched as confidential VMs

  • 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:
    • Europe-west-1 (Belgium)
    • US-central1 (Iowa)
    • Asia-east1 (Taiwan)
    • Asia-southeast1 (Singapore)
    • A limited set of Public images with support for confidential VMs

    List of images available for launch as in GCP as confidential VMs

  • And finally On-host maintenance to ‘Terminate VM instance

Confidential VM validation

Once you create the image, the next step is to launch an instance to 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.

  • integrityEvaluationPassed: The result of an integrity check that the hypervisor performs on the measurement that AMD SEV computes.
  • sevPolicy: The AMD SEV policy bits for this VM at launch time to enforce constraints such as debug mode.

The SEV API Spec provides us with some more details about the policy bits:

AMD Secure Encrypted Virtualisation (SEV) API Specification excerpt

Note the setting "esRequired": false : 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.

By default launchUpdateEntries contain two entries recording the guestMemoryRegion entry consistently reproduces 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 guestMemoryRegion However, this is not the case with the  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 finalDigest 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.

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:

Screenshot showing the diagnostic message output in a confidential VM

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 takes a major step towards improving cloud security. However, some crucial details are missing. A minimal wish list for more information includes (1) improved validation that would allow 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.

YOU MAY ALSO LIKE …

Accelerating Confidential Cloud Studio

Accelerating Confidential Cloud Studio

Early this year, CanaryBit was looking for a software developer to implement their Confidential Cloud Studio dashboard and integrate the solution with Cloud Service Providers (CSPs). CanaryBit is solving a painful problem for organizations willing to collaborate by...

read more
Intel SGX vs TDX: what is the difference?

Intel SGX vs TDX: what is the difference?

Intel has been a pioneer in Confidential Computing by introducing Software Guard Extensions - better known as SGX - as early as 2013. It continues this trend with the upcoming Trusted Domain Extensions or TDX. But when it comes to Intel SGX vs Intel TDX, what is the...

read more
CanaryBit has a new office space in Rome

CanaryBit has a new office space in Rome

Thanks to Leonardo Businesss Innovation Factory (BIF) Acceleration Programme and LVenture Group, CanaryBit has a new office space in Rome. Located at Rome - Termini Central Station, the LVenture Hub is the biggest innovation hub in Italy, with more than 130...

read more