UEFI, successor to legacy BIOS With HPE ProLiant Gen9 Servers

Contents Abstract ............................................................................................................................................................................................................................................................................................. 2 Introduction .................................................................................................................................................................................................................................................................................... 2 UEFI overview .............................................................................................................................................................................................................................................................................. 2

Why UEFI now? .................................................................................................................................................................................................................................................................... 3 Comparing UEFI to legacy BIOS ........................................................................................................................................................................................................................... 4

UEFI implementation in the ProLiant Gen9 servers ................................................................................................................................................................................. 6 ProLiant Gen9 server UEFI boot experience ............................................................................................................................................................................................ 6 Secure Boot .............................................................................................................................................................................................................................................................................. 8 PXE boot..................................................................................................................................................................................................................................................................................... 9 Boot from URL .................................................................................................................................................................................................................................................................. 10 UEFI Shell-based deployment ............................................................................................................................................................................................................................ 11

UEFI considerations ............................................................................................................................................................................................................................................................ 11 Functionality requiring UEFI ................................................................................................................................................................................................................................. 11 Upgrading existing resources ............................................................................................................................................................................................................................. 12 OS installation .................................................................................................................................................................................................................................................................... 12 Boot considerations ...................................................................................................................................................................................................................................................... 12 UEFI variables .................................................................................................................................................................................................................................................................... 13

Conclusion ................................................................................................................................................................................................................................................................................... 13 Resources, contacts, or additional links ...................................................................................................................................................................................................... 13

Technical white paper

Technical white paper Page 2

Abstract With the use of the Basic Input/Output System (BIOS) for PCs and servers extending over three decades, the need for a new firmware interface that is designed for today’s operating systems and hardware architectures is necessary. The Unified Extensible Firmware Interface (UEFI) addresses this need. HPE ProLiant Gen9 servers provide advanced UEFI functionality while preserving the ProLiant user experience that you expect. This document describes UEFI and its benefit to the modern data center. This document also discusses what you should consider when deciding whether to adopt UEFI or stay with legacy BIOS—an option all ProLiant Gen9 servers provide.

Introduction The BIOS running on many PC and server systems today is based on code initially developed in 1979. When BIOS became mainstream in 1981, PC architecture generally consisted of an 8-bit (single-core) processor, one or two floppy diskette drives, and a memory capacity typically measured in kilobytes. Enter the 21st century, where PCs and servers commonly have one or more multi-core processors, numerous I/O ports of different types, PCI devices with their own controllers, and terabytes of memory and storage space. Rising to this level of hardware complexity has required fixes and patches to legacy BIOS. Patching a system not originally designed for today’s expansive systems makes such fixes burdensome for operations and management.

UEFI overview UEFI is a firmware interface with the same basic purpose of legacy BIOS, but uses a different firmware stack. UEFI employs a modular structure (Figure 1) of drivers and files that are grouped into services that adapt well to complex and varied architectures. UEFI’s framework of coding scales easily with server design trends. Agnostic to the type of processor used in a platform, UEFI encourages architectural freedom, allowing us to offer a choice of CPUs within a server family.

Figure 1. UEFI relationship with the operating system and the hardware

Technical white paper Page 3

Why UEFI now? UEFI is not new to us. We have been involved in the UEFI forum since its inception in 2005, and we are currently on the board of directors for its over 250+ members. We implemented EFI—and then UEFI—in our Integrity server line and in the ProLiant DL580 Gen8 Server, and have been using UEFI in our client solutions (desktops, notebooks, and printers). Broad UEFI application to enterprise server solutions, however, has been prompted by recent trends, including:

• Expanded boot volume capacity

• Pre-boot security requirements and manageability needs

• Pre-operating system boot networking needs

• UEFI-only operating system requirements

• Expanded amount of I/O ports and bootable devices

• Remote provisioning

Expanded boot volume UEFI allows booting from hard drives larger than 2 TB. Legacy BIOS systems use the Master Boot Record (MBR) hard drive format, which limits a boot drive to a maximum capacity of 2 TB. While this limitation was not considered an issue years ago, hard drive capacities in the terabytes are common in today’s enterprise environments. Hard drives in UEFI-based systems use a new format called the global unique identifier (GUID) partition table or GPT. GPT allows far greater boot drive capacities, allowing you to use high-capacity drives for storage and system booting.

Pre-boot security requirements With the ability to access a UEFI-based system’s resources in a pre-boot environment, the issue of security becomes important. UEFI includes a Secure Boot function to protect against unauthorized operating systems and malware rootkit attacks, ensuring that only authenticated code can start on the system. When Secure Boot is enabled, UEFI uses public keys and certificates to verify the following:

• UEFI drivers loaded from PCIe cards

• Drivers loaded from mass storage devices

• Pre-boot UEFI shell applications including firmware updates

• Operating system UEFI bootloaders

If a signature verification fails, the process halts and the associated device will not be available for use. The system ROM carries the HPE Public Key, Microsoft® Windows® Production Key, SUSE Linux® Enterprise Server, and the UEFI CA Public Key. You can also create and enroll custom keys in the Secure Boot Custom Mode in the BIOS/Platform Configuration (RBSU). Secure Boot can only be disabled through secure access (through RBSU, a remote console to RBSU, or the RESTful API with proper iLO administrator credentials).

UEFI Secure Boot is a security measure that can complement the trusted boot function provided by the Trusted Computing Group’s Trusted Platform Module (TPM). While TPM is a hardware-based function that requires the optional TPM chip, UEFI Secure Boot is firmware-based and available with any UEFI-based system. Both UEFI Secure Boot and TPM can be used simultaneously. For more information on Secure Boot, refer to the additional resource links provided at the end of this document.

Pre-operating system networking needs The UEFI enhanced networking API allows for a rich network authentication (log-on) in a pre-boot environment. UEFI includes IPv4 and IPv6 networking stacks and provides PXE booting with the longer IPv6 addresses. UEFI also allows a server to multicast a single boot image to multiple units simultaneously. The ability to boot from a specified URL (offered by all ProLiant Gen9 servers) eliminates the need for physical or virtual media on a bare-metal system.

Pre-boot manageability needs UEFI-based systems can be easily and remotely managed by your IT personnel. UEFI offers complete access to the system hardware and resources, allowing UEFI diagnostics and troubleshooting applications to be run before loading an operating system. For instance, the UEFI Shell, accessible prior to OS boot, offers a number of OS-like functions for obtaining system information and manipulating files, and running UEFI applications. The RESTful API also offers platform configuration capabilities to an authorized user even while the server is down using the auxiliary-powered iLO interface.

Technical white paper Page 4

UEFI-only operating system capabilities Windows Server® 2012, while compatible with legacy BIOS systems, offers a number of functions that are only available to UEFI-based systems.

Expanded amount of I/O ports and bootable devices UEFI has a much greater ability than legacy BIOS in handling I/O port space, option ROM execution space, and large numbers of bootable I/O devices.

Remote provisioning The UEFI pre-boot networking capabilities let you connect directly to a website to download drivers and firmware and perform updates. In addition, re-imaging a system’s drive remotely from a backup server—without needing a system DVD—becomes a reality with UEFI.

Comparing UEFI to legacy BIOS UEFI clarifies the POST and boot processes with an enhanced user interface. No longer do you need to wonder when to press F9 to access the RBSU or a function key for a particular option ROM. Neither do you have to reboot after configuring an option in UEFI—UEFI will prompt you if a reboot is necessary. The BIOS/Platform Configuration (RBSU) menu is analogous to the RBSU of legacy BIOS. With UEFI, however, all parameters—system and options—are accessed from the UEFI System Utilities menu, allowing you to make any necessary changes in one continuous session. The UEFI System Utilities is available on all Gen9 servers except the ML10 Gen9 server. For more information about the ML10 Gen9 server, see the QuickSpecs for that server.

While the legacy BIOS interface was restricted to VGA mode with limited graphics, UEFI employs a more robust text and graphics interface that is more intuitive and informative. Figure 2 compares the RBSU screen in UEFI (Figure 2A) to the RBSU screen in legacy BIOS (Figure 2B).

A: UEFI RBSU screen B: Legacy BIOS RBSU screen

Figure 2. UEFI versus legacy BIOS user interface

Using established protocols, APIs, and drivers, UEFI has full access to processor, storage, network, and video components for a much richer pre-boot environment than legacy BIOS. Video and storage functions in particular are handled differently in UEFI. Table 1 compares characteristics of key functions of UEFI with those of legacy BIOS.

Technical white paper Page 5

Table 1. Comparison of key functions between UEFI with legacy BIOS

Function UEFI characteristic Legacy BIOS characteristic

Video services Pre-boot video functions available thru Graphics Output Protocol (GOP) for full graphics display.

Pre-boot video displays in VGA text mode with limited graphics. Requires INT10h and video BIOS after boot.

Storage services Available in pre-boot environment through Block I/O protocol. Requires INT13h after boot.

Bootloader initialization Specified as a file/path name on a storage device. Multiple bootloader files can co-exist on a sector/device, allowing the user to specify which loader through the Boot Device Selection service.

Specified in x86 real mode code located in the boot partition of master boot record (MBR). BIOS service INT19h initiates the bootstrap loader sequence. Only one bootloader per device is allowed.

Hard drive boot format GPT and MBR MBR (boot partition size limited to <2 TB)

Advanced Configuration and Power Interface (ACPI) compliancy

ACPI specification 5.0a has been incorporated into the UEFI portfolio. Moving forward, the ACPI spec will be maintained by the UEFI forum, ensuring that UEFI-compliant systems are ACPI-compliant.

With future ACPI specs under UEFI forum control, compliancy by future legacy BIOS-based systems will be an OEM responsibility.

Table 2 compares the capabilities between Linux distros RHEL 5.9 (and later), RHEL 6.3 (and later), and SLES 11 SP3; Windows Server 2008 R2 and Windows Server 2012 in UEFI mode and Legacy BIOS mode.

Table 2. Comparison of OS capabilities based on BIOS and UEFI modes

Linux distros: RHEL 7, SLES 11 SP3 Windows Server 2008 R2 Windows Server 2012 and 2012 R2

OS function UEFI BIOS UEFI BIOS UEFI BIOS

Boot disk format GPT MBR GPT MBR GPT MBR

PXE multicast (deploying an image to a number of clients concurrently)

Yes No Yes No Yes No

Secure Boot Yes No No No Yes No

BitLocker network unlock (Option for easier management of BitLocker-enabled servers)

N/A N/A No No Yes No

Boot to device from OS (native boot to device menu)

Yes No No No Yes No

Attestation (verification of hardware)

N/A N/A No No Yes Yes

Measured boot (OS measurement of component FW and drivers stored in TPM to protect against boot threats)

N/A N/A Yes Yes Yes Yes

Seamless boot (smoother POST/boot process from pre-boot to OS environment with less screen displays)

No N/A Yes No Yes No

VGA (graphics mode)

No Yes Yes Yes No Yes

Note: This table identifies OS capabilities that may or may not be capabilities of current hardware.

Technical white paper Page 6

UEFI implementation in the ProLiant Gen9 servers We offered an HPE-enhanced UEFI in the ProLiant DL580 Gen8 Server. This superset of the standard UEFI specification is now included with all ProLiant Gen9 servers.

Our enhanced UEFI offers robust functionality including:

• Configuring system devices and installed options.

• Best-in-industry implementation of Secure Boot that allows the system firmware, option card firmware, operating systems, and the HPE iLO 4 management engine to collaborate to enhance platform security.

• Preboot eXecution Environment (PXE) boot operation over IPv4 and IPv6 networks.

• PXE Multicast Boot allowing for faster PXE deployments for large numbers of servers.

• Boot from URL (http or FTP).

• Enabling and disabling system features.

• Enhanced UEFI Shell that provides a pre-boot environment and network deployment.

• Operating system specific functionality such as Microsoft Windows Server 2012, which enables several features only when installed in UEFI mode.

• ProLiant user interface that is intuitive and informative, with Quick Response (QR) codes to access the UEFI System Utilities and Shell Command Mobile Help for HPE ProLiant Gen9 Servers with your mobile device.

The UEFI pre-boot networking capabilities facilitate ProLiant Gen9 servers’ ability for Intelligent Provisioning. Intelligent Provisioning replaces the process of using CDs/DVDs for loading or updating firmware and software, lets you connect directly to hpe.com to download drivers and firmware, performs updates, and installs the operating system in the same step.

ProLiant Gen9 servers support both UEFI Boot Mode (default) and Legacy BIOS Boot Mode. This dual functionality (known as UEFI Class 2) allows ProLiant Gen9 servers to be used in infrastructures that are still legacy BIOS-based but might transition to UEFI in the future. Some server models like the HPE ProLiant XL260a Gen9 support a UEFI Class 3 implementation and have UEFI boot mode only.

ProLiant Gen9 server UEFI boot experience The boot process for UEFI-based ProLiant Gen9 servers is similar to legacy BIOS systems, but offers you more options. Starting a ProLiant Gen9 server includes the following steps:

1. Power on (or reboot) the system. The following POST functions are performed:

a. CPU and chipsets are initialized.

b. System board components are initialized.

c. UEFI drivers are discovered and loaded.

ProLiant functions are initialized, including:

a. Power Regulator

b. Smart Array

c. Smart Memory

d. Intelligent Provisioning

e. Sea of Sensors 3D

f. RESTful API

g. HPE iLO 4 management

Technical white paper Page 7

2. Once the POST functions are complete, the POST display appears as shown below:

Figure 3. POST display

Note Depending on your ProLiant Gen9 platform, not all UEFI System Configuration options may appear in the menu. Example above also shows error message capabilities.

As shown above, the POST screen displays the status/presence of ProLiant features and functions, giving you to access the following services:

a. System Utilities (F9), for accessing such functions as:

I. System configuration, for accessing the BIOS/Platform Configuration (RBSU) or iLO Configuration Utility

II. One-Time Boot Menu, for accessing the Boot Manager, UEFI Shell, or another UEFI application

III. Embedded Applications, for running custom utilities

IV. System information, for accessing system details such as name, processor type, memory amount, BIOS version

V. Device Health Status, for obtaining status of iLO, drive controller, and drive array

b. Intelligent Provisioning (F10), for reliable, consistent deployment of server configurations

c. Boot Menu (F11), for changing the boot order list

d. Network Boot (F12), for setting embedded NIC or PXE boot policies

3. Pressing a function key results in immediate visual feedback—a highlighted key indicator on the screen. If no user intervention is detected during the several seconds, the POST screen is displayed, UEFI continues the boot process, searches for a boot device and, once detected, boots from that device and loads the operating system.

UEFI runtime services are available after the operating system is loaded.

References • UEFI System Utilities User Guide for HPE ProLiant Gen9 Servers

Technical white paper Page 8

Secure Boot UEFI Secure Boot ensures that only firmware components, UEFI applications, and operating system bootloaders that have appropriate digital signatures and verified as authentic can execute during the boot process. UEFI Secure Boot is an improvement over the Trusted Computing Group (TCG) Measured Boot process used by legacy BIOS systems. In the TCG Measured Boot process, each component in the execution chain measures executing code and compares the value with the preceding component. Measured Boot offers a method to detect modified (i.e., malicious) code, but does not necessarily prevent execution of such code and requires a Trusted Platform Module (TPM) chip.

UEFI Secure Boot has each component in the processing chain validate and authorize code against a given policy before allowing it to execute. Secure Boot can use policies that include digital signatures, preloaded hash values, or both—and does not depend on TPM-type hardware.

The standard UEFI Specification 2.3.1 defines the Secure Boot process as offering the following functions:

• All UEFI drivers, OS bootloaders, and UEFI applications are digitally signed

• Binaries are verified using a set of embedded trusted keys

• Only validated and authorized components are executed

ProLiant Gen9 servers significantly enhance the standard UEFI Secure Boot process with additional functions (Figure 4) including:

• Secure firmware update:

– iLO validates of signatures of digitally-signed firmware images before flashing

– With ROM behind the iLO, only iLO can flash the part

• Tamper-resistant secure NVRAM storage:

– Isolated from firmware part

– Protected by iLO and Complex Programmable Logic Device (CPLD)

– Cannot be written from host except in System Management Mode with unlock password

• Secure Boot management (pre-boot UI and RESTful API):

– Requires physical admin presence (or virtual presence through iLO)

– Allows enabling or disabling Secure Boot

– Views, deletes, or resets all keys

– Enrolls or deletes certificate or hash

Technical white paper Page 9

Figure 4. UEFI Secure Boot in ProLiant Gen9 Servers

Secure Boot is available on systems running Windows Server 2012 R2 and Windows Server 2012, as well as recent versions of Linux (SUSE Linux Enterprise Server 11 SP3 and Ubuntu 12.04 and 14.04 and Red Hat® Enterprise Linux 7).

PXE boot The PXE boot specification defines how clients can boot from network software (instead of using a local operating system) using a standard network protocol such as DHCP or TFTP. Compared to legacy BIOS, UEFI can work with more advanced pre-boot user interfaces and can operate over both IPv4 and IPv6 networks.

PXE multicast boot combines unicasting and broadcasting in group communication using one-to-many or many-to-many distribution. Unlike legacy BIOS, UEFI can enable PXE multicast mode on the client side. The PXE stack on UEFI-based systems “listens” on multicast addresses and enables servers to install multiple PXE booting clients as part of a multicast group, saving both time and bandwidth and reducing server load.

PXE boot can occur from a Linux-based or Windows-based server (Figure 5).

Figure 5. UEFI PXE boot

Technical white paper Page 10

Linux-based PXE boot considerations For a Linux environment, the GUID Partition Table (GPT) must be enabled. This is done by turning on the CONFIG_EFI_PARTITION during kernel configuration. When booting Linux from GPT disks, the creation of an EFI System Partition (ESP) is required. ESP contains UEFI applications like the bootloaders, OS kernels, and utility software.

Bootloaders vary in functionality, so you should ensure that the UEFI features you want are supported by the bootloader being distributed. On a Linux-based PXE server, one of these bootloaders can be distributed:

• ELILO—EFI Linux bootloader that can only be used for UEFI systems.

• GRUB2—A bootloader that works with both UEFI and Legacy BIOS, and the only bootloader that currently supports Secure Boot.

Windows-based PXE boot considerations For a Windows-based PXE server, the boot image to be distributed must match the architecture of the client (x86 or x64). Prior to distribution, you can customize the boot image as to image properties, drivers, prestart command settings, command shell support, and optional components to use in Windows PE.

After the boot image is prepared, it can be distributed to all PXE-enabled distribution points (using the same method you use for distributing other content). Configuration Manager allows you to specify single distribution points, distribution point groups, or collections that are associated with distribution point groups. When the task sequence is run by a client, the client downloads the boot image from the distribution point.

References • UEFI Deployment Guide for HPE ProLiant Gen9 Servers

Boot from URL The enhanced UEFI of all ProLiant Gen9 Servers offers the ability to boot the system from a file at an http or ftp site using a specified URL. Booting from a URL eliminates the need for using physical or virtual media on a bare metal system.

As shown in Figure 6, you can configure the network settings for the URL one of three ways: a) through the System Utilities BIOS/Platform Configuration (RBSU), b) with the sysconfig command in the embedded UEFI Shell, or c) by using the RESTful API. You specify the URL as DHCP or static IP, and the file can be either a UEFI Network Boot Program (NBP) or an ISO image containing a UEFI bootable OS image. The boot from ISO support is currently limited to operating systems that have a self-contained OS image (such as WinPE, mini Linux, or VMware® ESX® installer). Booting Windows or Linux OS installation media is currently not supported.

Figure 6. Configuring for booting from a URL (example uses DHCP for specifying the location to a boot file)

Technical white paper Page 11

UEFI Shell-based deployment ProLiant Gen9 servers feature an embedded UEFI Shell, which is a command line interface (CLI) application that allows scripting, file manipulation, obtaining system information, or running other UEFI applications. The UEFI Shell includes a programming API you can use to create your own UEFI applications. Similar in functionality to the DOS prompt on legacy BIOS-based systems, the UEFI Shell provides such commands as md, cd, edit, cp/copy, del, and dir, but can be accessed as a boot option before the operating system is loaded.

The embedded UEFI Shell in ProLiant Gen9 Servers has been enhanced to perform deployment tasks such as firmware updates and OS installations. Using the same configuration procedures described previously for “Boot from URL,” you can configure the UEFI Shell to retrieve a Startup script from a particular location. After configuration and re-boot, the system will, as shown in Figure 7, 1) launch the UEFI Shell, 2) download the startup script from the specified HTTP or FTP server, and 3) run the Startup script, which can download any additional files specified for provisioning, place them into RAM disks, and invoke as appropriate.

Figure 7. UEFI Shell-based deployment

References • UEFI Shell User Guide for HPE ProLiant Gen9 Servers

• UEFI Shell Quick Reference Card for HPE ProLiant Gen9 Servers

• UEFI Deployment Guide for HPE ProLiant Gen9 Servers

UEFI considerations Adapting UEFI to an enterprise data center involves decisions based on your environment, particularly for existing IT infrastructures. The following sections describe areas of concern when choosing whether you should or can implement UEFI.

Functionality requiring UEFI The following elements and situations require implementing UEFI:

• Boot drives >2 TB

• Secure Boot

• IPv6 PXE boot

• PXE multicast boot

• UEFI Shell for running UEFI tools

• Option cards that work only with UEFI

• Boot from URL (http or FTP)

Technical white paper Page 12

• UEFI Shell-based deployment

• Booting NVMe drives

• Windows Server 2012 UEFI-only functionality

Upgrading existing resources Existing systems designed to run legacy BIOS firmware cannot be upgraded or modified to work with UEFI. Also note that upgrading the OS on such systems to UEFI versions will not gain you UEFI functionality or benefits. A system’s hardware and firmware must be designed to work with UEFI. Due to the forward-only nature of UEFI adoption, you need to decide if future system acquisitions should be UEFI-based.

OS installation For new hardware acquisitions that can run in either Legacy BIOS mode or UEFI mode, you must decide whether to install platforms in a legacy BIOS or UEFI mode. An OS installed for one mode cannot be converted to another.

The following operating systems can run in UEFI Mode on ProLiant Gen9 servers:

• Microsoft Windows Server 2008 R2

• Microsoft Windows Server 2012

• Microsoft Windows Server 2012 R2

• Microsoft Windows 10

• VMware ESXi 5.1 U2 and later

• VMware ESXi 5.5 U2 and later

• VMware ESXi 6.0 (VMware vSphere 2015)

• Red Hat Enterprise Linux 6.x

• Red Hat Enterprise Linux 7.x

• SUSE Linux Enterprise Server 11 SP4

• Ubuntu 14.04

• SUSE Linux Enterprise Server 12.x

Boot considerations The UEFI boot process offers more flexibility but requires familiarity by IT personnel. Moving to UEFI requires the following boot considerations:

• An OS will install in the mode (UEFI or Legacy BIOS) the platform is configured.

• USB keys and DVDs designed to boot only on legacy BIOS systems will not boot on UEFI systems. Boot devices must include the UEFI boot catalogue (or be dual-boot) for booting on a UEFI system.

• PXE servers must be set up for UEFI and existing scripts may require modification.

• A server configured in Legacy BIOS mode cannot boot an OS installed in UEFI mode.

• A server configured for UEFI mode cannot boot an OS installed in Legacy BIOS mode.

• If UEFI Secure Boot is enabled, UEFI drivers (option ROMs), OS bootloaders, and (in some cases) OS drivers must be signed.

• UEFI Boot Mode includes an option for UEFI Optimized Boot Mode that is enabled by default.

Technical white paper Page 13

Note UEFI Optimized Boot Mode must be disabled for Windows Server 2008 and Windows Server 2008 R2 as these OSs require legacy BIOS VGA components even when booting in UEFI mode. UEFI Optimized Boot Mode must be enabled, however, for booting VMware ESXi.

UEFI variables Unlike Legacy BIOS variables, which are stored in battery-backed CMOS memory, UEFI variables (such as boot configuration data and security keys) are stored in NVRAM (flash memory), resulting in the following important considerations:

• Restoring system defaults and erasing UEFI variables are two separate operations.

• If the system board is replaced, UEFI variables can be lost. However, some OSs (such as Windows 2012 and RHEL 7) cache the UEFI boot variables on the hard drive so that they can be restored.

• Default time zone is Coordinated Universal Time (UTC), and is not modified when system defaults are restored.

Conclusion Our leadership role in the UEFI forum and close association with UEFI development allows us to develop solutions that offer advanced UEFI functionality. The advanced UEFI functionality we have integrated into ProLiant Gen9 servers provides a highly manageable and easily provisioned system.

Resources, contacts, or additional links QR code access to support pages All ProLiant Gen9 servers provide QR codes on the chassis and in the UEFI graphic user interface (GUI) to provide access to mobile-friendly resources. The QR code on the chassis will direct users to the hpe.com/qref/servers landing page while the QR code in the GUI will display online help.

HPE information sources UEFI information hpe.com/servers/uefi

UEFI information library hpe.com/info/uefi/docs

ProLiant technical white papers hpe.com/servers/technology

UEFI documentation from Hewlett Packard Enterprise Important UEFI Requirements (for HPE ProLiant Gen9 Servers) hpe.com/support/gen9uefi

UEFI System Utilities User Guide for HPE ProLiant Gen9 Servers hpe.com/support/uefigen9_ug_en

UEFI Shell User Guide for HPE ProLiant Gen9 Servers hpe.com/support/uefigen9_sg_en

UEFI.org information sources UEFI Secure Boot in Modern Security Systems, published by UEFI.org

UEFI Learning Center at UEFI.org: uefi.org/learning_center

Technical white paper

Sign up for updates

© Copyright 2014–2016 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.

Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. VMware ESX and VMware ESXi are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. All other third-party trademark(s) is/are property of their respective owner(s).

4AA5-1111ENW, October 2016, Rev. 2

Operating system sources Microsoft Windows information on UEFI

UEFI Support in the Linux Kernel

openSUSE information on UEFI

Ubuntu information on UEFI

Learn more at hpe.com/servers/uefi