Secure Initial Program Load (IPL) process

The Secure Boot feature prevents unauthorized access to customer data, either through unauthorized firmware that runs on a system processor, or by access through security vulnerabilities in authorized service processor firmware, or through hardware service interfaces accessed through flexible service processor (FSP).

The Secure Boot feature implements a processor-based chain of trust in the POWER9™ processor hardware that is enabled by the POWER9 firmware stack. The Secure Boot feature provides a trusted firmware base to enhance confidentiality and integrity of customer data in a virtualized environment.

The trusted boot feature of POWER9 processor-based servers allows measurement of system configuration and initial program load (IPL) path code, which can be used later as proof, through attestation of the initial IPL path configuration of the system. To create a Core Root of Trust for these Measurements (CRTM), a Secure Boot flow is used that adds cryptographic checks in each phase of the IPL process until communication with the Trusted Platform Module (TPM) is established. The Secure Boot flow ensures the integrity of all firmware that must be run on core processors, thus preventing any unauthorized or maliciously modified firmware from running. A failure to authenticate the code at any point prevents the IPL process from reaching completion.

The Secure Boot feature in POWER9 systems establishes trust through the platform boot process. Here, trusted means that the code that is run during the IPL process originates from the platform manufacturer, is signed by the platform manufacturer, and has not been modified.

The secure mode protection available in POWER9 processor-based servers maintains trust, by preventing read/write access to the customer data by the FSP and service interfaces, by preventing execution of untrusted code on the host processor, and by maintaining trust across all the key points in the Secure Boot process.

The POWER9 Secure Boot feature implements a processor-based chain of trust. The chain starts with an implicitly trusted component, while other components are authenticated and checked for integrity before they are run on host processor cores. The verification code that is in the locked processor in the Serial Electrically Erasable Programmable ROM (SEEPROM) validates the initial firmware load. The firmware verifies cryptographic signatures of all subsequent firmware that must be trusted and that are loaded for execution on the POWER9 processor cores. On a POWER9 system, the SEEPROM security switches are set in the Self-Boot Engine (SBE) code and fixed on the manufacturing (MFG) assembly line of the system to provide the basis for hardware enforcement of secure IPL flows. Physical security mode jumpers are available on the backplane of a system. The jumpers can be used to override secure mode switches of the processor if the system is physically accessed by a person. The secure IPL process further enhances trusted computing Power® platform.

The following diagram illustrates the operations of a secure and trusted boot IPL process.

The Secure Boot feature establishes the locked SEEPROM, SBE, and host boot base code (including a small portion of host boot extended code) as the Core Root of Trust for Measurement (CRTM), with the chain of trust extended to include Power Hypervisor (PHYP), partition firmware (PFW), selected adjunct partitions (physical trusted platform module (pTPM), virtual trusted platform module (vTPM), host boot runtime, and encryption adjuncts), and On Chip Controller (OCC – thermal management). This trust domain and the processor hardware security support ensures that the customer data is not displayed or altered through any hardware or firmware mechanisms.

The complete trusted firmware stack is authenticated by using signed images and is run in trusted memory locations. The FSP is kept out of the host server trust domain and the FSP is blocked from accessing Alter/Display Unit (ADU) registers, other protected registers, and trusted memory regions. The Self Boot Engine (SBE) enforces FSP blocking, by filtering the blacklist of processor register read/write scan communication (SCOM) facilities. The SCOM facilities are enabled by the secure access switch in the SEEPROM area of the processor chip.

The following figure shows the Secure Boot environment.

When the Secure Boot process starts, the FSP element sends a boot request and details about the boot-type to processor chips in the system. Internally, the state of the Secure Boot logic is cleared of previously set values to start from an appropriate, known state. The state is also cleared of any tempering requests that were run previously. Hardware protection mechanisms are implemented to prevent a malicious attacker from skipping this initial step. The access from the FSP to internal chip resources is locked and the Secure Boot engine starts fetching initialization code from memory that is on-module, secure, nonvolatile, and locked. This code performs basic chip initialization and resets the TPM.

After the initial step in the booting process is completed, the Self Boot Engine (SBE) loads the host boot loader and validation code from SEEPROM into the internal L3 cache of the processor chip. A processor core is then started and the boot loader fetches the initial Host Boot Base (HBB) code from Processor NOR (PNOR) flash chip and loads it into the L3 cache. In secure mode, the validation code from the L3 cache is used to verify the HBB image that is now available in the trusted cache. After the initial flash code is verified, the processor core continues to run the validated code from the trusted memory space, and loads and validates HB extended functions (HBI). After the HBI is measured and the signature is verified and copied, its measurement (image hash), indicating valid authentication, is recorded in the TPM, as indicated by Step 1 in Figure Secure and Trusted Boot flow. At this point, all code that is run is fully contained in the PNOR flash chip and the system has not been accessed by any other mechanisms. This is referred to as the boundary of the trusted boot. In case the verification fails, the system is immediately stopped and is protected by hardware protection mechanisms to prevent execution of untrusted or rogue code.

The HB code then manages any pending updates of the secure nonvolatile memory by using a new trusted image. To protect the Core Root of Trust (CRTM), the HB code locks the secure memory, thereby preventing any further write access to that memory (this action means that if the system is rebooted, it returns to this trusted state). The HB code then initializes the on-chip memory controller and the attached memory dual inline memory modules (DIMMs). The HB code also initializes other chips that are directly attached to the processor on which it is running before it establishes the memory coherent interface to the other chips in the system. These other chips are also verified to ensure that they are in a secure and trusted state.

Higher firmware stack components are then loaded, verified, run, and their measurements are recorded in the TPM. This action completes Step 2, which is indicated in Figure Secure and Trusted Boot flow. In Step 3 of the figure Secure and Trusted Boot flow, the Power Hypervisor (PHYP) payload is loaded into main memory. Then, the code is cryptographically authenticated and after successful authentication, the PHYP starts to run. The authentication measurement of the PHYP code is recorded in the TPM. Similarly, Steps 4 through 8, which are indicated in Figure Secure and Trusted Boot flow are performed to load the code from unlocked flash memory to trusted memory, the code is cryptographically authenticated, and then various adjuncts and partition firmware (PFW) are run.