📃
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. AMD SEV
  3. Technology
  4. SEV-SNP Concepts
  5. Architecture

Encrypted Memory

Last updated 11 months ago

Was this helpful?

SEV leverages the same high-performance memory encryption engine featured in the SME technology described earlier. It also utilizes the C-bit in the page tables to indicate encrypted pages, albeit with some additional restrictions.

One of SEV's key features is granting guest VMs the capability to designate which data memory pages they want to keep private. This control is exercised through the standard CPU page tables, fully managed by the guest. Private memory is encrypted with a guest-specific key, while shared memory may be encrypted using the hypervisor key. This flexibility empowers VMs to mark specific memory pages as confidential (private), while others can be used for communication with other VMs or the hypervisor. In a common configuration, the guest typically designates all its code and data as private, except for specific shared pages it chooses to expose.

For enhanced security, SEV hardware enforces that certain memory types (including instruction pages and page tables) must always remain private to protect the VM.

An illustrative example of communication configuration is presented in figure above. In this scenario, the SEV-enabled guest and the hypervisor communicate through memory marked as shared by both entities. However, all other guest memory is encrypted with the guest's key, which the hypervisor cannot utilize directly. Any memory not used by the hypervisor for direct guest communication is encrypted using the SME feature, as detailed earlier. This setup ensures a secure and controlled communication environment between the guest VM and the hypervisor.

Guest/HV Communication Example
Drawing