SME Concepts
Last updated
Was this helpful?
Last updated
Was this helpful?
Main memory encryption is accomplished through dedicated hardware within the on-die memory controllers. Each controller is equipped with a high-performance Advanced Encryption Standard (AES) engine responsible for encrypting data when written to DRAM and decrypting it upon read, as depicted in the figure below. The AES engine operates with a 128-bit key and employs an address-based tweak to enhance protection against cipher-text block move attacks during data encryption.
The AES encryption key used with this mechanism, known as Secure Memory Encryption (SME), is randomly generated during each system reset and remains concealed from any software running on the CPU cores. Management of the encryption key is entirely entrusted to the AMD Secure Processor (AMD-SP), a 32-bit microcontroller (ARM® Cortex®-A5) serving as a dedicated security subsystem integrated within the AMD SOC. The key is generated using the onboard NIST SP 800-90 compliant hardware random number generator and securely stored in dedicated hardware registers within the SOC, ensuring that it is never exposed outside the system in plaintext. Unlike the SEV mode (to be discussed later), SME does not necessitate the participation of software running on the CPU cores in key management.
The decision of which memory pages should be encrypted is controlled by the operating system (OS) or hypervisor (HV) through the software-managed page tables. When memory encryption is enabled, the 47th bit of the physical address (referred to as the C-bit, as for enCrypted) is utilized to indicate whether a memory page should be protected. The OS or HV sets the 47th bit of the page table entry (PTE) to 1 to signify that the page should be encrypted. Subsequently, accesses to that memory are automatically encrypted and decrypted by the AES engine in the memory controller.
It is essential to note that the encryption and decryption processes via the AES engine introduce a minor increase in latency for DRAM memory accesses. The impact of this latency on software performance varies significantly depending on the system workload but is generally estimated to have only a marginal effect on overall system performance. If only a subset of memory is encrypted, the performance impact will be less pronounced since unencrypted accesses typically do not incur additional latency, as illustrated in figure above.
