This article explores the necessary transformations of the Linux cloud stack to support confidential virtual machines (VMs), which protect guest memory even from untrusted hypervisors and host providers. It details the tension between performance and security in cloud environments, particularly concerning I/O passthrough, and proposes extending confidential computing to I/O devices via standards like TDISP. The piece also outlines critical changes required for Secure Boot, necessitating trusted components like Secure VM Service Modules (SVSM) and remote attestation processes, and addresses runtime overheads from memory encryption and page acceptance. Scalability issues related to Address-Space Identifiers (ASIDs) are discussed, alongside the shift in trust from cloud providers to hardware and firmware OEMs. While confidential computing offers enhanced, verifiable privacy, the discussion also highlights skepticism regarding its absolute security claims and the importance of open architectures for transparency.
Rethinking the Linux Cloud Stack for Confidential VMs: Enhancing Privacy and Performance
~0:00 The Need for Confidentiality: The inherent privacy limitation of public clouds, where host providers can access VM memory, necessitates confidential computing (CC) to protect guest memory even from hypervisors. This requires rethinking the Linux cloud stack to balance performance and security.
~1:30 Isolation vs. Performance Trade-offs: While virtualization already provides isolation through hardware, hypervisors (like KVM), and user-space tools (cgroups, namespaces), CC adds a crucial layer protecting guests from potentially compromised hosts. However, performance-boosting techniques like I/O passthrough (e.g., DPDK, vDPA) bypass kernel-level security checks, creating a fundamental tension where stronger isolation often reduces performance.
~3:00 Extending Trust to I/O Devices: A key solution involves making I/O devices part of the VM's "circle of trust" through technologies like AMD's SEV Trusted I/O (SEV-TIO). The TEE Device Interface Security Protocol (TDISP), an industry standard by PCI SIG, defines how confidential VMs and devices establish mutual trust and share secrets via direct memory access (DMA) to encrypted private memory, thereby avoiding slow bounce buffers. Implementation via SR-IOV requires extensive changes across the software stack and faces vendor adoption challenges (e.g., NVIDIA's non-TDISP architecture).
~5:00 Secure Boot and Remote Attestation: In CC, the traditional Secure Boot chain, which relies on a host-provided virtual TPM (vTPM), is insufficient due to an untrusted hypervisor. Instead, a Secure VM Service Module (SVSM) or similar trusted component must provide a vTPM for remote attestation. This process, following architectures like RATS, involves a hardware Attester, a remote Verifier, and a vendor Endorser to cryptographically verify platform integrity before the guest VM proceeds. This process, however, adds significant boot time delays that are critical for cloud environments.
~8:00 Runtime Overhead and Scalability Challenges: While DRAM encryption/decryption causes minimal inline overhead, the process of explicitly "accepting" each memory page by the guest is a major performance bottleneck due to hypercalls and VMEXITs. Furthermore, hardware limitations like the number of Address-Space Identifiers (ASIDs) restrict the number of confidential VMs a system can host, impacting scalability for modern multicore processors. Pre-accepting memory pages during boot is suggested to mitigate runtime costs, and hybrid systems running both confidential and conventional VMs are explored as a potential solution for ASID limitations.
~11:00 Broader Implications and Shifting Trust: Confidential VMs require encrypted swap memory and secure end-to-end network communication. They are likely more suitable for latency-tolerant, batch-oriented workloads like HPC rather than real-time client-server applications. Live migration becomes more complex, requiring repeated attestation and verification of the VM's state on the destination. Ultimately, CC shifts the security trust from the cloud provider to hardware and firmware OEMs, underscoring the value of transparent, open architectures like RISC-V to mitigate risks from hidden vulnerabilities.
~12:30 Community Insights & Skepticism: Comments highlight a significant debate around CC. Skeptics view it as potentially "misleading promises" (hailfinger, Curan, himi), questioning its ability to provide absolute protection against physical access or compromised hardware/firmware, asserting that true security still requires full control over one's own systems. Others suggest CC is valuable for specific use cases like validating attestation in secure data centers or reducing accidental data leaks (DemiMarie), or even as a business strategy to "commoditize the complement" by chip makers (yaap). A key clarification is made that the guest forwards attestation to an external trusted service for verification, rather than making the trust decision itself (SLi, Zildj1an). Novel workarounds, such as using "Shared Hugepages" for Intel TDX, are emerging to accelerate I/O performance without specialized hardware (Liam_Ma).