📃
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
  • Full Memory Encryption
  • Partial Memory Encryption

Was this helpful?

  1. Technology in depth
  2. AMD SEV
  3. Technology
  4. SME Concepts

Use Models

Last updated 11 months ago

Was this helpful?

In this section, we explore two different models that demonstrate how software can utilize the SME (Secure Memory Encryption) feature.

Full Memory Encryption

Full memory encryption is a straightforward and compelling approach for many computing systems, particularly in situations where physical attacks on the system are a concern, such as government data centers or smaller/remote enterprise data centers with limited physical security. With full memory encryption, all contents in DRAM are encrypted using a random key, providing robust protection against cold boot attacks, DRAM interface snooping, and similar threats. This approach also safeguards systems with NVDIMM (Non-Volatile Dual In-line Memory Module), preventing attackers from extracting data by removing a memory module.

To enable full memory encryption with SME, the operating system (OS) or hypervisor (HV) sets the C-bit (Confidentiality-bit) in all DRAM physical addresses within the page tables. This includes both instruction and data pages, as well as the pages corresponding to the page tables themselves. Effectively, the OS or HV software treats the system as having DRAM starting at address 0x8000_0000_0000. If the HV sets the C-bit to encrypt all physical memory, all virtual machines (VMs) controlled by the HV are encrypted using the same encryption key.

Importantly, DMA (Direct Memory Access) to memory encrypted via SME is supported. From the perspective of a device, an encrypted memory access appears as a normal memory access with bit 47 set.

Partial Memory Encryption

The utilization of the C-bit in the page tables offers flexibility for the OS or HV to selectively encrypt only a subset of memory, if desired. This approach still provides physical protection of the encrypted memory, while potentially improving performance for non-sensitive data. Additionally, the choice between encrypted and unencrypted memory can be used to create isolation for critical workloads. One example of this isolation is a system that marks only the memory used by guest VMs as encrypted. This can be achieved without modifying the guest VMs themselves. By setting the C-bit in all the nested page table entries corresponding to DRAM for those VMs (as depicted in figure above), the hypervisor enables encryption for the VM memory exclusively.

This configuration can be employed to protect VMs from a rogue machine administrator. Even if the administrator has access to the hardware and host system, they would not be able to inspect guest VM data, even with memory scanning utilities.

Encrypted VMs
Drawing