PowerVM

POWER systems are known to provide a highly secured server platform. POWER9 hardware and firmware are making substantial improvements to make it even more secure for Cloud deployment with the addition of Secure Boot built on a host processor based chain of trust. Our previous blog addressed the concepts of Secure and Trusted Boot along with an overview of Secure Boot. Here we will dig a bit deeper into the host processor based chain of trust.

Host Processor Based Chain of Trust
POWER9 Secure Boot implements a host processor based chain of trust. The chain starts with an implicitly trusted component with other components being authenticated and integrity checked before being executed on the host processor cores. Verification code from locked processor SEEPROM (Serial Electrically Erasable Programmable ROM) validates the initial Firmware load. Firmware verifies cryptographic signatures of all subsequent “to be trusted” firmware that is loaded for execution on the POWER9 cores. On a POWER9 system, SEEPROM Security Switches are set in Self-Boot Engine (SBE) code and locked down on the system manufacturing line to provide the basis for hardware enforcement of secure IPL flows. Secure IPL facilitates the further development of a trusted computing POWER platform.

Secure Boot Flow
A flow diagram illustrating the operations for a Secure Boot IPL is shown in Drawing 1 below. Secure Boot establishes the locked SEEPROM, SBE, and Hostboot Base code (including a portion of Hostboot Extended code) as the core root of trust (CRTM) with the chain of trust extended to include PHYP, PFW, selected adjunct partitions (pTPM, vTPM, Hostboot Runtime, and Encryption adjuncts) and On Chip Controller (OCC – thermal management). Coupled with the processor hardware security support, this trust domain ensures that it is not feasible to silently display or alter customer data through any hardware or firmware mechanisms.

The entire trusted firmware stack is authenticated through the use of signed images and run in trusted memory locations. The FSP is outside the host server trust domain being an entity whose access is blocked to the Address/Display Unit (ADU) registers and other protected registers and trusted 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 environment with key players is shown in Drawing 2 below.

The secure boot process starts with the service element (FSP) 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 skipping this initial step. The access from the FSP to internal chip resources is locked and the SBE starts fetching initialization code from on module secure non-volatile locked memory. This code performs basic chip initialization and reset of the Trusted Platform Module (TPM). 

Once the above boot step has completed, the SBE loads 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 trusted 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 by step 1 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. This is referred to as the Trusted Boot Boundary (TBB) in Drawing 1. In case the verification has failed, the system is immediately stopped under hardware control to prevent execution of untrusted or rogue code.

The HB code then takes care of any pending update of the secure non-volatile memory with a new trusted image. It then locks down the secure memory preventing any further write access to that memory 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 step 2 where HBI begins execution (Drawing 1), the PHYP payload is loaded into main memory in step 3, the PHYP code image is cryptographically authenticated and on successful authentication, the execution of PHYP is started. The authentication measurement of the PHYP code is recorded in the TPM. Similarly, steps 4 thru 8 in the execution flow in the diagram are performed to load code from unlocked flash to trusted memory, cryptographically authenticate, measure, and then execute various adjuncts and PFW, respectively.

In a subsequent blog, we will introduce the attestation framework making use of the measurements recorded on the IPL path in the physical TPM referenced above.

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