2021 Call for Code Awards: Live from New York, with SNL’s Colin Jost! Learn more

OpenPower secure and trusted boot, Part 2: Protecting system firmware with OpenPOWER secure boot


IBM® OpenPOWER servers offer two essential security features, trusted boot and secure boot, to help ensure the integrity of your server and safeguard against a boot code cyberattack. Trusted boot works by creating secure recordings, or measurements, of executable code as the system boots. Using a process known as remote attestation, you can retrieve these measurements securely and use them to verify the integrity of your firmware or target operating system (OS).

Secure boot helps ensure the integrity of your OS and firmware as well. But rather than taking measurements for later examination, secure boot performs the validation in place, during boot, and will halt the boot process if the validation fails. These two features are complementary and work together to provide comprehensive protection of platform boot code. This article explores the secure boot method, with particular focus on protection of system firmware.

Secure boot versus trusted boot

Secure boot: Verify and enforce.

Trusted boot: Measure and record.

  • Secure boot protects system integrity by preventing execution of malicious code during boot.
  • Trusted boot creates measurements to prove that a particular chain of events happened during boot. Later these measurements can be examined to determine whether or not they represent trusted events.

Part 1 of this series, Using trusted boot on IBM OpenPOWER servers, explored trusted boot in detail. It explained how trusted boot performs integrity measurements and records these measurements to the trusted platform module (TPM), and how you can retrieve these measurements through remote attestation and use them to verify firmware integrity. The role of trusted boot is to enable detection of unauthorized system firmware, or the loading of an unauthorized operating system or boot configuration.

In Part 2 we will explore secure boot. Secure boot protects system integrity by preventing the execution of malicious code during boot. Secure boot checks the authenticity of each executable module as it is loaded from flash memory. If the verification fails, the boot process is halted. The role of secure boot is to prevent the execution of unauthorized firmware, or the loading of an unauthorized operating system or configuration.

With trusted boot, it is possible to use remote attestation to determine whether the system booted authorized firmware, OS, and configuration, and to use this check to control access to network- based resources. For example, an operating system could be denied access to a protected data store, or a hypervisor denied access to a protected guest image, until the host software and configuration has been verified. This of course requires services external to the server, and so is well suited to a data center or cloud computing environment where existing authorization and provisioning systems may be leveraged. Secure boot, by contrast, performs its checks locally and requires no external services.

As described in Part 1, secure boot is also used to establish the core root of trust for measurement, or CRTM, a necessary foundation for trusted boot. The CRTM ensures that the measurements written to the TPM are performed by authorized code. Establishing the CRTM on OpenPOWER systems requires a minimal implementation of secure boot in firmware. In this article we will describe how secure boot is used to validate components beyond the CRTM.

Secure boot protection of platform firmware

Secure boot ensures the integrity of platform firmware by verifying each executable component against a cryptographic signature. When an OpenPOWER server boots, the boot process loads a series of executable firmware components from flash memory. When secure boot is enabled, each component in the boot sequence verifies the integrity and the authenticity of the next before allowing that component to run. The integrity is verified by a secure cryptographic hash, such as SHA512, and the authenticity is verified by a cryptographic signature, such as Elliptic Curve Digital Signature Algorithm (ECDSA).

Secure boot works by establishing a chain of trust for all executable components. This chain of trust is anchored in hardware, meaning that secure boot trusts the very first bit of code to execute because it is stored immutably in system hardware. Each component that runs subsequently, however, is loaded from an unprotected location in flash memory and so is untrusted until verified. Secure boot stores each of these components in flash memory in a secure container that includes a cryptographic signature. For every component loaded, secure boot authenticates the component against this signature, and stops the boot if the check fails.

Secure boot provides a complete chain of trust, anchored in platform hardware, for all executable boot code.

How an OpenPOWER server boots

Figure 1 shows an overview of the OpenPOWER boot flow. When the system receives the power- on signal – through the power button or through the baseboard management controller (BMC) – a tiny bit of code called the self-boot engine (SBE) begins loading the OpenPOWER firmware from flash memory. Several stages of boot code are loaded, including Hostboot and the Open Power Abstraction Layer (OPAL). (The firmware-level boot flow is described in more detail in a following section).

After a few steps, the firmware reaches the Petitboot bootloader stage. Petitboot is the platform bootloader for OpenPOWER. Petitboot is a flexible bootloader that runs in an embedded Linux® kernel. Petitboot runs an intelligent discovery process to find bootable media on local storage devices or available over the network. Petitboot then selects a target boot device based on a preconfigured boot order, or based on user input (such as selection from a boot menu), and attempts to load the operating system.

Figure 1. OpenPOWER boot flow

Secure boot security domains

The OpenPOWER secure boot function consists of two security domains, the firmware domain and the operating system (OS) domain. The firmware domain governs the boot of platform firmware up to and including Petitboot. The operating system domain governs the boot of the target OS or hypervisor.

Each domain has an associated set of cryptographic keys for verifying the authenticity of boot code within the domain. The keys associated with the firmware domain are referred to as the hardware (HW) keys and firmware (FW) keys. The keys associated with the OS domain are the platform key (PK), key-exchange keys (KEK) and the software key database (DB) keys.

Each set of keys forms a hierarchy, with a designated root key – the HW keys in the case of the firmware domain, and the platform key (PK) in the case of the OS domain – and one or more levels of keys under the authority of the root. At the lowest level of each hierarchy are the code-signing keys, used to digitally sign the components authorized to run on the system. In the firmware domain, the FW keys are used to sign the executable firmware modules. In the OS domain, the DB keys sign the bootable OS images (for example, the Linux kernel). The key hierarchies are shown in Table 1.

Secure boot domain Keys Function Root key? Private key holder (typical)
Firmware domain HW (Root) keys The authority for the domain; used to sign FW keys Yes Platform vendor
FW keys Used to sign the firmware components; authorized by HW keys No Platform vendor
Operating System domain Platform key (PK) The authority for the domain (root key); used to sign KEK keys and authorize updates to KEK database Yes Platform owner
Key-exchange keys (KEK) Used to sign DB keys an authorize updates to software key No OS vendor
Software key database (DB) keys Used to sign target OS or hypervisor (that is, bootable Linux kernel) No OS vendor or platform owner

The keys are asymmetric keys, meaning that each has a public portion and a private portion. The private portion–or so-called private key–must be protected (kept secret) by the key owner. The public portion, or public key, may be distributed openly. Functionally, the public key is used to verify a signature created by the private key.

For the firmware domain, the HW and FW private keys are typically controlled by the platform vendor: IBM or the original design manufacturer (ODM); or, the private keys may be held the end- customer (platform owner). For the OS domain, the private PK is held by the platform owner. The key-exchange keys are typically controlled by the OS vendor, such as Red Hat, SUSE, or Ubuntu. The DB keys are controlled by the OS vendor or the platform owner.

OpenPOWER secure boot provides independent security domains for firmware and operating system, each protected by a cryptographic key hierarchy.

As shown in figure 1, each domain relies on a root of trust stored in (or protected by) platform hardware. For the firmware domain, the root of trust is a secure hash of HW Root keys, stored in a protected area of flash memory known the serial electrically erasable programmable read- only memory (SEEPROM). For the OS domain, the root of trust is the software platform key (PK), stored in the TPM NVRAM.

Note that the Petitboot bootloader is under the authority of the firmware domain because the Petitboot module itself is signed by the FW keys. Petitboot uses keys from the OS domain to verify the signed Linux kernel.

OpenPOWER firmware boot sequence

Figure 2 shows the firmware-level boot flow in more detail. The boot begins with the processor’s self boot engine (SBE) code. The SBE has several stages, with the first part stored in processor one-time programmable read-only memory (OTPROM) and another part stored in the SEEPROM module located on the POWER processor module. The SBE (OTPROM) initializes the pervasive bus, which is used for communication within the POWER processor, then directs the processor to begin executing code from SBE (SEEPROM).

Figure 2. OpenPOWER firmware boot flow

SBE (SEEPROM) performs several tasks, including initializing access to the host processor-based NOR flash memory (PNOR), where the remainder of the OpenPOWER firmware is stored. The PNOR is divided into logical partitions, each containing a firmware module. The first image to be loaded is Hostboot Base (HBB), which contains the Hostboot executable core, plus the drivers and utilities necessary to initialize additional Hostboot functions. These additional functions are stored in the Hostboot extended image, which is the next image loaded from PNOR.

Hostboot performs several steps, including initializing the Powerbus and creating the POWER device tree. Hostboot also loads and initializes the sleep-winkle image (SLW), used for power state control, and Hostboot runtime services (HBRT). Finally, Hostboot loads the OPAL and passes control.

OPAL initializes the host Peripheral Component Interconnect Express (PCIe) bus and discovers available adapters. Finally, OPAL loads and executes the Petitboot bootloader, which will in turn load the OS.

Here is a more detailed description of the functions performed by each OpenPOWER firmware module:

  • Self boot engine (SBE) (OTPROM) – Micro-controller used to start the boot process. Initializes the pervasive bus, providing communication within the IBM POWER® processor. Jumps execution to SBE (SEEPROM)
  • Self boot engine (SBE) (SEEPROM) – Initializes a single processor core, and L2, L3 caches. Also:
    • Initializes chiplet functions (independent functional units within the POWER processor)
    • Resets the TPM
    • Initializes access to PNOR flash
    • Loads HBB from PNOR to L3 cache, executes HBB
  • Hostboot base (HBB) – The core, or kernel, of the Hostboot module. Provides the general execution environment, message passing, task control, memory management, and interrupt support for the POWER processor
  • Hostboot extended image – The remainder of Hostboot functionality, in the form of a container holding Hostboot sub-component code with table of contents, also referred to as the Hostboot extended table. Hostboot performs the following initialization functions at boot time:
    • Initializes the Powerbus, connecting the processor to external resources such as cache, main memory, and I/O
    • Initializes memory controllers, performs DRAM (main memory) training (timing and throughput optimization) and initialization
    • Loads and initializes the sleep-winkle image (SLW) for each core, issues a winkle- wakeup call to each core
    • Creates the POWER device tree, a memory structure holding attributes and system configuration information
    • Loads and initializes Hostboot runtime (HBRT) services
    • Loads and transfers execution to OPAL layer
  • Sleep-winkle (SLW) – Mini execution engine responsible for moving the processor, L2, and L3 caches between fully powered state, sleep state (core powered off, cache active), and winkled state (core and caches powered off)
  • On chip controller (OCC) – The executable image for the OCC, an embedded subprocessor that controls the thermal and power management functions for the processor
  • Hostboot runtime (HBRT) – The portion of Hostboot that remains resident during OS execution to provide processor and memory runtime diagnostics and interface to OCC
  • OpenPOWER abstraction layer (OPAL) – Initializes the PCIe bus, provides a standard interface to POWER platform services to operating system layer
  • Petitboot bootloader – an embedded Linux kernel containing the Petitboot bootloader application. Discovers bootable media, builds and displays a boot menu, and loads the runtime operating system

To learn more about Hostboot, OPAL, and the OpenPOWER boot process, we encourage you to view the OpenPower Firmware Documentation.

OpenPOWER secure boot flow

As mentioned, secure boot establishes a chain of trust for all executable components by requiring each component to verify the next before allowing that component to run. We say the chain of trust is anchored in hardware, because the very first bit of code to execute, the SBE, is stored immutably in the processor’s OTPROM. The second part of SBE is stored in protected SEEPROM, which cannot be updated without the authority of the HW Root keys or by asserting physical presence at the machine.

The remaining firmware is stored in PNOR, which is essentially an unprotected location in flash memory. The PNOR is accessible through the BMC and can be updated through a standard firmware flash operation. Using the proper device drivers, it is also possible to modify PNOR through the runtime operation system. While these methods should be secured by password protection, any such protection is beyond the purview of the firmware root of trust. The OpenPOWER secure boot implementation assumes that the PNOR is untrusted.

OpenPOWER secure boot assumes firmware components are untrusted until verified.

To protect the firmware installed in PNOR, each component is stored in a secure container that includes a cryptographic signature. As each module is loaded, the secure boot code in the previous module will use this signature to verify the integrity and authenticity of the module to be executed. SBE (SEEPROM) verifies HBB, HBB verifies Hostboot extended image, and so on. If any check fails, secure boot halts the system.

Secure boot is enabled by means of a secure mode override jumper on the system board. When the jumper is removed, secure mode is in force and the secure boot code in each component is activated. When the jumper is in place, secure mode is disabled, in which case the boot process will ignore the container metadata and load any image from PNOR, signed or unsigned.

Secure mode status is conveyed to the upper firmware layers (OPAL and petitiboot) through a entry in the POWER device tree. When secure mode is enabled, the created in the device tree as shown below:

# ls -l /proc/device-tree/ibm,secureboot/ total 0
-r--r--r--    1 root    root    18 Apr 1 06:00 compatible
-r--r--r--    1 root    root    7 Apr 1 06:00 hash-algo
-r--r--r--    1 root    root    64 Apr 1 06:00 hw-key-hash
-r--r--r--    1 root    root    15 Apr 1 06:00 name
-r--r--r--    1 root    root    4 Apr 1 06:00 phandle
-r--r--r--    1 root    root    0 Apr 1 06:00 secure-enabled

This device tree node also contains a representation of the HW key hash imprinted in SEEPROM. This is a SHA512 hash of (the public portion of) the three HW Root keys.

# cat /proc/device-tree/ibm,secureboot/hash-algo sha512

# cat /proc/device-tree/ibm,secureboot/hw-key-hash | xxd -p 40d487ff7380ed6ad54775d5795fea0de2f541fea9db06b8466a42a320e6 5f75b48665460017d907515dc2a5f9fc50954d6ee0c9b67d219dfb708535 1d01d6d1

Firmware key hierarchy

As shown in Table 1, the firmware domain employs a two-level key hierarchy. The root keys are the HW keys, and the signing keys are the FW keys. In short, the HW keys sign the FW keys, and FW keys sign the firmware components. There are three keys in each set, which allows for a potential separation of duties within the signing process.

These are asymmetric keys, with each having a public portion and a private portion. The current implementation specifies the use of a 512-bit ECDSA key. The private keys must be kept secure, and should be stored in a hardware security module (HSM) like an IBM 4767 PCIe Cryptographic Coprocessor. The public keys are added to the component container so that they are available for the signature check during boot.

To anchor the key hierarchy in hardware, a SHA512 hash of the public portion of the three HW Root keys is installed in protected flash memory in the POWER processor SEEPROM. The process for installing this hash is referred as the imprinting process, and this is done (normally once) by the platform vendor or platform owner. When secure boot loads containers from PNOR, it checks the hash of the HW keys in each secure container against the value stored in SEEPROM. This is how secure boot verifies that the keys used to sign the firmware are properly authorized.

OpenPOWER firmware is stored in flash memory in secure containers, which provide the metadata necessary to enable secure boot verification.

Secure firmware containers

Each component of OpenPOWER firmware is packaged in a secure container that holds the hash and signature values required to support secure boot verification. The container is in fact a metadata header prefixed to the firmware image.

Figure 3 shows a simplified view of the container layout. The header is created during the firmware build process, or it can be created at some later packaging step. To build the header, the process performs the following steps:

  1. Adds a (SHA512) hash of the firmware image (the container payload) to a region of the header known as the firmware header.
  2. Requests a signature over the firmware header to be created by the holder (or holders) of the three FW keys, then adds these signatures to an adjacent region immediately following the firmware header.
  3. Calculates a hash of the three FW keys and adds this to a region of the header known as the prefix header.
  4. Requests a signature over the prefix header to be created by the holder (or holders) of the three HW keys and adds these signatures to a region immediately following the prefix header. (In a manner of speaking, the FW keys are the “payload” signed by the HW keys.)
  5. Adds a copy of the public HW keys to a region called the hardware header, and a copy of the FW public keys to the payload region of the prefix header.

Figure 3. Construction of a secure boot container

Note that the diagram shows the signing operations as being performed by HW and FW keys in the container header. In fact, the signing operations use the private HW and FW keys, which are kept secure. The keys added to the container header are the public keys, used for verification. The signing flow in the diagram is only a schematic representation.

The header contains no private keys or secrets, only enough public information to establish the trust chain for each signed payload. Secure boot will now have enough data to complete the three steps required to validate each payload:

  1. Verify the signature over the payload by the three FW keys.
  2. Verify the signature over the FW keys by the three HW keys.
  3. Verify that the hash of the HW keys matches the hash stored in processor SEEPROM.

If these three conditions are met, secure boot authorizes the component to run.

OpenPOWER firmware consists of several containers, packaged into a partitioned PNOR image. This PNOR image is what gets updated when you flash new host firmware to an OpenPOWER server.

Figure 4 shows the PNOR image layout. After the component headers are created, the process adds the containerized components to the PNOR image, with any necessary padding, then creates a table of contents (TOC) listing the partition offsets.

Figure 4. PNOR image layout

Firmware key management

The private portions of the HW and FW keys will be managed by IBM, the ODM vendor or the end-customer, depending on the procurement method and the application. When you buy an OpenPOWER server from IBM, the system will be shipped with a hash of the IBM HW keys installed in SEEPROM. You will obtain your firmware updates from IBM, through IBM Fix Central, for example. When IBM packages the firmware for release, the containers will be built using IBM- managed keys. IBM’s manufacturing process specifies that these keys are stored in an HSM, where the private keys are never actually exposed outside the HSM. When the server is in secure mode, it will refuse to boot any firmware not signed by IBM.

Similarly, if you purchase your OpenPOWER server from an ODM vendor, the system will be shipped with a hash of the ODM’s HW keys installed in SEEPROM. You will obtain your firmware updates from the ODM, through their supported channels.

The key hierarchy can support other usage models as well. An enterprise using OpenPOWER servers may choose to manage its own keys and sign its own firmware. An example would be data center customers who want to build their own firmware due to security or functional requirements of an enterprise-specific nature. In this case the enterprise can install its own HW key hash into system SEEPROM. This is done through the imprinting process, which we will describe shortly. The enterprise is then responsible for signing its own firmware and building its own PNOR image to flash.

Within the enterprise, the use of the two-level key hierarchy permits a separation of duties between the groups responsible for building the different firmware modules (Hostboot, OPAL, and so on), assuming such separation exists. Secure boot will permit the use of different FW keys for each firmware module, provided each set of FW keys is signed by the same HW keys. The HW key holders, then, have authority over all firmware modules in PNOR and hence, authority over the machine.

As mentioned, the use of three keys in each set, HW and firmware, permits a separation of duties for each signing operation. When all three are used, secure boot requires a signature by all three keys to be present in the container header. This means that all three FW key holders must sign off on a firmware module to make it bootable, and all three HW key holders must sign off on the FW keys to authorize their respective modules.

Updating the platform HW keys (key transition)

The holders of the three HW keys are effectively the platform owners, because it is the hash of these keys that is imprinted in SEEPROM. With secure mode in force, the system will refuse to boot any firmware not authorized by these keys.

The platform owner may choose to change the HW Root keys by updating the HW key hash in SEEPROM. This is done through the imprinting process. First, the user prepares a special PNOR image that contains a transition container. The transition container is a container that is signed with the current HW keys, but carries a payload signed with the new HW keys. This payload is in fact an embedded container. The embedded container resembles a normal container, only it is signed with the new HW keys rather than the current keys. This is shown in Figure 5.

Figure 5. PNOR image with transition container

When the system boots it detects the presence of the transition container in PNOR. Specifically, the Hostboot module performs this function. It then checks that a key transition bit is set within the signed portion of the Prefix header. If so, Hostboot enters the key transition code. Note that all executable code to this point has been verified by the current HW keys.

The transition code now reads the embedded container. The HW key fields in this container header hold the new HW keys (the ones to transition to), with corresponding signature fields that were generated by these keys. Before performing the SEEPROM update, the transition code does all the normal validation steps for this container using the new keys, just to verify that the keys are usable. This ensures that SEEPROM won’t be updated with an unusable set of keys.

The transition code now has everything it needs to update SEEPROM. The operation is authorized, because only the holder of the current keys could create this package. The new keys are good, because they have been used to sign at least one valid container. The transition code now calculates the (SHA512) hash of the new keys and writes this value to SEEPROM, overwriting the current value. At this point, the system halts and shuts down.

Next, the user flashes a new PNOR image signed with the new HW keys. From this point on, all images must be signed with these keys. The system now boots normally. Note that secure mode was enabled the entire time, and physical presence was not required. The user may do all operations remotely through the BMC.

Replacing the platform HW keys (key recovery)

In the case where the user is not the holder of the current HW keys, or the keys are lost (private key unrecoverable), physical presence is required to replace the HW key hash in SEEPROM. The user must install the secure mode override jumper. The process is then the same as above, except that the transition container is not signed with the current HW keys.

After the SEEPROM update, the user flashes a new PNOR image signed with the new keys, removes the secure mode override jumper, and powers on the system. The system will now boot normally in secure mode. From this point on, all images must be signed with the new HW keys.

OpenPOWER open source firmware

The previous sections describe some of the secure boot function and code. On OpenPOWER, all of the firmware components are open source, meaning that the source code is available for anyone to see. By examining this code you can inspect the secure boot functions previously described.

OpenPOWER firmware is built using the OpenPOWER Firmware Build Environment or op-build, hosted on the open source collaboration site Github. op-build uses buildroot to create a toolchain and build the various firmware components including Hostboot, skiboot, OCC and the Petitboot bootloader. Most of the code commits pertaining to secure boot are labeled with some variation of “secure”, secure boot” or “secureboot”, and you can find these commits by perusing the list or searching for these terms. For example, the library that implements secure and trusted boot in skiboot is called libstb. The libstb API was committed to skiboot on September 28, 2016 under commit ID, d15dd47.

OpenPOWER secure boot firmware is implemented entirely in open source code, with security functions based on open standards.

OpenPOWER is an open platform

The OpenPOWER key transition process ensures that the platform owner may always gain authority over the machine, regardless of how the system was configured when it was delivered. It is not possible to configure OpenPOWER secure boot in a way that is irrevocably locked to the original platform owner.

The OpenPOWER open source firmware ensures that the platform owner always has the choice of running the system with an open firmware stack, in secure mode, regardless of what firmware was installed when the system was delivered. An enterprise user, or individual user, updating the HW key hash with a new public key hash, may sign and securely boot his or her own firmware.

Note that OpenPOWER secure boot does not preclude the use of vendor-specific, or even proprietary firmware. An ODM may still deliver secure, signed firmware based partly or entirely on closed source code, and choose not to publish source code on which proprietary features are based. OpenPOWER secure boot simply ensures platform owners have the option of running an open source firmware stack as an alternative, or any firmware of their choosing.

Establishing a new root of authority might not be something a typical platform owner will choose to do. It requires platform owners to sign their own firmware, because the system will no longer boot in secure mode with the ODM-signed package after the HW key hash has been updated. A platform owner who wants to maintain firmware at the latest available version–to install security patches, bug fixes, and functionality updates– will need to rebuild and resign the firmware periodically.

If the ODM-provided firmware meets the platform owner’s requirements for functionality, trust and openness, there might be little benefit for the platform owner to assume this responsibility. If however, the platform owner has functional requirements for firmware that are not met by the ODM, or chooses not to trust the ODM firmware (or any code by an external authority), the platform owner has the option of establishing a new, independent root of authority over the machine.

Updating OpenPOWER firmware

The OpenPOWER host firmware can be updated through the BMC using the pUpdate utility included in the firmware download package. The host firmware update consists of a single file with the extension .pnor, which contains the full contents of PNOR as described previously. In the following example, the user flashes a new PNOR image using the network-based or out-of-band method. The IP shown in the example is the IP of the BMC. The operation requires administrator- level privilege on the BMC.

$ pUpdate -pnor P8DTU20161202_IBM_prod_sign.pnor -i lan -h \
version str len=8
Version info are not available.
If the PNOR update fails, PLEASE TRY AGAIN. Transfer data ................
Load    335872 bytes, 33554560 bytes
Load  1678336 bytes, 33554560 bytes
Load  4027392 bytes, 33554560 bytes
Load 15099904 bytes, 33554560 bytes validating PNOR image ................ Image validation passed.
Updating PNOR flash ................ updating new PNOR firmware ...74% updating new PNOR firmware ...93% updating new PNOR firmware ...100% "PNOR Update Complete."

The update can be performed while the server is running, without affecting the operation of the running host. The firmware update takes effect on the next reboot.

The pUpdate utility is supported in Linux on both POWER and x86 systems, and the firmware download package includes a pUpdate executable for each architecture.

Verifying secure boot operation

When the system boots successfully in secure mode you can see the "secure mode on" message displayed on the system console during boot:

[ 4.142741818,5] NVRAM: Size is 576 KB
[ 4.334350410,5] STB: secure mode on. [ 4.335615219,5] STB: trusted mode on
[ 4.338939542,5] ROM: romcode driver registered
[ 4.340772248,5] TPM: tpm0 registered: driver=i2c_tpm_nuvoton felsz=2018

In the case of a secure boot failure, the console output depends on the failure mode. If the failure occurs early in the boot process– as would be the case if the very first image loaded from PNOR failed to verify–there would be no output to the system console at all. The failure would occur at the SBE stage, before access to the system console is initialized.

If the secure boot occurred at a later stage–as would be the case if some, but not all, PNOR images successfully verified–the console will display a failure message. In the following example, the system successfully booted as far as OPAL, but OPAL failed to verify the Petitboot bootloader module (referred to as BOOTKERNEL0 here):

Verification fail:
STB: sb_verify failed: resource BOOTKERNEL0 STB: Secure mode enforced, aborting.

This demonstrates that all firmware components must successfully verify for the system to boot. If any image is corrupt or compromised, secure boot will halt the system.


IBM OpenPOWER servers provide both secure boot and trusted boot functionality to help ensure the integrity of system firmware and guard against a bootcode cyberattack. Trusted boot works by generating secure measurements of vital system firmware and storing these measurements so they can be retrieved and independently verified. Secure boot works by strictly preventing the execution of corrupt or unauthorized firmware, and halting the system boot process if the firmware fails to verify. Together these features provide comprehensive protection of system boot code, on a platform based entirely on open standards and open source firmware.