UEFI, successor to legacy BIOS

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
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
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