Harnessing the UEFI Shell

Michael Rothman, Vincent Zimmer, Tim Lewis

• Verlag: De|G Press
• Jahr: 2017
• ISBN:
  9781501505812
• Auflage: 1
• Thema: Informatique
• Thema: Matériel

Focusing on the use of the UEFI Shell and its recently released formal specification, this book unlocks a wide range of usage models which can help people best utilize the shell solutions. This text also expands on the obvious intended utilization of the shell and explains how it can be used in various areas such as security, networking, configuration, and other anticipated uses such as manufacturing, diagnostics, etc. Among other topics, Harnessing the UEFI Shell demonstrates how to write Shell scripts, how to write a Shell application, how to use provisioning options and more. Since the Shell is also a UEFI component, the book will make clear how the two things interoperate and how both Shell developers as well as UEFI developers can dip into the other's field to further expand the power of their solutions.

Harnessing the UEFI Shell is authored by the three chairs of the UEFI working sub-teams, Michael Rothman (Intel, chair of the UEFI Configuration and UEFI Shell sub-teams), Vincent Zimmer (Intel, chair of the UEFI networking sub-team and security sub-team), and Tim Lewis (Insyde Software, chair of the UEFI security sub-team). This book is perfect for any OEMs that ship UEFI-based solutions (which is all of the MNCs such as IBM, Dell, HP, Apple, etc.), software developers who are focused on delivering solutions targeted to manufacturing, diagnostics, hobbyists, or stand-alone kiosk environments.

Chapter 1
Introduction

Less but better.

—Dieter Rams

To most users, a computer is represented by the operating system that they’re using and nothing more. However, unbeknownst to most basic users, there are a large number of components that must work in concert to go from where the user presses the power button, the hardware is initialized, the boot target is discovered, to where the operating system is launched.

There are two major phases of platform initialization between when a user turns a computer on and the computer has completed its initialization: the first phase is what might be called the “pre-OS” stage where the platform’s hardware is initialized and made usable, and the second phase is when the boot target is launched, which oftentimes would be the target operating system.

The early phase of platform initialization is primarily focused on the launching of a target. This target almost always is an operating system, but it doesn’t always have to be. Sometimes, activities such as bare-metal provisioning, diagnostics, personality migration, scripting and others are accomplished through an intermediary execution environment known as a UEFI shell.

Much of this book will further explain the intricacies of how one uses the UEFI shell to accomplish the aforementioned activities, but this being an introductory chapter, it seems reasonable to give a slight background on what the UEFI shell actually is and from where its roots evolved.

What is UEFI?

Historically, the BIOS (Basic Input Output System) was a black box. In other words, there was very limited exposure to how it worked and the interoperability associated with the BIOS and the rest of the system was limited at best.

The purpose of a BIOS was very simple: its role was to discover and initialize the hardware, run any tests that were required to ensure the hardware was in working order, and ultimately launch the boot target.

The goals for today’s BIOS have not significantly changed. What has changed is that the “black box” nature of BIOS has been opened so that the industry can normalize the interfaces associated with BIOS technology and leverage it in many ways that were previously not possible.

In 2005, the UEFI (Unified Extensible Firmware Interface) Forum was established. The forum itself was formed with several thoughts in mind:

The UEFI Forum is established as a Washington non-profit Corporation

–Develops, promotes, and manages evolution of the UEFI Specification

–Continue to drive low barriers for adoption

The Promoter members for the UEFI forum are:

–AMD, AMI, Apple, Dell, HP, IBM, Insyde, Intel, Lenovo, Microsoft, Phoenix

The UEFI Forum has a form of tiered Membership:

–Promoters, Contributors, and Adopters

–More information on the membership tiers can be found at: www.uefi.org

The UEFI Forum has several work groups:

–Figure 1.1 illustrates the basic makeup of the forum and the corresponding roles.

Figure 1.1: Forum group hierarchy

Sub-teams are created in the main owning workgroup when a topic of sufficient depth requires a lot of discussion with interested parties or experts in a particular domain. These teams are collaborations among many companies who are responsible for addressing the topic in question and bringing back to the workgroup either a response or material for purposes of inclusion in the main working specification. Some examples of sub-teams that have been created are as follows:

–UCST – UEFI Configuration Sub-team

• Chaired by Michael Rothman
• Responsible for all configuration-related material and the team has been responsible for the creation of the UEFI configuration infrastructure commonly known as HII, which is in the UEFI Specification.

–UNST – UEFI Networking Sub-team

• Chaired by Vincent Zimmer
• Responsible for all network-related material and the team has been responsible for the update/ inclusion of the network-related material in the UEFI specification, most notably the IPv6 network infrastructure.

–USHT – UEFI Shell Sub-team

• Chaired by Michael Rothman
• Responsible for all command shell-related material. The team has been responsible for the creation of the UEFI Shell specification and continues to maintain the contents as technology evolves.

–USST – UEFI Security Sub-team

• Chaired by Vincent Zimmer
• Responsible for all security-related material and the team has been responsible for the added security infrastructure in the UEFI specification.

With the UEFI Specification, we now have programmatic interfaces to features and functionality that we never had before in previous generations. This allows third parties to create UEFI-compatible software that can run on platforms which are UEFI-compliant.

In Figure 1.2, we see a very high level illustration of the general software flow during platform initialization.

The normal process would be to launch the operating system loader, which is a UEFI-compliant item, and it in turn will initialize the operating system.

However, there are cases where the user or system administrator would choose to launch other components such as a UEFI Shell. This of course leads to a natural question, “What is a shell?”

Figure 1.2: High-Level Platform Initialization Flow

What Do We Mean by Shell?

At its most basic, a shell is a way of exposing an interface to a user. This can be a graphics interface such as one that leverages icons, mouse clicks, and animation, or a more rudimentary interface such as a CLI (Command-Line Interface), which requires a user to type commands to a command processor for it to respond.

It should be pointed out that from a programmatic point of view, a shell also provides interfaces from which an application can interact with the underlying programmatic abstractions (interfaces).

This book will cover a wide variety of the underlying APIs (both programmatic and script-based) as well as functional capabilities. For reference, there are two very pertinent specifications that come out of the UEFI forum (www.uefi.org).

–UEFI specification: The specification that covers a wide variety of programmatic interfaces, many of which are associated with interacting with a platform’s hardware and other platform policy. This is the specification that forms the basis of what is known as “UEFI compatibility.”

–Shell specification: The specification that also describes programmatic interfaces that are exposed by a UEFI Shell compatible environment. In addition to the typical programmatic interfaces, the specification also describes a large series of commands that form the basis of the UEFI Shell’s scripting language.

A Short History of the UEFI Shell

The UEFI Shell had very humble beginnings. Its roots lie with the birth of the PC and the advent of CPM/ DOS.

For those who can recall the predominant operating system of the 1980’s, it was part and parcel of the original IBM PC and was very much ubiquitous for users of computers in that era. The command-line interface and many of the commands that are very familiar to users (e.g., copy, delete, echo) owe their origins to the days of DOS (Disk Operating System).

In those days, DOS was the boot target. The expectations of the user were a bit more humble than they are today, and to give a relative comparison of the complexity between now and then, bear in mind that the first DOS with all of its utilities and kernel fit within 150K worth of code, while most modern operating systems may have an on-disk size of one gigabyte or more.

The main goal of DOS was to be able to launch applications, utilities, and execute scripts.

DOS exposed limited standardized APIs to access the underlying platform, so the complexity associated with what one could do through the command-line interface was also fairly limited. However, with the advent of UEFI and the myriad interfaces that it exposed, the possibilities became fairly broad. For instance, within UEFI we have provided abstractions to access networking devices, graphical components, storage devices, and a multitude of other things. The possibilities of what a third-party application or script can do is much broader than was ever possible in the earliest of operating systems.

It should be noted that in many UEFI-compliant platforms, the UEFI shell and its underlying abstractions are all contained on the platform’s embedded non-volatile storage (e.g., FLASH device) and can execute even without a boot media target. This is something that the platforms of old did not provide. On a UEFI-compliant system, you could potentially have a rather robust environment of a complete network stack, UEFI shell, and a modern programming environment with memory managers and a driver model. This powerful environment now allows for some of what will be described in...