Skip to content

AMD platform security features

Introduction

This document describes the platform security features available on AMD-based Dasharo platforms and how to verify and use them. The features rely on the AMD Platform Security Processor (PSP) and the AMD memory controller, and are therefore specific to AMD platforms. They may not apply to Intel-based platforms.

At the time of writing, the AMD platform supported by Dasharo is the Gigabyte MZ33-AR1, a single-socket AMD EPYC (Genoa/Turin) server board. The features described here were validated on AMD Turin (EPYC 9005 series) and are expected to apply to future AMD Dasharo platforms as they are added.

The features covered are:

AMD ROM Armor

AMD ROM Armor protects the SPI flash against unauthorized writes. It is AMD's equivalent of SMM BIOS write protection used on Intel Dasharo platforms.

How it works

When ROM Armor is enabled, the host-side SPI flash interface is disabled and the PSP becomes the sole owner of the SPI flash controller. The host CPU can no longer issue SPI transactions directly, so a compromised OS or firmware cannot write to the flash by driving the SPI controller.

Legitimate flash writes (for example, a firmware update or SMMSTORE variable update) are performed by sending a command to the PSP from System Management Mode (SMM). The SMM code provides the PSP with:

  • the raw SPI flash commands to execute,
  • a whitelist of address ranges that may be written, and
  • a whitelist of SPI flash commands (opcodes) that may be executed.

The PSP validates each request against these whitelists before executing it on the flash. Because only privileged SMM code can construct these requests, and the PSP enforces the allowed ranges and opcodes, writes originating outside of SMM are rejected.

Status and configuration

ROM Armor is supported and enabled on AMD Turin. In the Dasharo setup menu it is controlled by the Enable SMM BIOS write protection option under Dasharo Security Options.

Tip

As with SMM BIOS write protection on Intel platforms, this protection must be disabled before flashing firmware from the running OS. Use Firmware Update Mode to temporarily disable firmware protections for the duration of a single boot.

Verification

With ROM Armor enabled, an attempt to write the SPI flash from the OS using the internal programmer must fail, because the host no longer owns the SPI controller:

flashrom -p internal -w coreboot.rom

The write should be refused. A write using an external programmer (or a write performed through the firmware update path) still works. After disabling the protection via Firmware Update Mode, the same write should succeed, confirming that the protection is what blocks it.

AMD Secure Memory Encryption (SME)

AMD Secure Memory Encryption (SME) transparently encrypts the contents of system DRAM. The encryption key is generated by the AMD Secure Processor and managed by the memory controller; encryption and decryption happen inline on memory accesses and are transparent to the operating system. SME protects data at rest in DRAM against physical attacks such as cold-boot attacks and DIMM interposers.

SME is enabled on AMD Turin Dasharo builds.

Verification

If support for SME is present, MSR 0xc0010010 (MSR_AMD64_SYSCFG) can be used to determine if SME is enabled and/or to enable memory encryption:

0xc0010010:
        Bit[23]   0 = memory encryption features are disabled
                  1 = memory encryption features are enabled

For example:

ubuntu@3mdeb:~$ sudo rdmsr 0xc0010010
3fc0000

AMD SEV-SNP

AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) extends memory encryption to virtual machines. Each guest is encrypted with its own key, isolating guest memory from the hypervisor and from other guests. Secure Nested Paging adds integrity protection using the Reverse Map Table (RMP), which prevents a malicious or compromised hypervisor from remapping, replaying, or corrupting guest memory.

SEV-SNP is supported on AMD Turin Dasharo builds.

Prerequisites

Enabling SEV-SNP requires an AMD PSP Configuration Block (APCB) with SEV-SNP enabled. This APCB blob is extracted from the stock (vendor) firmware and included in the Dasharo firmware image at build time. Without an APCB that enables SEV-SNP, the feature cannot be turned on.

Verification

On the host, confirm that the firmware and hypervisor enabled SEV-SNP:

dmesg | grep -i sev

You should see a line indicating that SEV-SNP is enabled, for example:

[    5.454098] kvm_amd: SEV enabled (ASIDs 512 - 1006)
[    5.454101] kvm_amd: SEV-ES enabled (ASIDs 1 - 511)
[    5.454102] kvm_amd: SEV-SNP enabled (ASIDs 1 - 511)

You can also check the KVM AMD module parameter:

cat /sys/module/kvm_amd/parameters/sev_snp

A value of Y indicates SEV-SNP is available to guests. Final confirmation is launching an SEV-SNP guest and verifying, from inside the guest, that it reports running as an SNP-protected VM. This requires a host kernel, QEMU, and guest stack with SEV-SNP support.

FCH, GPIO, and SMM lockdown

To prevent tampering with the platform configuration after boot, Dasharo locks down a range of security-sensitive registers before handing control to the operating system. This includes:

  • SMM lockdown - System Management RAM (SMRAM) is locked so that SMM code and data cannot be modified or read from outside SMM, and SMI configuration is locked so the SMM handlers cannot be bypassed or reconfigured.
  • FCH lockdown - security-relevant registers in the AMD Fusion Controller Hub (FCH) are locked to prevent runtime reconfiguration of the platform.
  • GPIO lockdown - GPIO configuration registers are locked so that pin functions and states cannot be altered after boot.

These protections are implemented globally for AMD Turin and are always applied; they are not user-configurable.

Verification

These lockdowns are enforced by hardware lock bits set during POST. On a Linux host, fwupd may be used to verify the SMM lockdown:

sudo fwupdtool security
HSI-1
✔ SMM locked down:               Locked
✔ Fused platform:                Locked
✔ Supported CPU:                 Valid
✔ UEFI bootservice variables:    Locked
✘ TPM v2.0:                      Not found

References