# AWS Nitro Enclaves

AWS Nitro Enclaves are isolated compute environments that run alongside EC2 instances. They are created by partitioning CPU and memory resources from a parent instance and launching a signed Enclave Image Format (EIF) file inside a confidential VM managed by the Nitro Hypervisor.

QEMU supports launching Nitro Enclaves on EC2 instances that have enclave support enabled, using the `nitro` accelerator and the `nitro` machine type.

## Prerequisites

- An EC2 instance with Nitro Enclaves enabled

- The `nitro_enclaves` kernel module loaded (provides `/dev/nitro_enclaves`)

- CPU cores allocated to the Nitro Enclaves pool via `nitro-enclaves-allocator`

- Huge pages allocated for Nitro Enclaves via `nitro-enclaves-allocator`

## Quick Start

Launch a Nitro Enclave from a pre-built EIF file:

    $ qemu-system-x86_64 -accel nitro,debug-mode=on -M nitro -nographic \
        -smp 2 -m 512M -kernel enclave.eif

Launch an enclave from individual kernel and initrd files:

    $ qemu-system-x86_64 -accel nitro,debug-mode=on -M nitro -nographic \
        -smp 2 -m 512M -kernel vmlinuz -initrd initrd.cpio \
        -append "console=ttyS0"

The same commands work with `qemu-system-aarch64` on Graviton based EC2 instances.

## Accelerator

The `nitro` accelerator (`-accel nitro`) drives the `/dev/nitro_enclaves` device to create and manage a Nitro Enclave. It handles:

- Creating the enclave VM slot

- Donating memory regions (must be huge page backed)

- Adding vCPUs (must be full physical cores)

- Starting the enclave

- Notifying vsock bus devices of the enclave CID

Accelerator options:

`debug-mode=on|off`

  Enable debug mode. When enabled, the Nitro Hypervisor exposes the enclave’s serial console output via a vsock port that the machine model automatically connects to. In debug mode, PCR values are zero. Default is `off`.

## Machine

The `nitro` machine (`-M nitro`) is a minimal, architecture-independent machine that provides only what a Nitro Enclave needs:

- RAM (huge page backed via memfd)

- vCPUs (defaults to `host` CPU type)

- A Nitro vsock bus with:

  - A heartbeat device (vsock server on port 9000)

  - A serial console bridge (vsock client, debug mode only)

Communication to the Nitro Enclave is limited to virtio-vsock. The Enclave is allocated a CID at launch at which it is reachable. A specific CID can be requested with `-accel nitro,enclave-cid=<N>` (0 lets the hypervisor choose). The assigned CID is readable from the vsock bridge device:

    (qemu) qom-get /machine/peripheral/nitro-vsock enclave-cid

### EIF Image Format

Nitro Enclaves boot from EIF (Enclave Image Format) files. When `-kernel` points to an EIF file (detected by the `.eif` magic bytes), it is loaded directly into guest memory.

When `-kernel` points to a regular kernel image (e.g. a bzImage or Image), the machine automatically assembles a minimal EIF on the fly from `-kernel`, `-initrd`, and `-append`. This allows standard direct kernel boot without external EIF tooling.

### CPU Requirements

Nitro Enclaves require full physical CPU cores. On hyperthreaded systems, this means `-smp` must be a multiple of the threads per core (typically 2).

Nitro Enclaves can only consume cores that are donated to the Nitro Enclave CPU pool. You can configure the CPU pool using the `nitro-enclaves-allocator` tool or manually by writing to the nitro_enclaves cpu pool parameter. To allocate vCPUs 1, 2 and 3, you can call:

    $ echo 1,2,3 | sudo tee /sys/module/nitro_enclaves/parameters/ne_cpus

Beware that on x86-64 systems, hyperthread siblings are not consecutive and must be added in pairs to the pool. Consult tools like `lstopo` or `lscpu` for details about your instance’s CPU topology.

### Memory Requirements

Enclave memory must be huge page backed. The machine automatically creates a memfd memory backend with huge pages enabled. To make the huge page allocation work, ensure that huge pages are reserved in the system. To reserve 1 GiB of memory on a 4 KiB PAGE_SIZE system, you can call:

    $ echo 512 | sudo tee /proc/sys/vm/nr_hugepages

## Emulated Nitro Enclaves

In addition to the native Nitro Enclaves invocation, you can also use the emulated nitro-enclave machine target (see ‘nitro-enclave’ virtual machine (nitro-enclave)) which implements the x86 Nitro Enclave device model. While -M nitro delegates virtual machine device emulation to the Nitro Hypervisor, -M nitro-enclave implements all devices itself, which means it also works on non-EC2 instances.

If you require NSM based attestation backed by valid AWS certificates, you must use -M nitro. The -M nitro-enclave model does not provide you with an AWS signed attestation document.