Power systems are known to provide a highly secured server platform. Power10 hardware and firmware improvements build upon what was released in Power9 systems to further minimize the core root of trust for measurement (CRTM) and core root of trust for verification in the firmware.

Host Processor Chain of Trust

Power10 Secure Boot implements chain of trust for the host processor. The chain starts with an implicitly trusted component with other components being authenticated and integrity checked before being executed on the host processor cores. Measurement code from a locked processor SEEPROM (Serial Electrically Erasable Programmable ROM) loads and measures the verification image. The measurement code also locates and measure the hardware public key hash from protected processor SEEPROM and passes it to the verification image. The verification image will use this hardware public key hash as the root for the Secure Boot IPL(Initial Program Load). On a Power10 system the measurement code and security switches are written during processor module manufacturing to provide the basis for hardware enforcement of secure IPL flows. Secure IPL facilitates the further development of a trusted computing Power platform.

Host Secure Boot Flow

A flow diagram illustrating the operations for a Secure Boot IPL is shown in Drawing 1 below. Secure Boot establishes the verification image as the core root of trust (CRT) with the chain of trust extended to include PowerVM, PFW (Partition Firmware), selected adjunct partitions - pTPM (physical TPM), vTPM (virtual TPM), Hostboot Runtime, and Encryption adjuncts - and On Chip Controller (OCC – thermal management). This chain of trust can be further extended into the operating system by enabled ‘Guest OS Secure Boot’ for your partition. Coupled with the processor hardware security support, this trust domain ensures that only authentic Power10 firmware is allowed to execute and that all components of the firmware stack are measured to the TPM to enable attestation.

Drawing 1: Power 10 Secure Boot Flow showing reduction of CRTM in Power10 vs. Power9.

The entire trusted firmware stack is authenticated through the use of ECDSA P-521/SHA512 signed images and runs in isolated memory locations. The service processor (FSP/BMC) is outside the host trust domain being an entity whose access is blocked to the Address/Display Unit (ADU) registers and other protected registers and isolated memory regions. The blocking is enforced by SBE denylist filtering of processor register read/write (SCOM) facilities enabled by the “secure access switch” in the SEEPROM area on the processor chip.

The secure boot process starts with the service processor (FSP/BMC) sending a boot request and boot-type to processor chip(s) in the system. Internally, the state of the secure boot logic is completely cleared to start from a good known state. Hardware protection mechanisms are implemented to prevent a malicious attacker from bypassing this initial step. The access from the service processor to internal host CPU chip resources is locked and the SBE starts fetching initialization code from on chip secure OTPRom. This code performs basic chip initialization and reset of the Trusted Platform Module (TPM). The OTPRom code then loads the measurement image from locked on-module processor SEEPROM. The measurement image loads and measures a SHA256 hash of the verification image from protected on-module processor SEEPROM. This measurement image forms the core root of trust for measurement (CRTM) as shown in Drawing 1. The measurement image also loads and measures the HW public key hash from protected SEEPROM and passes that to the verification image. The launch of the verification image is the start of the secure boot validation chain. The verification image loads the runtime SBE Boot image and uses the HW public key hash and signatures attached to the SBE Boot image to verify the integrity of the image. Upon successful verification a measurement of the SBE Boot image will be recorded to the TPM.

Once the above boot steps have completed, the SBE loads, validates and measures the Hostboot boot loader and validation code from SEEPROM into the processor chip’s internal L3 cache. A core is then started and the boot loader fetches the initial Hostboot Base code (HBB) from PNOR FLASH into the L3 cache. In secure mode, the validation code in L3 cache will be used to verify the HBB image now in trusted cache. Once the verification of the initial flash code is completed, the processor core continues executing the validated code from isolated memory space, next loading and validating HB extended functions (HBI). Once the HBI is measured and signature verified and copied, its measurement (image hash) indicating valid authentication is recorded in the TPM, as shown in the measurement flow side of Drawing 1. Notice that at this point, all code executed is fully contained in the chip and no off chip accesses have taken place.

The HB code then takes care of any pending update of the protected non-volatile SEEPROM with a new trusted image. It then locks down the protected SEEPROM preventing any further write access to protect the core root of trust (that is, any reboot of the machine will bring it back to this trusted state). The HB code then initializes the on-chip memory controller and the attached memory DIMMs (Dual In-line Memory Module) as well as other chips directly attached to the processor it is running on, before establishing the memory coherent interface to the other chips in the system after verifying that these are also in a secure/trusted state.

Higher FW stack components are then loaded, verified, executed and measurements recorded in the TPM. Following where HBI begins execution (Drawing 1), the PowerVM payload is loaded into main memory, the PowerVM code image is cryptographically authenticated and on successful authentication, the execution of PowerVM is started. The authentication measurement of the PowerVM code is recorded in the TPM. The same steps are performed to load code from unlocked flash to isolated memory, cryptographically authenticate, measure, and then execute various adjuncts and PFW, respectively.

OS Secure and Trusted Boot

In Power systems OS Secure and Trusted Boot optionally builds upon the firmware chain of trust to extend the verification and measurements into each partition.

To support OS Secure Boot in P10 partition firmware (PFW) has AIX and Linux (Redhat/SUSE) public keys embedded in it. When OS Secure Boot is enabled PFW will validate the first stage boot loader against these embedded keys to verify its integrity.

OS Secure Boot supports three modes :

• Disabled : Don’t perform any validation

• Enforce : Perform signature validation. On failure log an error and halt execution

• Audit : Perform signature validation but only log an error and allow execution to continue.

More information about AIX Secure Boot can be found here.

More information about Linux static key secure boot can be found here.

To add Trusted Boot for Linux you must enable a Virtual Trusted Platform Module 2.0 (vTPM). By enabling this feature PowerVM will extend measurements of the firmware (PFW/vTPM) into the vTPM prior to launch of the partition. PFW will then extend additional measurements including the measurement of the first stage boot loader.

Have questions for the PowerVM team or want to learn more?  Follow our discussion group on LinkedIn IBM PowerVM or IBM Community Discussions