📃
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. Features

Integrity Threats

In the case of Replay Protection and Data Corruption-based attacks, the exploits exploit the ability of untrusted code to write to the memory of a protected Virtual Machine (VM). To counter this, SEV-SNP implements a measure where only the owner of a memory page (i.e., the SEV-SNP VM to which the page was assigned) can write to that page. This restriction is accomplished by utilizing the Reverse Map Table (RMP) mechanism, further detailed in the subsequent section.

Memory Aliasing attacks involve maliciously mapping two different guest pages to the same physical memory page by the hypervisor. Naturally, a guest expects that distinct pages in its guest physical address space correspond to different memory locations, and any aliasing could lead to inadvertent data corruption. Ensuring that each physical memory page can only be mapped to one guest page at any given time is essential to address this threat. Once again, the RMP structure is employed to enforce this crucial property.

The final integrity threat, Memory Re-Mapping, arises when the hypervisor maliciously re-maps a single guest page to multiple different physical memory pages. Consequently, the guest may perceive an inconsistent memory view, with only a subset of the data it wrote being present in memory. To tackle this threat, it is imperative to ensure that each guest page is exclusively mapped to one page of physical memory at any given time, and this mapping cannot be altered except by trusted entities, such as the AMD-SP. SEV-SNP utilizes a mechanism known as Page Validation to counter this threat. Page Validation combines the new RMP mechanism with new VM code to effectively manage the injective relationship between guest memory and system memory, thereby enhancing security and thwarting Memory Re-Mapping attempts.

Last updated 1 year ago

Was this helpful?