📃
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

Interrupt/Exception Protection

Last updated 11 months ago

Was this helpful?

To address potential concerns about interrupt and exception handling in virtual machine (VM) operating systems, SEV-SNP introduces two optional modes that VMs can enable to establish a more restrictive interface with the hypervisor.

  1. Restricted Injection: In this mode, virtual interrupt queuing is disabled, and the hypervisor's ability to inject interrupts is partially restricted. The hypervisor is only permitted to inject a single newly defined exception vector, #HV, which serves as a doorbell. Restricted Injection assumes that VMs and the hypervisor communicate events in a para-virtualized manner, like using an event queue in shared memory. The #HV exception serves as a signal to the guest VM to re-scan the event queue for new information.

  2. Alternate Injection: In this mode, standard virtual interrupt queuing and injection interfaces are allowed, but their control is exclusively assigned to the guest itself. Additional fields are added to the encrypted save area, referred to as the Virtual Machine Save Area (VMSA), to facilitate interrupt queuing and event injection. As the VMSA is accessible only by someone with access to the guest VMSA data (such as VMPL0), it ensures that interrupt-related security-sensitive states, like Task Priority Register (TPR), are securely saved and protected from manipulation by a malicious hypervisor.

When used together, these two modes enable VMPL0 to handle interrupt processing and APIC emulation. Virtual CPUs (vCPUs) assigned to run VMPL0 can be operated with Restricted Injection enabled, allowing them to communicate with the hypervisor using a para-virtualized interface and the #HV exception. Conversely, vCPUs utilized for other VMPLs, typically running the main OS of the guest, can be run with Alternate Injection enabled. This configuration allows VMPL0 to safely inject events and virtual interrupts to the main OS. From a software standpoint, the main OS can utilize a standard APIC or x2APIC interface, and any APIC accesses it requires can be trapped and emulated in VMPL0.

In this manner, the VMPL interrupt handling ensures a more secure and controlled environment for VMs and helps prevent potential disruptions caused by malicious hypervisor actions or unwarranted assumptions about interrupt and exception behavior based on bare-metal hardware. The use of different VMPL modes allows for a well-defined separation of concerns and facilitates effective communication between VMs and the hypervisor.

VMPL Interrupt Handling
Drawing