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