MESSAGE
| DATE | 2014-11-18 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] UEFI and Secure Boot
|
From owner-hangout-outgoing-at-mrbrklyn.com Tue Nov 18 15:23:39 2014
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id E3F68161143; Tue, 18 Nov 2014 15:23:38 -0500 (EST)
Delivered-To: hangout-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id BBB0416115D; Tue, 18 Nov 2014 15:23:38 -0500 (EST)
Delivered-To: hangout-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id A6F61161143
for ; Tue, 18 Nov 2014 15:23:37 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id 7140C13D30
for ; Tue, 18 Nov 2014 15:23:36 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 37B1833C79; Tue, 18 Nov 2014 15:23:36 -0500 (EST)
Date: Tue, 18 Nov 2014 15:23:35 -0500
From: Ruben Safir
To: hangout-at-nylxs.com
Subject: [NYLXS - HANGOUT] UEFI and Secure Boot
Message-ID: <20141118202334.GA15311-at-panix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: owner-hangout-at-mrbrklyn.com
Precedence: bulk
Reply-To: hangout-at-mrbrklyn.com
--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
This is the finished report, version 1.0, although I expect to improve
on the paper in the future. Included is also the presentation slides.
I will be presenting this at LIU/Brooklyn tonight, but I will give
another off campus presentation in the immediate future, and hopefully
extend it to more than 10 minutes, which is my current time limit.
http://www.nylxs.com/docs/grad_school/uefi/page1.html
slides
http://www.nylxs.com/docs/grad_school/arch/uefi_pages.txt
paper
--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=unknown-8bit
Content-Disposition: attachment; filename="uefi.txt"
Content-Transfer-Encoding: 8bit
IBM/PC/Intel Based computers, like all other computing systems, need to
boot when they are powered on. The computer's various parts and in and
out devices need to be defined in order to allow access to resources.
In order to facilitate booting, PC based systems have a variety of ROM
like storage systems to read the program that begins the booting process.
When a computer starts, it has no knowledge of itself. It is a blank
slate. All the information that the system needs to know about itself,
in order to process user programs and to do useful tasks, requires
an increasingly complex task of making resources available and known.
In order to do this, systems are hard wired to look for the starting
instructions at fixed locations on the system. These locations
are specific for different hardware types. For example on Intel x86
processors, memory location FFFF:0000 is always the first instruction that
the CPU is begin executing with. Other systems have different locations,
and even different addressing schemes.
Intel x86 based system include ROM based firmware called a BIOS.
The BIOS (Basic Input/Ouptput System), has exacting specifications.
Although they can vary, for a specific x86 type of architecture, they can
only vary within the confines of the specification. A BIOS relies on the
x86 architecture’s 16-bit real mode which is a long was of saying that
it works in the environment of a 16 bit CPU of the x86 type. Since all
the intel chips have been backwardly compatible to this standard, up
until now, BIOS, and CMOS software that accesses the BIOS has been at
the core of system start ups for intel based hardware for a generation.
Over time, there has been increasing demands on hardware booting.
Even early in the history of the PC, there was a need to use PCs as thin
clients and for network booting. This required that network cards, and
networking protocols to be active prior to the booting and
implementation of the operating system. There was the creation of the
BOOTP and TFTP (trivial FTP) and a slowly a whole alphabet soup of
acronyms have been introduced into the lingo of booting system.
In addition to this, more than one operating system are now installed on
system, and hard drive capacities have grown further that the 16 BIOS
addressing scheme can read. Hard Drives have had master boot records,
but over time, booting information has moved off the master boot record
and onto various partitions. Additionally, modern Free Software and
proprietary systems can run on a variety of hardware outside of the
world of the x86 architecture.
Bios and CMOS can now also be flashed, to be updated and allow for more
flexible configurations. Tablets, micro-tables(phones), and new laptop
designs with touch screen are standard input devices have become
population. All this has put pressure to redesign the booting system
for commodity hardware.
"In the end, the BIOS is still here and still does what it has been doing
for the last 25 years: making sure your operating system can boot. It
was never designed for today’s massive diversity of hardware. It’s
still stuck with 16-bit interfaces and software interrupts, interrupt
routing and maximum precision timers, limited ROM execution space (1
MB) and image size, a limited number of initializeable devices (which
is critical in the server space), proprietary extensions, and missing
modularity—just to name a few issues." [1]
This has been a blessing and a curse. Efforts to remove the BIOS
functionality have always been targeted to take away the flexibility of
run anything, clean and simple interface. IBM's MicroChannel
architecture is but one an example. Intel finally took the bull by the
horns with the introduction of the Itanium’s IA64 architecture (along
with HP) in 2003. This was a PC like server architecture that needed
around some of the BIOS limitations. The created the EFI standards
(adding more acronyms to the soup), and handed off its future to the
industrial consortium called Unified Extensible Firmware Interface Forum
which is an acronym for AMD, Insyde Software, American Megatrends, Inc..
Intel, Apple Inc, Lenovo, Dell, Microsoft, Hewlett Packard,
Phoenix Technologies and IBM. There is a SINGLE non-profit engineering
or standards group represented on UEFI forum. The result is some very
useful specifications a washed in some game changing lock down mechanism
designed to do what IBM could never accomplish with microchannel.
UEFI, in fact, is nearly an operating system sitting between your
firmware and your operating system. "It not only offers driver support,
interfaces, and services, but it also has a shell that allows users to
execute applications on a command line interface." [1]
The generalized process of UEFI booting is as follows:
1- UEFI Firmware: Performs CPU and Chipset initialization and loads
drivers
2- UEFI Boot Manager - Loads device drivers and the boot application
3- Loads the OS boot manager selected by the user
4- Loads the OS
5- Runs the OS Kernel
EFI (the Intel Child of UEFI) has tables and offers run level services
to the operatings. This is similar to the runtime services that
unix-like operating systems have had for decades. Boot Services include
file services, text and graphic user consoles, and the run services can
offer access to Non-volatile random-access memory (NVRAM), date and
time, etc. EFI drivers have specific communication protocols that all
components can use. The EFI device driver environment s a virtual
drive, like what Java uses, called the EBC, which provides a CPU
independent development target for UEFI module development.
Overall Boot Time line
Part 1:
Power On
Secure Boot
Pre EFI Initialization (PEI)
PIE Core
CPU Init
Chipset Init
Board Iniit
EFI Driver Dispatcher
Architecture Protocols
Driver Execution Environment
Device, Bus and Service Driver
Utilization of the EFI Driver Dispatcher
Boot Device Selection
Boot Manager
Transition System Load
OS Absent Application
UEFI Shell
Transient OS Boot Loader
Final OS Boot Loader
Run Time
OS environment
applications
The complete specification for UEFI is now 2098 pages of text available from
the UEFI forum, and as such, is far more detailed than the limits of
this paper. It's complete current source is at
http://www.uefi.org/sites/default/files/resources/2_4_Errata_B.pdf .
The transformation from CMOS/BIOS is significant and deserves some
understanding and attention.
UEFI is an embrace and extend technology for the system bios. It does
not eliminate fundamental firmware, but masks some of the complexity
for developers and computer users. It also provides for a locked down
mechanism for purchased systems such that their operating systems can not
be removed or altered. It therefor provides a key objective of
operating system vendors and computer system manufactures such that
previously has been denied them by the open standards of BIOS and CMOS.
Upon powering up the system, BIOS bases systems have a very specific
agenda of items that they must perform in order to be compliant with the
specifications. With a BIOS the x86 CPU resets and loads a PC at the top
of the one megabyte real mode address space which is where the BIOS
program is resident. Then a jump instruction is set to move the PC to
an earlier location where the BIOS is run. The system can be reset from
a cold boot or a warm boot. Flags determine which process to follow.
On a cold boot, the bios runs a "post". On a warm boot it does not.
Post identifies the systems parts and the CPU, RAM, interrupt and DMA
controllers and other parts of the chipset, video display card, keyboard,
hard disk drive, optical disc drive and other basic hardware. After
posting, optional ROMs are searched for which extend functionality.
These ROMs exist in upper memory, and the BIOS scans memory from
0x0C0000 to 0x0F0000 on the 2 KiB boundary. ROMs have a memory boundary
of 0x55 0xAA followed by a byte that describes the number of 512 byte
blocks that the expansion ROM sits at in real memory. A checksum is of
the 512 byte block that is calculated and if valid, the execute jumps to
the optional ROM which now controls the system. ROMS normally return
back to the BIOS which scans for the next ROM until the entire sector of
memory is scanned.
Finished with all this, the BIOS now calls INT 19h. INT 19H is a software
interrupt that puts address 0019H onto the address bus and starts executing
code found there. 0019H is normally a jump instruction. Usually this loads
data from Head 0, Track 0 of Sector 1 of a disk. This would be the Master
Boot Record (MBR). Information received by the Post determines which disks
are attempted to locate a bootstrap loader, installing it into memory
location 0x0000:0x7C00. The bloatstrap loader reads in the partition
table and the operating system. [2]
The bios is a dumb device that does not process instructions from the
boot sector. This is left to the bootstrap program. What is most
important to understand is that the entire BIOS specification is very
specific with exact definitions of interrupts, memory mappings, from
interrupt definitions, hard drive specification and a plethora of exact
locations and limitations in order to get from power of to OS running.
Much of this detail was created because the x86 specification was
designed for the purpose of emulating the specific IMB/PC XT product and
architecture. The new UEFI specification buries much of this
specification and leaves the implementation specifics to individual
firmware companies. Under the hood, one motherboard under UEFI might
use an entirely unique set of addressing schemes and interrupts then
another, as long as BOTH end up showing an interface that complies with
the UEFI specification.
"While BIOS is fundamentally a solid piece of firmware, UEFI is a
programmable software interface that sits on top a computer’s hardware
and firmware (and indeed UEFI can and does sit on top of BIOS). Rather
than all of the boot code being stored in the motherboard’s BIOS, UEFI
sits in the/EFI/ directory in some non-volatile memory; either in NAND
on the motherboard, on your hard drive, or on a network share (more on
that later)." [3]
Bootloaders have been constrained to fit in 446 bits of the master boot
record and run in 32k of system memory. These are called first stage
boot loaders and the partition tables are in a default 64 byte partition
table with four primary partitions, in its most generic form.
Boatloaders most often load secondary boot loaders that are more
flexible, such and GRUB. These loaders allow for multiple operating
system installation or to load operating systems in different states.
They read partition tables and load systems accordingly.
UEFI takes a different approach. As one tech blogger wrote, "Now let’s
look at how booting works on a UEFI system. Even if you don’t grasp the
details of this post, grasp this: it is completely different. Completely
and utterly different from how BIOS booting works. You cannot apply any
of your understanding of BIOS booting to native UEFI booting. You cannot
make a little tweak to a system designed for the world of BIOS booting
and apply it to native UEFI booting. You need to understand that it is a
completely different world." [4] I think this is overstated. Eventually
every computer system has to do exactly what a BIOS based system does.
It has to reach into the architecture of a computer, identify some
subset of its working parts, and bootstrap a fully functional operating
system into its memory while running the operating systems viable
instruction set. UEFI is an attempt to hide much of this hardware
complexity and substitute it with software complexity that looks
simpler. There are inherent problems with this approach, the first
being is the scale of the introduced complexity. Let's review some of
this introduced complexity.
One of the first changes to the booting process involved the change from
the MBR standard to what is no known as GPART or GPT standard. There
was an essential problem to the original BIOS specification that was
simply outgrown over time, namely the limitation of the size of
partitions that could be read from hard drives. The Master Boot Record,
is that special sector at the very beginning of a fixed disk that
describes the partition table of the disk and contains the primary boot
loader. The MBR is limited to 32 bits for addressing partitions and with
a sector size set at 512 bytes, hard drive addressing is limited to a shade
over 2 terabytes in size. In order address partitions greater than 2
terabytes, another scheme was needed. That scheme came the way of the
GUID Patition Table,
(GPT).
This is the layout for a modern Master Boot Record:
________________________________________________________________________
ADDRESS Description Size in Bytes
Hex Dec
________________________________________________________________________
+000h +0 Bootstrap code area (part 1) 218
+0DAh +218 0000h Disk timestamp[4][b]
(optional, MS-DOS 7.1-8.0
(Windows 95B/98/98SE/ME),
alternatively can serve as OEM
loader signature with NEWLDR) 2
+0DCh +220 original physical drive (80h-FFh) 1
+0DDh +221 seconds (0-59) 1
+0DEh +222 minutes (0-59) 1
+0DFh +223 hours (0-23) 1
+0E0h +224 Bootstrap code area (part 2, code
entry at +000h) 216 (or 222)
+1B8h +440 32-bit disk signature
Disk signature (optional, UEFI,
Windows NT/2000/Vista/7 and other
OSes) 4
+1BCh +444 0000h
(5A5Ah if copy-protected) 2
+1BEh +446 Partition entry #1
Partition table
(for primary partitions) 16
+1CEh +462 Partition entry #2 16
+1DEh +478 Partition entry #3 16
+1EEh +494 Partition entry #4 16
+1FEh +510 55h Boot signature[a] 2
+1FFh +511 AAh
________________________________________________________________________
Total size: 218 + 6 + 216 + 6 + 4×16 + 2 512 (from WIKIPEDIA)
GUID Partition Tables, which are now a key component of the UEFI
specification, feature divisions of memory through the modern LBA
placement and memory scheme. Previously, hard drive locations were
identified by the (Cylinder, Head, Sector) tuples, which identified a
location through the raw location of the hard drive. As drives changes
and new media emerged, CHS was replaced by LBA (Logical Block
Addressing).[5] The protective MBR would be in LBA0. The GPT header is
in LBA1 which has a pointer to the Partition Table or a Partition Entry
Array. [6] The Partition Array, by UEFI standards must have a minimum
16,384 bytes which allows for addressing space to 18 Exabyte with up to
128 partitions. The GPT has a partition header that defines the tables
characteristics. It lives always in LBA1. GUID is a system for uniquely
identifying computing components as defined in the UUID Standard. It is
32 Hex couples, 128 bit values.
The UEFI standard includes a native executable tongue called the EFI Byte
Code (EBC if you are keeping track). This is a 'virtual' machine in which
the firmware can be written to and for which implementation will happen
on any hardware architecture, regardless of the CPU. In C programming,
it requires the use of efi and efilib headers and a complex linkage to
cross compile to the efi binary code. A GNU-EFI package exists and
a sample program for a native EFI firmware binary is demonstrated by
Roderick W. Smith at http://www.rodsbooks.com/efi-programming/hello.html.
His sample program includes as follows:
#include
#include
EFI_STATUS
EFIAPI
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) {
InitializeLib(ImageHandle, SystemTable);
Print(L"Hello, world!\n");
return EFI_SUCCESS;
}
Notice how main is replaces with efi_main
The compilation would require a cross platform compile to EFI native
binary and a complex makefile is provided by Mr Smith as follow:
________________________________________________________________________
ARCH = $(shell uname -m | sed s,i[3456789]86,ia32,)
OBJS = main.o
TARGET = hello.efi
EFIINC = /usr/include/efi
EFIINCS = -I$(EFIINC) -I$(EFIINC)/$(ARCH) -I$(EFIINC)/protocol
LIB = /usr/lib64
EFILIB = /usr/lib64/gnuefi
EFI_CRT_OBJS = $(EFILIB)/crt0-efi-$(ARCH).o
EFI_LDS = $(EFILIB)/elf_$(ARCH)_efi.lds
CFLAGS = $(EFIINCS) -fno-stack-protector -fpic \
-fshort-wchar -mno-red-zone -Wall
ifeq ($(ARCH),x86_64)
CFLAGS += -DEFI_FUNCTION_WRAPPER
endif
LDFLAGS = -nostdlib -znocombreloc -T $(EFI_LDS) -shared \
-Bsymbolic -L $(EFILIB) -L $(LIB) $(EFI_CRT_OBJS)
all: $(TARGET)
hello.so: $(OBJS)
ld $(LDFLAGS) $(OBJS) -o $-at- -lefi -lgnuefi
%.efi: %.so
objcopy -j .text -j .sdata -j .data -j .dynamic \
-j .dynsym -j .rel -j .rela -j .reloc \
--target=efi-app-$(ARCH) $^ $-at-
Note that Makefiles are tab sensitive so you will need to assure the
format of this file accordingly.[7]
The UEFI standard includes the possible use of a shell. With the use of
this shell, you can run arbitrary code. This is the Preboot environment
of UEFI. In fact, Smith makes clear that this preboot environment can
be useful for application development in several areas, reinforcing the
idea that UEFI is very much operating system like in it's specification.
Wolfgang-Rosenbergsr, from Intel, has extensively documented a UEFI
Shell and the EFI OpenShell available from http:www.tianocore.org.
Among the items that the UEFI shell allows for is the execution of preboot
programs, setup, operating system installation, testing of hardware and
software, disk utilities, driver diagnostics, configuration
modifications, moving files around and between the hard disk, floppy disk,
CD-ROM, USB flash devices, and so on, to load a preboot EFI driver in the
system (has an .efi suffix) such as network stacks, tcpip drivers,
to, update old drivers in flash memory, load new drivers for plugin
cards, and more.[8] This shell has two versions, Shell.efi and
Shell_full.efi. Shell.efi fits on most current flash memories.
efi binary files start with the symbol efi_main that has two parameters,
EFI_HANDLE ImageHandle and EFI_SYSTEM_TABLE *SystemTable. The
system table is a C-style structure with the following entries:
typedef struct _EFI_SYSTEM_TABLE {
EFI_TABLE_HEADER Hdr;
CHAR16 *FirmwareVendor;
UINT32 FirmwareRevision;
EFI_HANDLE ConsoleInHandle;
SIMPLE_INPUT_INTERFACE *ConIn;
EFI_HANDLE ConsoleOutHandle;
SIMPLE_TEXT_OUTPUT_INTERFACE *ConOut;
EFI_HANDLE StandardErrorHandle;
SIMPLE_TEXT_OUTPUT_INTERFACE *StdErr;
EFI_RUNTIME_SERVICES *RuntimeServices;
EFI_BOOT_SERVICES *BootServices;
UINTN NumberOfTableEntries;
EFI_CONFIGURATION_TABLE *ConfigurationTable;
} EFI_SYSTEM_TABLE;
These listed handles, likewise have application interfaces that directly
tie to firmware defined modules. For example, one can call
ConOut->OutputString() to print to the console. Firmware is required to
make available a set of binary compatible libraries for extensive
program building. EFI_RUNTIME_SERVICES accesses a firmware services
which are available in the preboot environment and when the Operating
System takes control of the system. These services include system clock
functions, NVRAM variables, and system reset operations. This is unlike
EFI_BOOT_SERVIES which are only available during the preboot phase. 7
In order to accommodate all this complex preboot operating system, UEFI
specifies that boot medium must have an EFI partition which contains
binaries, and bootloader. This is something that must astute
observers have seen on flash drives for a number of years. In order to
allow them to function as bootable devices, they have EFI partitions on
their front. These small partitions must be either FAT12, FAT16 or
FAT32. All UEFI compliant systems must be able to read all of these FAT
variations.
"The file system supported by the Extensible Firmware Interface is based
on the FAT file system. EFI defines a specific version of FAT that is
explicitly documented and testable. Conformance to the EFI specification
and its associate reference documents is the only definition of FAT that
needs to be implemented to support EFI. To differentiate the EFI file
system from pure FAT, a new partition file system type has been
defined." 4
As such a EFI partition is a partition defined as such type in a gpart
record and which has a valid EFI approved version of the FAT file system
installed within it.
UEFI specifies a UEFI Boot Manager. Since the purpose of all this is
to boot an operating system, something the BIOS Specification seems to
do so matter of factly, UEFI includes a boot manager with specifications
WITHIN its environment, rather than leaving it to the operating system.
Just as BIOS reads extensions that it expects to find at predefined
locations, the UEFI Boot Manager is defined as follows:
“The UEFI boot manager is a firmware
policy engine that can be configured by
modifying architecturally defined global NVRAM
variables. The boot manager will attempt to load
UEFI drivers and UEFI applications (including
UEFI OS boot loaders) in an order defined by
the global NVRAM variables.” 4
For those used to looking at the CMOS over the years, this is largely
the "rubber hits the road" change to the booting process with UEFI. The
configuration system is entirely different and it is not alway clear
what you are looking at when your not experienced with UEFI when trying
to install an operating system. UEFI can be configured. You can alter
your boot menu when you start your system and activate the boot manager.
You can add drives, and twist up firmware configurations, even over
clock the CPU. Because of the size of the EFI Partition, this
application can be a graphic user interface, or a cursors like
configuration menu. Linux comes with a tool to help work with your boot
manager called efibootmgr.[9] It produces output such as this, when run
from user space:
[root-at-system directory]# efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0002,0000,0004
Boot0000* CD/DVD Drive BIOS(3,0,00)
Boot0001* Hard Drive HD(2,0,00)
Boot0002* Fedora HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi)
Boot0003* opensuse HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)
Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G .
[root-at-system directory]#
Here you can see the option: BootOrder which is to load first opensuse
(with its load path within the EFI partition specified), and then Fedora
and then the CD/DVD, and finally Hard Drive under BIOS(2,0,00)
Notice the EFI Paths described in the output of efibootmanager. They
can point at any device object that the firmware presents. This is not
just Hard Drives, but network devices, USB ports or devices not yet
invented. These paths are defined in the specification under
EFI_DEVICE_PATH_PROTOCOL. These protocols are very difficult to learn
and understand. They are defined in language programing, initially by
Intel and later by other vendors. An example is given by Intel in slide
13 and 14 in their presentation on UEFI located at
http://www.feishare.com/attachments/105_202%20UEFI-Drivers.pdf and where
it states:
Device Path Protocol - Example
GUID
#define EFI_DEVICE_
PATH_PROTOCOL_GUID \
{0x09576e91,0x6d3f,0x11d2,0x8e,0x39,0x00,0xa0,0xc9,0x69,0x72, 0x3b}
Protocol Interface Structure
typedef struct _EFI_DEVICE_PATH_PROTOCOL {
UINT8 Type;
UINT8 SubType;
UINT8 Length[2];
} EFI_DEVICE_PATH_PROTOCOL;
• The device path describes the location of the device
the handle is for
• A UEFI driver may access only a physical device for
which it provides functionality.
The slides go on to give an example of a SCSI Bus interface and a
discussion of the language implementation.
Phoenix company defines the fully paths for devices as follows. In this
exampe the path names are spelled out for the subset of devices that
Phoneix at least is supporting with this long and verbose specification for
device paths and structure within their firmware.[10] I quote the exact
specification in order to underscore how complex path naming is which
underlines that UEFI does not, as it claims, remove complexity from the
booting process. It does organize the complexity to make it more
managable in some instances.
_____________________________________________________________________________
*GUID
#define EFI_DEVICE_PATH_PROTOCOL_GUID \
{0x09576e91,0x6d3f,0x11d2,0x8e,0x39,0x00,0xa0,0xc9,0x69,0x72,0x3b}
*Protocol Interface Structure
#include EFI_PROTOCOL_CONSUMER(DevicePath) // for protocol
#include "Efi\EfiDevicePath.h" // for #define & structures
extern EFI_GUID gEfiDevicePathProtocolGuid;
typedef struct _EFI_DEVICE_PATH_PROTOCOL {
UINT8 Type;
UINT8 SubType;
UINT8 Length[2];
} EFI_DEVICE_PATH_PROTOCOL;
Members
Member Description
Type The type of device path node.
#define HARDWARE_DEVICE_PATH 0x01
#define ACPI_DEVICE_PATH 0x02
#define MESSAGING_DEVICE_PATH 0x03
#define MEDIA_DEVICE_PATH 0x04
#define BBS_DEVICE_PATH 0x05
#define END_DEVICE_PATH_TYPE 0x7f
SubType The sub-type of the device path now. The meaning depends on Type. For HARDWARE_DEVICE_PATH:
#define HW_PCI_DP 0x01
#define HW_PCCARD_DP 0x02
#define HW_MEMMAP_DP 0x03
#define HW_VENDOR_DP 0x04
#define HW_CONTROLLER_DP 0x05
For ACPI_DEVICE_PATH:
#define ACPI_DP 0x01
#define ACPI_EXTENDED_DP 0x02
#define ACPI_ADR_DP 0x03
For MESSAGING_DEVICE_PATH:
#define MSG_ATAPI_DP 0x01
#define MSG_SCSI_DP 0x02
#define MSG_FIBRECHANNEL_DP 0x03
#define MSG_1394_DP 0x04
#define MSG_USB_DP 0x05
#define MSG_I2O_DP 0x06
#define MSG_INFINIBAND_DP 0x09
#define MSG_VENDOR_DP 0x0a
#define MSG_MAC_ADDR_DP 0x0b
#define MSG_IPv4_DP 0x0c
#define MSG_IPv6_DP 0x0d
#define MSG_UART_DP 0x0e
#define MSG_USB_CLASS_DP 0x0f
#define MSG_USB_WWID_DP 0x10
#define MSG_DEVICE_LOGICAL_UNIT_DP 0x11
#define MSG_SATA_DP 0x12
#define MSG_ISCSI_DP 0x13
For MEDIA_DEVICE_PATH:
#define MEDIA_HARDDRIVE_DP 0x01
#define MEDIA_CDROM_DP 0x02
#define MEDIA_VENDOR_DP 0x03
#define MEDIA_FILEPATH_DP 0x04
#define MEDIA_PROTOCOL_DP 0x05
For BBS_DEVICE_PATH:
#define BBS_BBS_DP 0x01
For END_DEVICE_PATH_TYPE:
#define END_ENTIRE_DEVICE_PATH_SUBTYPE 0xFF
#define END_INSTANCE_DEVICE_PATH_SUBTYPE 0x01
Length The entire length of this device path node, including this header, in bytes.
Description
The executing IEFI Image may use the device path to match its own device
drivers to the particular device. Note that the executing UEFI OS loader
and UEFI application images must access all physical devices via Boot
Services device handles until ExitBootServices() is successfully called.
A UEFI driver may access only a physical device for which it provides functionality.
Type SubType Structure
_______________________________________________________________________
HARDWARE_DEVICE_PATH HW_PCI_DP PCI_DEVICE_PATH
HW_PCCARD_DP PCCARD_DEVICE_PATH
HW_MEMMAP_DP MEMMAP_DEVICE_PATH
HW_VENDOR_DP VENDOR_DEVICE_PATH
HW_CONTROLLER_DP CONTROLLER_DEVICE_PATH
ACPI_DEVICE_PATH ACPI_DP ACPI_HID_DEVICE_PATH
ACPI_EXTENDED_DP
ACPI_EXTENDED_HID_DEVICE_PATH ACPI_ADR_DP
ACPI_ADR_DEVICE_PATH
MESSAGING_DEVICE_PATH MSG_ATAPI_DP ATAPI_DEVICE_PATH
MSG_SCSI_DP SCSI_DEVICE_PATH
MSG_FIBRECHANNEL_DP
FIBRECHANNEL_DEVICE_PATH
MSG_1394_DP F1393_DEVICE_PATH
MSG_USB_DP USB_DEVICE_PATH
MSG_USB_CLASS_DP USB_CLASS_DEVICE_PATH
MSG_USB_WWID_DP USB_WWID_DEVICE_PATH
MSG_DEVICE_LOGICAL_UNIT_DP
DEVICE_LOGICAL_UNIT_DEVICE_PATH
MSG_I2O_DEP I2O_DEVICE_PATH
MSG_MAC_ADDR_DP MAC_ADDR_DEVICE_PATH
MSG_IPv4_DP IPv4_DEVICE_PATH
MSG_IPv6_DP IPv6_DEVICE_PATH
MSG_INFINIBAND_DP INFINIBAND_DEVICE_PATH
MSG_UART_DP UART_DEVICE_PATH
MSG_VENDOR_DP VENDOR_DEVICE_PATH
MSG_VENDOR_DP, GUID =
DEVICE_PATH_MESSAGING_PC_ANSI ---
MSG_VENDOR_DP,
GUID = DEVICE_PATH_MESSAGING_PC_VT_100
---
MSG_VENDOR_DP, GUID =
DEVICE_PATH_MESSAGING_PC_VT_100_PLUS
---
MSG_VENDOR_DP, GUID =
DEVICE_PATH_MESSAGING_PC_UTF8
---
MSG_VENDOR_DP, GUID =
DEVICE_PATH_MESSAGING_FLOW_CONTROL
UART_FLOW_CONTROL_DEVICE_PATH
MSG_VENDOR_DP, GUID =
DEVICE_PATH_MESSAGING_SAS
SAS_DEVICE_PATH MSG_ISCSI_DP
ISCSI_DEVICE_PATH MSG_SATA_DP
SATA_DEVICE_PATH
MEDIA_DEVICE_PATH MEDIA_HARDDRIVE_DP
HARDDRIVE_DEVICE_PATH MEDIA_CDROM_DP CDROM_DEVICE_PATH
MEDIA_VENDOR_DP VENDOR_DEVICE_PATH
MEDIA_VENDOR_DP, GUID= UNKNOWN_DEVICE_GUID
UNKNOWN_DEVICE_VENDOR_DEVICE_PATH
MEDIA_FILEPATH_DP
FILEPATH_DEVICE_PATH MEDIA_PROTOCOL_DP
MEDIA_PROTOCOL_DEVICE_PATH
BBS_DEVICE_PATH BBS_BBS_DP BBS_BBS_DEVICE_PATH
_____________________________________________________________________________
In section 8.3 of the original Intel Specification, EFI Specification
version 1.10, dated December 1, 2002, six paths are defined as follows:
Device Path Nodes
There are six major types of Device Path nodes:
1) Hardware Device Path. This Device Path defines how a device is attached
to the resource domain of a system, where resource domain is simply the
shared memory, memory mapped I/O, and I/O space of the system.
2) ACPI Device Path. This Device Path is used to describe devices whose
enumeration is not described in an industry-standard fashion. These
devices must be described using ACPI AML in the ACPI name space; this
Device Path is a linkage to the ACPI name space.
3) Messaging Device Path. This Device Path is used to describe the
connection of devices outside the resource domain of the system. This
Device Path can describe physical messaging information (e.g., a SCSI ID)
or abstract information (e.g., networking protocol IP addresses).
4) Media Device Path. This Device Path is used to describe the portion of
a medium that is being abstracted by a boot service. For example, a Media
Device Path could define which partition on a hard drive was being used.
5) BIOS Boot Specification Device Path. This Device Path is used to
point to boot legacy operating systems; it is based on the BIOS Boot
Specification Version 1.01. Refer to the References appendix for details
on obtaining this specification.
6) End of Hardware Device Path. Depending on the Sub-Type, this Device
Path node is used to indicate the end of the Device Path instance or
Device Path structure.[11]
You can see this specification reflected in the Phoenix development
protocols. Overall, there is a very verbose and user unfreindly naming
convention for identifying bootable objects within the UEFI bootloader,
all of which can be quite frightful when a user is confronted with
deleting a driver that the firmware initially places on the boot menu.
Firmware writers need to be careful to include a return to default
configuration in order to save the end user from themselves.
Returning back to the output of our sample efibootmgr output, and after
reviewing some of the specifications of EFI_DEVIDE_PATH_PROTOCOL, we can
now disect some of this output with better edification:
________________________________________________________________________
[root-at-system directory]# efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0002,0000,0004
Boot0000* CD/DVD Drive BIOS(3,0,00)
Boot0001* Hard Drive HD(2,0,00)
Boot0002* Fedora
HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi)
Boot0003* opensuse
HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)
Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G .
________________________________________________________________________
Boot0000, and Boot0004 are evidently legacy bios boot entries. Boot0002
and Boot0003 are native UEFI entries which point to different secondary boot
loaders, both being on the same hard drive device and both executables
residing in the EFI active partition, one for fedora and one for
opensuse. Boot0001 is a UEFI default boot if all else fails. This is
similar to a bios boot but the UEFI boot loader looks on the specified
hard drive for a efi binary based on the system architecture, such as
\EFI\BOOT\BOOTx64.EFI (for a x86 64 bit arch).
An important and controversial component of the UEFI specification is
the secure boot configuration. Theoretically the secure boot is designed
to address a security issue, which is a root kit attack. In real life,
this is a non-issue and of no concern whatsoever. What the secure
boot mechanism is actually for is to protect the vendors who wrote this
specification from the installation of competitive products on hardware
which they have OEM contracts with. Root kits require physical access
to sensitive parts of a computer system. Without physical security, one
can never have security of any kind. As a vector, firmware root kits
are one of the hardest attacks on a digital system. Gartner reports
that in 2013 over 19 BILLION dollars was spent on security software,
nearly all of it targeted for Microsoft Windows viruses and worms.[12] The
2013 security report from Sohpos outlines nearly ever possible vector
for malware on all platforms, with special emphasis on emerging devices.
In their comprehensive report firmware attacks are not considered even a
viable vector.[13] The standing threat is still standard Microsoft Windows.
For example, Microsoft shipped its latest operating system with a sliding
gadget that immediately had to be withdrawn because it served as a vector
for multiple malware attacks. [14]
"Applying the automated Microsoft Fix it solution described
in Microsoft Knowledge Base Article 2719662 disables the
Windows Sidebar experience and all Gadget functionality.
Recommendation. Customers who are concerned about
vulnerable or malicious Gadgets should apply the automated
Microsoft Fix it solution as soon as possible. For more
information, see the Suggested Actions section of this
advisory." [15]
So what is the problem being addressed? First and foremost, Secure Boot
is about vendor control and not security. This is obvious. No true
expert on cryptography or security has been able to demonstrate that
removal of security and keys from the users improves security of a
system. And furthermore there is scant evidence of a security issue
within the prebooting environment, that is up until now. In fact, Richard
Wilkins, of Phoenix Technologies, and Brian Richardson Intel
Corporation, write in their September 2013 paper on UEFI and computer
security 3 pages of outlined possible security issues and maleware
efforts, including documented in the wild programs and research test
programs and show current threats outside of the theoretical.
To quote one blogger at zdnet:
"You should do your readership a huge favor. Interview a
world-class cryptography expert [I suggest Ron Rivest over
at M.I.T., the "R" in RSA as you know], and ask him/her
the following question:
1. "Is there any technical reason whatsoever that
UEFI-Secure Boot should be tied to any particular OS
vendor in order for the end-user to realize the benefit
of secure-boot?"
2. "How would you have implemented secure-boot?"
Ask him/her to go into as much detail as reasonable, so
that all the tech-heads who read your journal are able
to follow along and conclude for themselves that the
binding to Windows is entirely artificial and concocted
by Microsoft.
The reason for doing such an interview is very important:
There are a lot of people, including the U.S. Department
of Justice, for whom cryptography is a kind of black
magic. They do not know what is fact and what is fiction,
even after reading the specifications for asymmetric
crypto, because it takes a while to be able to understand
crypto primitives well-enough to know that nobody is
pulling the wool over your eyes. "
In fact, it seems very apparent that the perceived threat to system
security, such as any exist at the preboot level, is largely from the
UEFI environment itself. It actually boots an mini-operating system and
the EFI Partition can represent a whole new security hole, especially
when linked to a non-secure operating system such as Microsoft Windows.
"The examples outlined above describe similar attack
methods . The bootkit is deployed in the form of
a UEFI executable , to masquerade as the default
operating system boot loader. The bootkit then
launches a patched version of the operating system
loader, adding exploit code before the operating
system loads malware protection...While rootkits and
bootkits are an issue for any system, including legacy
BIOS environments, they present a unique challenge
to the UEFI ecosystem. The entire philosophy behind
UEFI is to standardize and allow for extensibility
of the pre - boot interface. While this openness
and standardization can make the system vulnerable
to attacks that would have been more difficult in
legacy BIOS , it is important to acknowledge that
legacy BIOS had very limited provisions for detection
or defense. Any optimal solution for UEFI needs to
embrace flexibility , while limiting attack vectors ,
mitigating risk, promoting possibilities and providing
methods for manufacturers and users to control their
security policy."[17]
This heady combination of desire for vendor control, an inherently
insecure preboot environment, and consideration of the significant legal
ramifications, there has been good reason for the Secure Boot protocols
and their abuse by Microsoft Corporation, who in addition to wanting
system control as a means of market dominance, also understands that
they have an insecure operating system just ripe for being taken
advantage of through the UEFI security hole which they will allow access
to.
Secure Boot is a system within EFI where the binaries for the operating
system and other binaries are cryptographically signed. This prevents
tampering as the system will not boot a binary which is not signed when
secure boot is turned on within the UEFI firmware.
What is a cryptographically signed binary? Most cryptography today uses
asymmetrical (known also as public key) encryption. In its simplest
form, someone creates a private key and safely stores it. An algorithm
allows for the creation of a many public keys. A plain message can then
use an algorithm to encrypt the plain message. The algorithm is such,
however, where ONLY THE PRIVATE KEY can decrypt the encrypted message.
There are many versions of asymmetric encryption standards including
Diffie–Hellman key exchange protocol, DSS (Digital Signature Standard),
which incorporates the Digital Signature Algorithm, ElGamal, Various
elliptic curve techniques, Various password-authenticated key agreement
techniques, Paillier cryptosystem, RSA encryption algorithm (PKCS#1),
Cramer–Shoup cryptosystem, YAK authenticated key agreement protocol
and others.[18]
Steps for Standard Encryption of a message using Public Keys:
______________________________________________________________________________
Step 1: LONG_DATA_STREAM ==> Encryption ==> Private Key
Step 2: Private Key ==> Asymmetric Algorithm ==> Public Key (make as many as you
want)
Step 3: Distribute Public Key
Step 4: Plain Message ==> Encrypt with Public Key ==> Unreadable Message
Step 5: Unreadable Message can only be decrypted with the PRIVATE key **
Step 6: Unreadable Message ==> DECRYPT with Private Key ==> Plain Message
Signing some data with a binary signature is a bit more complex. it
requires that with a public key, one can determine that a message was
signed with the public keys private key, although it can not decrypt the
message. In the case of signatures, it is not necessary to decrypt the
signature, in fact the message is gibberish in content, but only that it
was generated from a specific private key. RSA is an algorithm that can
perform this task and the entry in Wikipedia explains binary signatures
better than I could reformulate the process.
Suppose Alice uses Bob's public key to send
him an encrypted message. In the message, she
can claim to be Alice but Bob has no way of
verifying that the message was actually from
Alice since anyone can use Bob's public key to
send him encrypted messages. In order to verify
the origin of a message, RSA can also be used
to sign a message.
Suppose Alice wishes to send a signed message
to Bob. She can use her own private key to do
so. She produces a hash value of the message,
raises it to the power of d (modulo n) (as she
does when decrypting a message), and attaches
it as a "signature" to the message. When Bob
receives the signed message, he uses the same
hash algorithm in conjunction with Alice's
public key. He raises the signature to the power
of e (modulo n) (as he does when encrypting
a message), and compares the resulting hash
value with the message's actual hash value. If
the two agree, he knows that the author of the
message was in possession of Alice's private
key, and that the message has not been tampered
with since.
Since the hash value is constructed from the message itself, not only
are we certain of the origins of the message (Alice), but also that the
content has not been altered.[19] [20]
Secure Boot uses this technique to evaluate binaries that it boots.
There are several levels of keys that the secure boot system uses, which
creates a hierarchical system of trust. The 4 types of keys are as
follows, from top to bottom:
PK - Platform Key, this is the top level public key on the system whose private key is
owned by the OEM of the hardware. It is used to sign all other keys on
the system.
KEK - Key Exchange Keys, is more properly described as a database of
keys. These keys can only be entered into the firmware with PK key
authority. The KEK has keys from the vendor, OEM, other operating system
vendors, and the KEK entries authorize updates to the DB/DBX.
DB is the ‘allowed’ list of code that can execute, and for a Microsoft (R)
Windows8 machine contains a Microsoft OS certificate, the Microsoft UEFI CA
cert, and possibly other OSV/ISV entries
DBX is the 'disallowed and Blocked' list of code. 21,22
With a secure boot, the sequence of events for authorization to run
binaries on the firmware is as follows:
The fireware loads binary objects and checks them against the DB and the
DBX list. If the binary's signature is not within the DB list, or if it
is in the DBX list, then it will not be run and the booting process will
usually halt.
"As the boot process proceeds from an initial
protected firmware core, it will load and execute
additional sections of code, drivers and Option
ROMs (code provided by peripheral manufacturers
to enable their devices). Eventually this
process culminates in the loading and execution
of the operating system boot loader that starts
the operating system execution. As each code
section is loaded, and before it is executed,
the firmware confirms that its signature matches
one in its database of authorized signatures,
and also that the signature is not in the
forbidden database. This includes the operating
system boot loader itself. What the firmware
does with the signature matching information
is a policy decision, and is not defined by the
specification. Typically, unauthorized code will
not be executed, and therefore, the system may
not be able to complete the operating system
bootstrap process." 22
The problem has been that Microsoft controls the signing agency for the
KEK keys within the firmware. While the UEFI rules for a secure boot
should allow for ownership control and the secure boot process,
Microsoft has effectively blocked other signing agents from being
brought on board by hardware manufacturers because of Microsoft's
near monopoly and OEM sold x86 hardware. Initially it was a concern
that x86 hardware would be blocked from installation of any
non-Microsoft operating systems and binaries. Some of this concern has
been alleviated by actions of Microsoft which assure that on x86
platforms that the terms of the Microsoft OEM will require that
firmwares allow for the secure boot to be turned off. This is not true,
however,for ARM processors, and Microsoft is not alone in locking down
such devices.
There is a glitch in this solution, however. Going forward, it is a
huge question as to if it is safe to run a UEFI booted system without a
secure boot. The reason for this is exactly what was pointed out
Wilkins and Richardson, which is that UEFI, with its virtual machine,
readable partitions and userspace toolkits, makes a very target rich
vector for malware in the future. 17 Just turning off secure boot on an
industrial server comes with some serious risks that need to be
accessed.
References:
_______________________________________________________________________________
[1] http://www.tomshardware.com/reviews/intel-uefi-firmware,2486.html
[2] https://en.wikipedia.org/wiki/BIOS
[3] Sebastian Anthony on September 22, 2011
http://wwwextremetech.com/computing/[96985]-demystifying-uefi-the-long-overdue-bios-replacement
[4] https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
[5] Logical block addressing (LBA) is a common scheme used for specifying
the location of blocks of data stored on computer storage devices,
generally secondary storage systems such as hard disks
LBA is a particularly simple linear addressing scheme; blocks are located
by an integer index, with the first block being LBA [0], the second LBA 1,
and so on
[6] https://en.wikipedia.org/wiki/GUID_Partition_Table
[7] http://www.rodsbooks.com/efi-programming/hello.html
[8] https://software.intel.com/en-us/articles/uefi-shell/
[9] http://linux.die.net/man/8/efibootmgr
[10] http://wiki.phoenix.com/wiki/index.php/EFI_DEVICE_PATH_PROTOCOL
[11] EFI Specification 1.10 - December 1, 2002:
http://wwwintel.com/content/dam/doc/product-specification/efi-v[1]-10-specification.pdf
[12] http://www.gartner.com/newsroom/id/2762918
[13] http://www.sophos.com/en-us/medialibrary/PDFs/other/sophossecuritythreatreport2013.pdf
[14] https://nakedsecurity.sophos.com/2012/07/12/disable-windows-sidebar-gadgets/
[15] https://technet.microsoft.com/library/security/2719662
[16] http://www.zdnet.com/uefi-and-secure-boot-in-depth-7000012138/
Article titled "UEFI and secure boot in depth Summary: Q&A: My
questions on UEFI and secure boot, answered by Mark Doran, the president
of the UEFI Forum" by J.A. Watson March [13], 2013
[17] http://www.uefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_2013.pdf
[18] http://en.wikipedia.org/wiki/Public-key_cryptography
[19] http://en.wikipedia.org/wiki/RSA_%28cryptosystem%29#Signing_messages
[20] http://upload.wikimedia.org/wikipedia/commons/2/2b/Digital_Signature_diagram.svg
[21] Victor Zimmer Engineering Blog September 28th, 2013
http://vzimmerblogspot.com/[2013]_09_01_archive.html
[22] Richard Wilkins, Ph.D., Brian Richardson: UEFI SECURE BOOT IN MODERN COMPUTER SECURITY SOLUTIONS
http://wwwuefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_[2013].pdf
--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=unknown-8bit
Content-Disposition: attachment; filename="uefi_pages.txt"
Content-Transfer-Encoding: 8bit
2014-11-18 03:37 UEFI - The New Bootings System Page 1
IBM/PC/Intel Based computers, like all other computing systems, need to
boot when they are powered on. The computer's various parts and in and
out devices need to be defined in order to allow access to resources.
In order to facilitate booting, PC based systems have a variety of ROM
like storage systems to read the program that begins the booting process.
When a computer starts, it has no knowledge of itself. It is a blank
slate. All the information that the system needs to know about itself,
in order to process user programs and to do useful tasks, requires
an increasingly complex task of making resources available and known.
In order to do this, systems are hard wired to look for the starting
instructions at fixed locations on the system. These locations
are specific for different hardware types. For example on Intel x86
processors, memory location FFFF:0000 is always the first instruction that
the CPU is begin executing with. Other systems have different locations,
and even different addressing schemes.
Intel x86 based system include ROM based firmware called a BIOS.
The BIOS (Basic Input/Ouptput System), has exacting specifications.
Although they can vary, for a specific x86 type of architecture, they can
only vary within the confines of the specification. A BIOS relies on the
x86 architecture’s 16-bit real mode which is a long was of saying that
it works in the environment of a 16 bit CPU of the x86 type. Since all
the intel chips have been backwardly compatible to this standard, up
until now, BIOS, and CMOS software that accesses the BIOS has been at
the core of system start ups for intel based hardware for a generation.
Over time, there has been increasing demands on hardware booting.
Even early in the history of the PC, there was a need to use PCs as thin
clients and for network booting. This required that network cards, and
networking protocols to be active prior to the booting and
implementation of the operating system. There was the creation of the
BOOTP and TFTP (trivial FTP) and a slowly a whole alphabet soup of
acronyms have been introduced into the lingo of booting system.
In addition to this, more than one operating system are now installed on
system, and hard drive capacities have grown further that the 16 BIOS
addressing scheme can read. Hard Drives have had master boot records,
but over time, booting information has moved off the master boot record
and onto various partitions. Additionally, modern Free Software and
proprietary systems can run on a variety of hardware outside of the
world of the x86 architecture.
Bios and CMOS can now also be flashed, to be updated and allow for more
flexible configurations. Tablets, micro-tables(phones), and new laptop
designs with touch screen are standard input devices have become
population. All this has put pressure to redesign the booting system
for commodity hardware.
"In the end, the BIOS is still here and still does what it has been doing
for the last 25 years: making sure your operating system can boot. It
was never designed for today’s massive diversity of hardware. It’s
still stuck with 16-bit interfaces and software interrupts, interrupt
routing and maximum precision timers, limited ROM execution space (1
MB) and image size, a limited number of initializeable devices (which
is critical in the server space), proprietary extensions, and missing
2014-11-18 03:37 UEFI - The New Bootings System Page 2
modularity—just to name a few issues." [1]
This has been a blessing and a curse. Efforts to remove the BIOS
functionality have always been targeted to take away the flexibility of
run anything, clean and simple interface. IBM's MicroChannel
architecture is but one an example. Intel finally took the bull by the
horns with the introduction of the Itanium’s IA64 architecture (along
with HP) in 2003. This was a PC like server architecture that needed
around some of the BIOS limitations. The created the EFI standards
(adding more acronyms to the soup), and handed off its future to the
industrial consortium called Unified Extensible Firmware Interface Forum
which is an acronym for AMD, Insyde Software, American Megatrends, Inc..
Intel, Apple Inc, Lenovo, Dell, Microsoft, Hewlett Packard,
Phoenix Technologies and IBM. There is a SINGLE non-profit engineering
or standards group represented on UEFI forum. The result is some very
useful specifications a washed in some game changing lock down mechanism
designed to do what IBM could never accomplish with microchannel.
UEFI, in fct, is nearly an operating system sitting between your
firmware and your operating system. "It not only offers driver support,
interfaces, and services, but it also has a shell that allows users to
execute applications on a command line interface." [1]
The generalized process of UEFI booting is as follows:
1- UEFI Firmware: Performs CPU and Chipset initialization and loads
drivers
2- UEFI Boot Manager - Loads device drivers and the boot application
3- Loads the OS boot manager selected by the user
4- Loads the OS
5- Runs the OS Kernel
EFI (the Intel Child of UEFI) has tables and offers run level services
to the operatings. This is similar to the runtime services that
unix-like operating systems have had for decades. Boot Services include
file services, text and graphic user consoles, and the run services can
offer access to Non-volatile random-access memory (NVRAM), date and
time, etc. EFI drivers have specific communication protocols that all
components can use. The EFI device driver environment s a virtual
drive, like what Java uses, called the EBC, which provides a CPU
independent development target for UEFI module development.
Overall Boot Time line
Part 1:
Power On
Secure Boot
Pre EFI Initialization (PEI)
PIE Core
CPU Init
Chipset Init
Board Iniit
2014-11-18 03:37 UEFI - The New Bootings System Page 3
EFI Driver Dispatcher
Architecture Protocols
Driver Execution Environment
Device, Bus and Service Driver
Utilization of the EFI Driver Dispatcher
Boot Device Selection
Boot Manager
Transition System Load
OS Absent Application
UEFI Shell
Transient OS Boot Loader
Final OS Boot Loader
Run Time
OS environment
applications
The complete specification for UEFI is now 2098 pages of text available from
the UEFI forum, and as such, is far more detailed than the limits of
this paper. It's complete current source is at
http://www.uefi.org/sites/default/files/resources/2_4_Errata_B.pdf .
The transformation from CMOS/BIOS is significant and deserves some
understanding and attention.
UEFI is an embrace and extend technology for the system bios. It does
not eliminate fundamental firmware, but masks some of the complexity
for developers and computer users. It also provides for a locked down
mechanism for purchased systems such that their operating systems can not
be removed or altered. It therefor provides a key objective of
operating system vendors and computer system manufactures such that
previously has been denied them by the open standards of BIOS and CMOS.
Upon powering up the system, BIOS bases systems have a very specific
agenda of items that they must perform in order to be compliant with the
specifications. With a BIOS the x86 CPU resets and loads a PC at the top
of the one megabyte real mode address space which is where the BIOS
program is resident. Then a jump instruction is set to move the PC to
an earlier location where the BIOS is run. The system can be reset from
a cold boot or a warm boot. Flags determine which process to follow.
On a cold boot, the bios runs a "post". On a warm boot it does not.
Post identifies the systems parts and the CPU, RAM, interrupt and DMA
controllers and other parts of the chipset, video display card, keyboard,
hard disk drive, optical disc drive and other basic hardware. After
posting, optional ROMs are searched for which extend functionality.
These ROMs exist in upper memory, and the BOIS scans memory from
0x0C0000 to 0x0F0000 on the 2 KiB boundary. ROMs have a memory boundary
of 0x55 0xAA followed by a byte that describes the number of 512 byte
blocks that the expansion ROM sits at in real memory. A checksum is of
the 512 byte block that is calculated and if valid, the execute jumps to
the optional ROM which now controls the system. ROMS normally return
back to the BIOS which scans for the next ROM until the entire sector of
memory is scanned.
2014-11-18 03:37 UEFI - The New Bootings System Page 4
Finished with all this, the BIOS now calls INT 19h. INT 19H is a software
interrupt that puts address 0019H onto the address bus and starts executing
code found there. 0019H is normally a jump instruction. Usually this loads
data from Head 0, Track 0 of Sector 1 of a disk. This would be the Master
Boot Record (MBR). Information received by the Post determines which disks
are attempted to locate a bootstrap loader, installing it into memory
location 0x0000:0x7C00. The bloatstrap loader reads in the partition
table and the operating system. [2]
The bios is a dumb device that does not process instructions from the
boot sector. This is left to the bootstrap program. What is most
important to understand is that the entire BIOS specification is very
specific with exact definitions of interrupts, memory mappings, from
interrupt definitions, hard drive specification and a plethora of exact
locations and limitations in order to get from power of to OS running.
Much of this detail was created because the x86 specification was
designed for the purpose of emulating the specific IMB/PC XT product and
architecture. The new UEFI specification buries much of this
specification and leaves the implementation specifics to individual
firmware companies. Under the hood, one motherboard under UEFI might
use an entirely unique set of addressing schemes and interrupts then
another, as long as BOTH end up showing an interface that complies with
the UEFI specification.
"While BIOS is fundamentally a solid piece of firmware, UEFI is a
programmable software interface that sits on top a computer’s hardware
and firmware (and indeed UEFI can and does sit on top of BIOS). Rather
than all of the boot code being stored in the motherboard’s BIOS, UEFI
sits in the/EFI/ directory in some non-volatile memory; either in NAND
on the motherboard, on your hard drive, or on a network share (more on
that later)." [3]
Bootloaders have been constrained to fit in 446 bits of the master boot
record and run in 32k of system memory. These are called first stage
boot loaders and the partition tables are in a default 64 byte partition
table with four primary partitions, in its most generic form.
Boatloaders most often load secondary boot loaders that are more
flexible, such and GRUB. These loaders allow for multiple operating
system installation or to load operating systems in different states.
They read partition tables and load systems accordingly.
UEFI takes a different approach. As one tech blogger wrote, "Now let’s
look at how booting works on a UEFI system. Even if you don’t grasp the
details of this post, grasp this: it is completely different. Completely
and utterly different from how BIOS booting works. You cannot apply any
of your understanding of BIOS booting to native UEFI booting. You cannot
make a little tweak to a system designed for the world of BIOS booting
and apply it to native UEFI booting. You need to understand that it is a
completely different world." [4] I think this is overstated. Eventually
every computer system has to do exactly what a BIOS based system does.
It has to reach into the architecture of a computer, identify some
subset of its working parts, and bootstrap a fully functional operating
system into its memory while running the operating systems viable
instruction set. UEFI is an attempt to hide much of this hardware
complexity and substitute it with software complexity that looks
simpler. There are inherent problems with this approach, the first
2014-11-18 03:37 UEFI - The New Bootings System Page 5
being is the scale of the introduced complexity. Let's review some of
this introduced complexity.
One of the first changes to the booting process involved the change from
the MBR standard to what is no known as GPART or GPT standard. There
was an essential problem to the original BIOS specification that was
simply outgrown over time, namely the limitation of the size of
partitions that could be read from hard drives. The Master Boot Record,
is that special sector at the very beginning of a fixed disk that
describes the partition table of the disk and contains the primary boot
loader. The MBR is limited to 32 bits and with a sector size set at 512
bytes, hard drive addressing is limited to a shade over 2 terabytes in
size. In order address partitions greater than 2 terabytes, another
scheme was needed. That scheme came the way of the GUID Patition Table,
(GPT).
This is the layout for a modern Master Boot Record:
________________________________________________________________________
ADDRESS Description Size in Bytes
Hex Dec
________________________________________________________________________
+000h +0 Bootstrap code area (part 1) 218
+0DAh +218 0000h Disk timestamp[4][b]
(optional, MS-DOS 7.1-8.0
(Windows 95B/98/98SE/ME),
alternatively can serve as OEM
loader signature with NEWLDR) 2
+0DCh +220 original physical drive (80h-FFh) 1
+0DDh +221 seconds (0-59) 1
+0DEh +222 minutes (0-59) 1
+0DFh +223 hours (0-23) 1
+0E0h +224 Bootstrap code area (part 2, code
entry at +000h) 216 (or 222)
+1B8h +440 32-bit disk signature
Disk signature (optional, UEFI,
Windows NT/2000/Vista/7 and other
OSes) 4
+1BCh +444 0000h
(5A5Ah if copy-protected) 2
+1BEh +446 Partition entry #1
Partition table
(for primary partitions) 16
+1CEh +462 Partition entry #2 16
+1DEh +478 Partition entry #3 16
+1EEh +494 Partition entry #4 16
+1FEh +510 55h Boot signature[a] 2
+1FFh +511 AAh
________________________________________________________________________
Total size: 218 + 6 + 216 + 6 + 4×16 + 2 512 (from WIKIPEDIA)
GUID Partition Tables, which are now a key component of the UEFI
specification, feature divisions of memory through the modern LBA
placement and memory scheme. Previously, hard drive locations were
identified by the (Cylinder, Head, Sector) tuples, which identified a
location through the raw location of the hard drive. As drives changes
and new media emerged, CHS was replaced by LBA (Logical Block
2014-11-18 03:37 UEFI - The New Bootings System Page 6
Addressing).[5] The pr |
|
