Secure Boot is an industry security standard introduced in UEFI (Unified Extensible Firmware Interface) version 2.3.1, which ensures only authorized EFI binaries are loaded by firmware during the boot process. As such, it helps secure a system from malicious early boot code “rootkit” or ”bootkit” vulnerabilities, providing a trusted execution environment for the OS and user applications. This is of increasing importance to security conscious users in these unpredictable times.
In OneFS 9.3, the familiar boot path components remain in place, but are enhanced via the addition of new code and libraries to deliver Secure Boot functionality. Specifically, the BIOS is updated, and the bootloader and kernel are modified for verifying signatures. Secure Boot only runs at boot time, and uses public key cryptography to verify the signatures of signed code and establish a chain of trust to the platform, loading only trusted/validated code.
Introduction of Secure Boot necessitates that all OneFS releases from 9.3 onwards now be signed. If Secure Boot is disabled or unsupported in BIOS, no signature verification is performed, and the feature is considered dormant. OneFS 9.3 Secure Boot goes beyond the standard UEFI framework to include OneFS kernel and modules. As such:
UEFI Secure Boot + OS Secure Boot = Secure Boot
The UEFI infrastructure performs EFI signature validation and binary loading within UEFI Secure Boot, and the BSD ‘veriexec’ function is used to perform signature verification in both the loader.efi and kernel.
Public key cryptography is used to validate the signature of signed code before it can be loaded and executed. Under the hood, Dell’s Code Signing Service (CSS) is used to sign all EFI binaries (platform FW), as well as the OneFS bootloader, and kernel and kernel modules
With OneFS 9.3 and later, automated code signing is now an integral part of the Onefs build pipeline infrastructure, which includes an interface to the Dell CSS for signing keys access. Keys and signature databases are pre-enrolled in the BIOS image and there is intentionally no interface between OneFS and key management to eliminate security risks.
The OneFS Security Configuration Guide includes a recommendation to and instructions for configuring a BIOS GUI admin password.
In OneFS 9.3, Secure Boot feature requires the following prerequisites:
- Isilon A2000 node platform
- OneFS 9.3.0.0 or greater
- Node Firmware Package (NFP) version 11.3 or greater
Be aware that a cluster must be upgrade-committed to OneFS 9.3 prior to upgrading the NFP to v11.3.
A PowerScale cluster will happily contain a mix of Secure Boot enabled and disabled nodes, and no additional is required in order to activate the feature. Indeed, Secure Boot can be enabled or disabled on an A2000 node at any point without any future implications. Additional PowerScale hardware platforms will also be added to the Secure Boot support matrix in future releases.
Since Secure Boot is node-local, it does necessitate individual configuration of each applicable node in a cluster. The configuration process also requires a reboot, so a suitable maintenance window will need to be planned for enabling or disabling Secure Boot. As a security best practice, it is strongly recommended to configure a BIOS admin password in order to restrict node access. Since Secure Boot is only executed at boot time, it has no impact on cluster performance.
The Secure Boot feature can be easily enabled on an A2000 node as follows:
- First, ensure that the cluster is running OneFS 9.3 and Node Firmware Package 11.3 or greater.
- Next, run the following CLI commands to enable the PowerScale Secure Boot feature:
# ipmitool raw 0x30 0x12 0x08 0x13 0x01 0x53 0x55 0x42 0x54 # ipmitool raw 0x30 0x11 0x04 0x00 0x08 0x13 0x01 08 13 01 53 55 42 54
The output ‘08 13 01 53 55 42 54’ indicates successful command execution.
# ipmitool raw 0x30 0x12 0x0C 0x13 0x01 0x01 # ipmitool raw 0x30 0x11 0x01 0x00 0x0C 0x13 0x01 0c 13 01 01
Similarly, the output ‘0c 13 01 01’ indicates successful command execution.
- Finally, reboot the node to apply the PowerScale Secure Boot feature.
The following sysctl CLI command can be run to verify that secure boot is enabled on the node:
# sysctl security.mac.veriexec.state security.mac.veriexec.state: loaded active enforce locked
Since Secure Boot configuration is node-local, this procedure will need to be performed on each A2000 node in the cluster.
Be aware that once the PowerScale Secure Boot feature is enabled on a node, it cannot be reimaged via PXE. However, reimaging from a USB drive is supported. If a node does require PXE reimaging, first disable Secure Boot, reimage, and then re-enable Secure Boot when completed.
Conversely, disabling the PowerScale Secure Boot feature can only be performed from the BIOS interface, which involves interrupting a node’s boot sequence. This is to ensures that secure boot can only be disabled if you have both physical and administrator access to the node. Again, disabling the feature also necessitates performing the process on each Secure Boot enabled node. The following procedure will disable the PowerScale Secure Boot feature on an A2000 node:
1. During the early stages of the A2000’s boot sequence, use ‘F2’or ‘DEL’ to enter the BIOS setup menu, navigate to the ‘Security’ tab, and select the “Secure Boot” option.
2. Next, set the “Secure Boot” entry from ‘Enabled’ to ‘Disabled’ to deactivate the PowerScale Secure Boot feature.
3. Finally, ‘ESC’ to return to the main menu, navigate to the ‘Save & Exit’ tab, and select the ‘Save Changes and Exit’ option.
Once Secure Boot is disabled, the A2000 node will continue to boot after exiting the BIOS.
In future OneFS releases, Secure Boot will be expanded to encompass additional PowerScale platforms.