Power systems are known to provide a highly secured server platform. DDR5 DDIMM memory buffer chips follow a similar secure boot process to Power 11 with further minimized core root for measurement (CRTM) and core root of trust for verification in firmware.
On Power11 and Power10 with DDR5 DDIMM memory, the Secure ROM (SROM) code is permanently fused into the Hardware, ensuring immutability and providing stronger resilience against supply chain attacks.
The OTPROM (One Time Programable ROM) security settings, HW public key hashes, and security switches are written during DDR5 DDIMM memory module manufacturing in IBM premises. Once fused, these values become immutable, providing a hardware-anchored root of trust that can be reliably used for secure boot and protection against tampering.
DDR5 DDIMM Memory Chain of Trust
The DDR5 DDIMM memory Secure Boot chain starts with the Secure ROM (SROM) code, with other components authenticated and integrity checked before being executed on the chip. Secure ROM code loads the bootloader image from external NOR and verifies the image before executing. The Secure ROM code also measures the HW public key hashes, Boot loader image hash and secure boot settings fused into the chips. The SROM image will use the hardware public keys hash from OTPROM as the root for the Secure Boot IPL (Initial Program Load). Secure IPL facilitates the further development of a trusted Power platform.
DDR5 DDIMM Memory Secure Boot Flow
A flow diagram illustrating the operations for a Secure Boot IPL (Initial Program Load) is shown in Diagram 1 below. Secure boot leverages the Secure ROM image as the core root of trust (CRT) with the chain of trust extended to include memory and IO engines on DDR5 DDIMM memory. Upon completion, the host’s chain of trust validates that the DDR5 DDIMM memory chain of trust has completed successfully and resulted in the state expected by the host. Coupled with DDR5 DDIMM memory HW security support, this trust domain ensures that it is not feasible to silently compromise the firmware running on DDR5 DDIMM memory.
Diagram 1
The firmware stack is authenticated through the use of ECDSA P-512/SHA3-512 and Crystals Dilithium/SHA3-512, making DDR5 DDIMM memory resistant to attacks by both classical and quantum computers. The service processor (FSP/BMC) is outside the DDR5 DDIMM memory trust domain, being an entity whose access is blocked to internal registers of DDR5 DDIMM memory and other protected registers and trusted memory regions. The blocking is enforced by Secure PPE (SPPE), which is the only interface for service processors to communicate with DDR5 DDIMM memory. Deny list address filtering logic is applied to any read/write hardware register access requests from the service processor to the DDR5 DDIMM memory SPPE.
The secure boot process starts with the Host sending a boot request to DDR5 DDIMM memory chips(s) in the system. Internally, the state of the secure boot logic is completely cleared to start from a well-known state. Hardware protection mechanisms are implemented to prevent a malicious attacker from skipping this initial step. The access from the service processor to the DDR5 DDIMM memory internal chip resource is locked, and SPPE starts executing code from Secure ROM. The code performs basic initialization and sets up SPI (Serial Peripheral Interface) to read from external NOR memory. Secure ROM code then reads the bootloader from NOR, validates the signatures over it, and measures the public keys and payload hash into one-time writable measurement registers. This secure ROM image and contents in the OTPROM form the core root of trust (CRTM) as shown in diagram 1. The secure ROM image also loads and verifies the HW keys hash in OTPROM and uses it for verifying the signatures of the bootloader image. On successful validation of the bootloader image by SROM, the control of execution is handed over to the bootloader image. The bootloader image loads the runtime image hash list and the HW public keys from NOR to validate the signatures and measures the public keys and hash of the hash list into one-time writable measurement registers. The hash list is a collective set of all image hashes that would be used during boot to verify the image before loading it onto the target. On successful validation of the runtime hash list, the bootloader loads the SPPE runtime image from NOR into SPPE secure RAM for execution. The image is validated by checking the hash against the hash list image hash.
Once the above steps are completed, Secure PPE validates and loads other IO and memory engines RAM. The Host code on the processor then takes care of any pending update of the non-volatile NOR. In case of any updates Host performs a firmware update and initiates a reboot of the DDR5 DDIMM memory, which forces the DDR5 DDIMM memory to start from Secure ROM.
Host validation of DDR5 DDIMM Memory Secure Boot
Upon successful boot of the DDR5 DDIMM memory, the Host reads out all measurements via HW operations that were written into one-time writable measurement regs by DDR5 DDIMM memory Secure ROM firmware stack, which is immutable, and DDR5 DDIMM memory Boot loader. The host then validates the measurements read with the measurements in PNOR and in case of a mismatch the DIMM is deconfigured. All DDR5 DDIMM memories in the system are expected to have the same measurement values and the Host records a set of them in the Trusted Platform Module (TPM).
Summary
DDR5 DDIMM memory in Power10 and Power11 systems follows a secure boot process similar to the server platform, anchored by an immutable Secure ROM (SROM) and OTPROM settings fused during manufacturing to ensure hardware-based root of trust. The secure boot chain begins with SROM verifying the bootloader image and measuring public key hashes and secure boot settings, extending trust to memory and IO engines. The firmware stack is protected using advanced cryptographic algorithms like ECDSA P-512/SHA3-512 and Crystals Dilithium/SHA3-512, making it resilient against both classical and quantum attacks. Access from the service processor to DDR5 DDIMM internal resources is strictly controlled via Secure PPE (SPPE), which enforces deny-list filtering and acts as the sole communication interface. After a successful boot, the host validates measurements stored in one-time writable registers against trusted values, and any mismatch results in DIMM deconfiguration to maintain system integrity.
Contacting the PowerVM Team
Have questions for the PowerVM team or want to learn more? Follow our discussion group on LinkedIn IBM PowerVM or IBM Community Discussions