CHAPTER 1

INTRODUCTION ON UEFI HISTORY

In the beginning, there was Basic Input/output System (BIOS). Back in those times,
processors were running in 16-bit mode, and Random-access memory (RAM) was
architecturally limited to 1 megabyte. As the evolution went forth, came 32-bit, and
later 64-bit x86 Central processing unit (CPU), amount of RAM was increasing, and
new ways of accessing it were being developed. But BIOS remained same. This
situation was far from ideal, since BIOS code was very limited, and operating system
loader had to load kernel just with using the most basic BIOS services, from 20 years
ago. [1] Creating new standard seemed impossible on such diverse market. But it
was done anyway.

1.1

Development of UEFI standard

It all has begun when Intel decided to develop 64-bit CPU. They made decision
which was very good logically, but unfortunately not as good market-wise: to get rid
of all ancient x86 features, drop entire x86 backward portability, and create
completely new CPU architecture, named Itanium (IA64). That also meant that old
1

BIOS won't be running on it, and so opportunity opened for new standard interface
between OS and hardware/firmware. This is how first steps took place in the half of
90s, to replace BIOS by new standard, called Extended Firmware Interface (EFI).
EFI is very different from old BIOS: it offers wide range of functionality even before
OS starts loading, it is modular (you can add custom code or drivers), runs on various
platforms, applications and drivers for it can be written in C not in Assembly, thus
they are more portable, etc. Besides native CPU code, EFI supports custom byte
code, so drivers can be compiled so that they are portable between CPU architectures
without need for recompilation. [5]

1.2

Implementations

Next important thing for Unified Extensible Firmware Interface (UEFI) to become
real standard, besides specification, is some implementation on real hardware. Intel
had his own implementation of EFI 1.10 standards, called Platform Innovation
Framework, or The Framework in short, or Tiano by project name. From this, in
2005 Intel released core part dubbed TianoCore, or EFI Development Kit (EDK).
This project became open-sourced, and is now developed by companies and
volunteers from all over the world. First company besides Intel to implement EFI
was Insyde. They offer their implementation called InsydeH20, or lightweight
version of it called InsydeDIY. It seems these only support UEFI 1.x standards, as
Insyde doesn't ever mention UEFI 2.0 on their site, nor is x86-64 CPU on list of
supported CPUs. [2]

Phoenix Technologies supports UEFI 2.0 in its brands SecureCore, TrustedCore, and
AwardCore Tiano. They also offer development environment for driver
programming, called UEFI Platform Initialization DDK: Phoenix TrustedCore,
Phoenix SecureCore, and Phoenix AwardCore Tiano. [3]
AMI (American Megatrends Inc.) supports UEFI 2.0 in their codebase Aptio. The
32-bit implementation of Aptio can be found on Efinity motherboards (by MSI), and
we are expecting UEFI 2.x implementation on MSI 45 boards very soon. Since UEFI
standard defines exact binary interface, standalone UEFI drivers and applications are
portable between various implementations. All version of standard are also backward
compatible. The UEFI standard also supports old-style boot via 16-bit real mode
code, so it can be used with OSes that don't have UEFI support, but in this case UEFI
runtime drivers doesn't work. So, most motherboard has both old school BIOS and
UEFI implementation. [4]

1.3

What is UEFI?

UEFI (Unified Extensible Firmware Interface) is a specification that defines an

interface between a PCs firmware and an operating system. It replaces or can work
in concert with the Basic Input/output System (BIOS) firmware that PCs have
traditionally used. For Windows 8, a key part of this specification is Secure Boot,
which protects the PC from malware by allowing only authorized boot loaders to run
when the computer starts. UEFI Secure Boot was created to enhance security in the
pre-boot environment. UEFI Forum members developed the UEFI specification, an
interface framework that affords firmware, operating system and hardware providers
a defence against potential malware attacks. [5] Without UEFI Secure Boot, malware
developers can more easily take advantage of several pre-boot attack points,
including the system-embedded firmware itself, as well as the interval between the
3

firmware initiation and the loading of the operating system. Secure Boot helps
firmware, operating system and hardware providers cooperate to thwart the efforts of
malware developers.

1.4

The most common misperceptions about UEFI and UEFI Secure Boot

Several misperceptions about UEFI Secure Boot, its intended uses, requirements and
application exist within the technology and end-user community. A few of the most
common are outlined below and in greater depth throughout this paper.

False: UEFI Secure Boot is an attempt to lock platforms to software from

specific vendors and block operating systems and software from others.

False: UEFI Secure Boot requires a TPM chip, as described by the Trusted

Computing Group (TCG), and TCG controls the UEFI specification.

False: UEFI Secure Boot requires a specific implementation by computer

manufacturers and operating system vendors. [6]

1.5

Standard

UEFI is the moniker for industry standards group, the UEFI Forum, that is
responsible for the governance of UEFI specifications. Furthermore, within the UEFI
organization, there are several groups. First, the UEFI Specification Working Groups
(USWG) manages the evolution of the main interface document. Today, the UEFI 2.1
specification represents the latest version.
4