📃
Confidential Computing 101
HomeTechnologyTry CC!
  • Welcome
  • Confidential Computing
    • What is Confidential Computing
    • What problems Confidential Computing solves
      • Bare Metal
      • Docker
      • Kubernetes
      • Knative
    • Why Confidential Computing
    • How Confidential Computing works
      • Memory Encryption
      • Workload Attestation
      • Confidential Boot
      • Sealing / Binding
      • Secret Provisioning
    • Technology Overview
    • Cloud Service Providers
  • Technology in depth
    • Intel SGX
      • Getting Started
        • Bare Metal Server Installation
        • Enclave Development Environment
        • Intel SGX SDK Setup
      • Technology
        • 🎭Features
        • 💂Threat Model
        • 🆚Versions
        • 🟦Concepts
          • 🏦Memory Encryption
          • 👮Local and Remote Attestation
          • 🖼️DCAP-Attestation Framework
          • 🔑Secret Key Provisioning
      • enclaive Development Kit
        • 🏢Architecture
        • 🌪️Workflow
        • 🌍Tutorials
          • Azure DCdsv3, DCsv2, or DCsv3 Setup
          • Redis in cK8s
          • MongoDB in cK8s
          • K8s + HashiCorp Vault on Azure DCsv3
      • Vault Remote Attestation Plug-In
        • 🏃‍♂️Initialization
        • 👮Attestation
        • ⚙️Configuration
    • Intel TDX
      • Getting Started
        • Azure
        • AWS
        • GCP
      • Technology
        • History
          • VT
          • TME/MKTME
          • SGX
        • Features
        • Threat Model
        • Concepts
          • Architecture
            • TDX Module
          • Memory Encryption
            • Confidentiality and Integrity
            • Keys and Key Management
          • TD Partitioning
          • DCAP-Attestation
            • Overview
            • Platform Registration
            • Attestation Report
    • AMD SEV
      • Getting Started
        • Azure
        • AWS
        • GCP
      • Technology
        • History
        • Threat Model
        • SME Concepts
          • Use Models
        • SEV-SNP Concepts
          • Features
            • Integrity Threats
            • Reverse Map Table
            • Page Validation
            • Page States
            • Virtual Machine Privilege Levels
            • Interrupt/Exception Protection
            • Trusted Platform Information
            • TCB Versioning
            • VM Launch & Attestation
            • VM Migration
            • Side Channels
          • Use Cases
          • Architecture
            • Encrypted Memory
            • Key Management
          • Software Implications
    • ARM CC
      • Technology
        • Introduction
        • Threat Model
        • Design
        • Comparison
    • Attestation Methods
      • Raw Attestation
      • Raw Attestation with Secure-Boot
      • Raw Attestation with a vTPM
        • AMD Secure VM Service Module and vTPMs
      • Raw Attestation with paravirtualized TPM
  • Resources
    • Youtube
    • Github
    • Products
Powered by GitBook
On this page

Was this helpful?

  1. Technology in depth
  2. ARM CC
  3. Technology

Comparison

Advancements in Trusted Execution Environments (TEEs) have become pivotal in modern computer architectures. Notably, Arm TrustZone offers static partitioning and isolation of memory segments in the Secure world, though scalability is limited due to the support of only a few such regions. Intel Software Guard Extensions (SGX) enable application developers to shield userspace memory from potential threats, but are not tailored for safeguarding virtual machines (VMs).

Meanwhile, AMD Secure Encrypted Virtualization (SEV) and Intel Trust Domain Extensions (TDX) provide protection at the VM level, paralleling the threat models of Arm CCA. Initial SEV versions ensured confidentiality by encrypting VM memory at runtime, but lacked memory data integrity safeguards. However, Secure Nested Paging (SNP) subsequently introduced integrity protection in SEV-SNP, allowing untrusted hypervisors to manage NPTs with reverse map table checks. Conversely, Intel TDX utilizes a TDX module in a privileged SEAM root CPU mode. Unlike Arm CCA, these solutions rely on intricate, unverified microcode and firmware implementations, which can be challenging to update.

Komodo draws inspiration from SGX but adopts a software monitor, coded in verified Arm assembly, atop TrustZone instead of necessitating hardware for complex enclave manipulations. While it lacks multiprocessor execution support, Komodo's approach sidesteps hardware complexity and facilitates independent enclave feature deployment. Arm CCA retains these advantages, leveraging a verified software monitor for Realms implementation while ensuring verified VM protection and multiprocessor execution.

The concept of retrofitting a standard hypervisor to enforce security with a trusted core was initially explored by SeKVM. SeKVM pioneered microverification, where a commodity hypervisor's confidentiality and integrity guarantees can be verified. Arm CCA mirrors this by enabling modified hypervisors to support Realms, protected by a verified monitor reminiscent of SeKVM. However, RME introduces new hardware mechanisms safeguarding VMs from untrusted software in both NS and Secure worlds, maximizing virtualization features like VHE for superior performance. Furthermore, Arm CCA firmware ensures scalability and concurrent operation, utilizing fine-grain synchronization and enabling dynamic memory allocation for VM metadata.

In conclusion, Arm CCA introduces Realms as secure execution environments that bolster VM confidentiality and integrity against untrusted system software. Realms leverage hardware and firmware to offer these guarantees while maintaining compatibility with the Arm architecture. This approach minimizes complexity and performance overhead while establishing a robust TEE for VM protection.

Last updated 11 months ago

Was this helpful?