The new threat model of confidential computing

In the traditional computing threat model, privileged system software like the hypervisor, host OS, firmware, and DMA-capable devices were all granted access to the data and code of your workloads. This was widely accepted because it seemed necessary for the system managing VM resources (memory, execution, and hardware access) to also have access to the workload’s data. How else could it manage it after all?

Today, confidential computing is here to fundamentally disrupt this conventional model, by introducing a new system security primitive which decouples resource management from data access. In this new paradigm, the hypervisor and other system software retain their responsibilities for workload scheduling, execution and memory management but no longer have direct access to the data within the virtual machines. In practice, this means that even if a vulnerability would exist within the hypervisor, for example, it still won’t be able to compromise the security of your confidential virtual machines.

To achieve this level of security, new CPU security extensions have been developed, such as AMD SEV (Secure Encrypted Virtualization) and Intel TDX (Total Memory Encryption). These extensions provide two fundamental pillars of security:

1.  Memory Isolation through Main Memory Encryption: CPUs with confidential computing capabilities incorporate an AES-128 hardware encryption engine within their memory controller. This engine encrypts and decrypts memory pages each time there is a memory read or write operation. Instead of storing workload code and data in clear text in system memory, they are encrypted using the encryption key managed at the hardware level. The encryption/decryption process happens transparently and efficiently within the CPU, providing strong memory isolation for confidential workloads. 

1. Additional CPU-Based Hardware Access Control Mechanisms: Confidential computing-capable CPUs introduce new instructions and data structures that enable auditing of security-sensitive tasks typically performed by privileged system software. These tasks include memory management and access to platform devices. For example, when reading the memory pages mapped to confidential workloads, these new instructions also provide the previous value that was last written into the page. This feature helps mitigate data corruption and replay attacks by allowing detection of unauthorised modifications to the memory pages.

In order to enable Ubuntu users to take benefit of these new hardware-rooted security guarantees, Canonical offers today confidential virtual machines, CVMs, based on both Intel TDX and AMD SEV. As such, Ubuntu CVMs introduce a  stronger trust boundary that we need to properly understand in order to appreciate and use CVMs’ strengths. But of course, we also need to  identify their limitations and mitigate them. 

A new trust boundary with Ubuntu confidential VMs

Security is a subtle business where attention to details is crucial. When discussing confidential VMs, it is natural to see the industry’s emphasis on highlighting the software components that the technology helps you eliminate from your VM’s trust boundary, such as the underlying hypervisor and host OS, because this highlights the innovative and transformative aspect of confidential computing.

However, to provide a comprehensive and transparent evaluation of this technology, it is crucial to shine the light on the elements that still need trust when deploying workloads as confidential VMs. These trusted components can significantly impact the overall security of the system and should be approached with care and consideration. They are as follows:

• The entire software stack that runs within the CVM. 
• The development environment where the customer implements and builds their confidential workload.
• The development tools used to build confidential workloads.
• The infrastructure services that confidential VMs may depend on for additional security primitives, such as vTPMs for full disk encryption or measured boot. 
• The run-time root of trust which encompasses all the hardware and firmware that the underlying silicon technology used to implement the architectural extensions for confidential computing.
• The attestation protocol and its required key management.
• The network communication between your workload’s build and deployment environments. 
• Side-channel attacks.

By acknowledging and thoroughly evaluating all these factors, we can establish a holistic approach to security in confidential VM deployments. In this blog series, our aim is to delve into the security implications associated with trusting each individual component, as well as offer relevant mitigation strategies to address them.

How a confidential VM can turn on itself

Within each confidential VM, three key components coexist: 

• The customer’s workload
• The guest operating system 
• The in-guest firmware

While the remainder of this blog will focus on the customer’s workload and the guest operating system, we will reserve the discussion on the in-guest firmware for an upcoming blog post.

The customer’s workload refers to the software developed and built by the customer using their own development platforms. It is important to acknowledge that any security vulnerabilities or backdoors present within the workload can be potentially exploited by malicious attackers, and that confidential VMs, alone, cannot protect against them. And once the workload is deployed to the confidential virtual machine (VM), the guest operating system assumes full access to the workload. 

In other words, any security vulnerability within the workload itself or the guest operating system can cause the confidential VM to turn on itself. To mitigate this risk, we need to take several measures. 

In addition to using secure development practices, it is crucial to ensure that the development platforms employed for building the workload are adequately maintained and regularly updated with security patches. Neglecting to do so could make them vulnerable to attacks, as attackers can take advantage of unpatched vulnerabilities or introduce their own malicious code or backdoors. Choosing a secure and trustworthy operating system is also  crucial. 

However, even with an open source operating system, it is critical to actively monitor and address any security vulnerabilities through regular patching and updates. Security vulnerabilities, known as Common Vulnerabilities and Exposures (CVEs), can be discovered over time, and prompt action is required to mitigate their impact. Let us explore how you can achieve that with Ubuntu.

How Ubuntu and Ubuntu Pro can better protect your confidential VM from itself

Ubuntu offers many built-in security features like Full disk encryption, Mandatory Access Control via AppArmor, filesystem capabilities and UEFI secure boot. The Ubuntu pro subscription  provides  access to additional security features and updates tailored for enterprise environments. Ubuntu Pro provides extended security maintenance, which includes regular security patches and updates of the base operating system and 25,000 open source packages, including popular applications like Apache Kafka, NGINX, MongoDB, Redis, and PostgreSQL.  Ubuntu Pro  can reduce your average CVE exposure time from 98 days to 1 day. This proactive approach significantly reduces your exposure to security vulnerabilities and ensures that your confidential VM remains protected.

By using Ubuntu Pro with your development environments and workload development platforms, you significantly reduce your CVM’s attack vector. 

Ubuntu Pro is also free for up to 5 machines for personal and small-scale commercial use, or up to 50 machines for official Ubuntu Community members. Ubuntu Confidential VMs are available at no extra cost on major cloud providers. 

Get started with Ubuntu Pro today

Conclusion

At Canonical, we believe that confidential computing will become the default approach to computing. As such,  we are dedicated to supporting our users and customers in embarking on their confidential computing journeys with ease, using Ubuntu as their trusted platform. At the same time, we understand the importance of complete transparency and acknowledge that confidential computing alone cannot address all security challenges. By actively addressing and mitigating these challenges, we can establish a comprehensive and robust security approach in confidential computing deployments. 

In this blog, we have explored how confidential computing is disrupting the conventional threat model and how Ubuntu Pro can assist in establishing a strong security foundation for your confidential workload and VM guest operating system. Moving forward, we will delve into additional innovations that can further reduce the trust boundary by addressing security concerns related to components such as in-guest firmware and the platform’s virtual Trusted Platform Module (vTPM).

With Ubuntu as the foundation, we strive to empower our users and customers with the knowledge and solutions needed to navigate the complexities of confidential computing and build a secure environment. Together, we can embrace the transformative potential of confidential computing while prioritising transparency and comprehensive security practices.

Learn more about Ubuntu security

If you would like to know more about the Canonical approach to security at large, contact us. 

Additional resources

• Learn about Ubuntu Pro Ubuntu Pro 20.04 on Azure Marketplace Microsoft Azure Marketplace
• Watch our webinar to learn more about confidential computing
• Read our blog post for “What is confidential computing? A high-level explanation for CISOs”
• Read our blog post for “Confidential computing in public clouds: isolation and remote attestation explained”
• Start creating and using Ubuntu CVMs on Azure
• Is Linux Secure?