UEFI virtual machine firmware hardening through

snapshots and attack surface reduction

Mikhail Krichanov Vitaly Cheptsov
Ivannikov Institute for System Programming Ivannikov Institute for System Programming
of the Russian Academy of Sciences of the Russian Academy of Sciences
Moscow, Russia Moscow, Russia
[email protected] [email protected]
arXiv:2111.10167v1 [cs.SE] 19 Nov 2021

Abstract—The Unified Extensible Firmware Interface (UEFI) operating system runs on top of the UEFI firmware and can
is a standardised interface between the firmware and the oper- usually be viewed as a tandem of a UEFI application, serving
ating system used in all x86-based platforms over the past ten as an operating system bootloader, and a UEFI-compatible
years. A side effect of the transition from conventional BIOS
implementations to more complex and flexible implementations kernel, which is aware of the features brought by the UEFI
based on the UEFI was that it became easier for the malware to firmware through the UEFI specification.
target BIOS in a widespread fashion, as these BIOS implementa- The malicious code running at the firmware level could
tions are based on a common specification. This paper introduces be used to compromise any components that are loaded later
Amaranth project - a solution to some of the contemporary in the boot process, including boot loader, hypervisor, and
security issues related to UEFI firmware. In this work we focused
our attention on virtual machines as it allowed us to simplify operating system. Compared to the legacy x86 firmware, which
the development of secure UEFI firmware. Security hardening did not employ any built-in security features in the majority
of our firmware is achieved through several techniques, the of the platforms, the UEFI firmware is supposed to build a
most important of which are an operating system integrity chain of trust and ensure that the operating system it runs is
checking mechanism (through snapshots) and overall firmware not compromised. This change made the x86 system firmware
size reduction.
an even more attractive target for the attacks, as it is now
Index terms— firmware, security, UEFI, virtual machines.
required to hijack the chain either on the operating system
I. I NTRODUCTION side or the firmware side. A side effect of the transition from
conventional BIOS implementations to more complex and
It has become common sense to model computer architec-
flexible implementations based on the UEFI was that it became
ture as a multi-layer system. When describing a computing
easier for the malware to target BIOS in a widespread fashion,
system on a high level, NIST defines four layers: application
as these BIOS implementations are based on a common
software, operating system, system firmware, and hardware
specification.
[2], [3]. Here the combination of system firmware and hard-
The industry community does pay attention to platform
ware can comprise something that we call platform. The
security issues, such as protecting the integrity of the firmware
existence of a platform is meant to leverage the complexity of
and mechanisms for updating it [2], [3], but, as this paper
hardware initialisation tasks to the earlier boot stage in order
shows, much still remains to be done in this field. In section
to essentially simplify the operating system code.
II we briefly discuss the latest industry advancements in
The Unified Extensible Firmware Interface (UEFI) [1] is
defending the x86 platforms with the firmware. In section III
a standardised interface between the system firmware and the
we demonstrate how this knowledge applies to hardening the
operating system used in all x86-based platforms over the past
virtual machine firmware, and in section IV we provide the ex-
ten years. Migrating to the UEFI solved multiple operating sys-
cerpts of our practical experience, gained while implementing
tem design issues, including the unification of the boot code,
the Amaranth project, designed to make our virtual machines
deprecation and removal of the undocumented vendor-specific
more secure.
extensions, interface simplification for early Input/Output (IO),
boot path determination, hardware enumeration, and many II. S TATE OF THE ART
more. When speaking about the UEFI, one generally considers Nowadays UEFI firmware from different vendors are ex-
three things: tremely overcomplicated and tend to provide as many means
• the UEFI firmware; of interaction with the user as operating systems do. According
• the UEFI specification; to the recent studies [4], optional code (code, which does
• the UEFI operating system. not participate in the boot process) can constitute up to 70%
The UEFI firmware, commonly named the UEFI BIOS (table I) of the total size of system firmware and can be safely
(Basic Input/Output System) on x86 platforms for historic removed without any impact on the functioning of the target
reasons, is the main component of system firmware. The UEFI applications.

1
 TABLE I [7].
P ERCENTAGE OF UNNECESSARY CODE IN MODERN FIRMWARE [4].
Summarizing the above, upon taking a random x86-based
platform on the market, one will face a list of common security
Original Final issues related to x86-firmware we outlined below.
Motherboard firmware firmware Reduction
size (KiB) size (KiB) 1) A bloated firmware codebase leads to an increase of the
SuperMicro A1SAi-2550F (V519) 3013 903 70.91% overall vulnerability surface and exploit availability.
Tyan 5533V101 4520 1916 39.82%
HP DL380 Gen10 46102 27809 39.68% 2) Unauthenticated BIOS updates lead to the installation of
SuperMicro A1SAi-2550F (V827) 3000 2108 29.76% the UEFI implants, which compromise the entire system.
SuperMicro A2SDi-12C-HLN4F 3618 2680 25.91% 3) Outdated BIOSes with known security issues [14] also
SuperMicro A2SDi-H-TP4F 3645 2766 24.12%
lead to an increase of availability of exploits.
SuperMicro X10SDV-8C-TLN4F 4519 4209 6.87%
4) The UEFI bootloaders commonly fail to check all the
files they use in the boot process, providing room to
compromise the target system and bypassing the trust
Optional firmware code is not only a waste of the SPI chains and security mechanisms such as UEFI Secure
(Serial Peripheral Interface) flash memory, it also has major Boot [15].
security implications. A recent study has shown that because 5) The UEFI Secure Boot is both extremely overcom-
of numerous additional modules in UEFI images, and large plicated and lacking functionality. It misses certificate
amount of code reuse between images, certain attacks can be chains, which resulted in all Option ROM and third-
easily and reliably automated [6]. party operating system vendors signing their code by
The following are typical ways to infect UEFI firmware the same certificate. At the same time the revocation
with a persistent rootkit or implant: only works on per-file or per-certificate basis, completely
ignoring the sequential nature of vulnerability fixing,
1) Modifying an unsigned UEFI Option ROM
making rollback protection, generally solved by security
An Option ROM is PCI/PCIe expansion firmware (Pe-
counters, nearly impossible on x86. To add more, a
ripheral Component Interconnect (Express) – I/O bus for
convoluted signature format, requiring the file to be
connecting peripherals to the computer’s motherboard)
heavily parsed for the verification, contributes to the
in x86 code located on a PCI-compatible device. An
overall availability of implementation exploits.
Option ROM is loaded, configured, and executed dur-
6) Misconfigured SPI flash protection mechanisms (regis-
ing the boot process. In 2012 a variety of techniques
ters BIOS CNTL, PRx [16]) allow an attacker to write
for infecting Apple laptops was introduced, including
malicious code to SPI flash memory and completely
through Option ROMs [8]. At Black Hat 2015 an attack,
compromise an entire system.
named Thunderstrike, was demonstrated that infiltrated
7) SMM: vulnerabilities in SMI handlers [17], [18], [19]
the Apple Ethernet adapter with modified firmware that
lead to privilege escalation, i.e. execution of malicious
loaded malicious code [9]. Specifically, Thunderstrike
code with SMM privileges.
loaded the original Option ROM driver with additional
8) Malicious peripherals: unsigned Option ROMs and lack
code that was then executed because the firmware did
of separation of the degrees of trust for different devices,
not authenticate the Option ROM’s extension driver
whether it’s an embedded media or an external one, lead
during the boot process.
to DMA (Direct Memory Access) attacks [20].
2) Adding/modifying a DXE driver
9) S3 resume boot-script [21], [22] vulnerabilities are sim-
By modifying a legitimate DXE (Driver eXecution En-
ilar to those in SMI handlers as they lead to privilege
vironment) driver in the firmware, an attacker is able to
escalation in PEI (Pre-Efi Initialisation) stage right after
introduce malicious code that will be executed in the pre-
platform wake-up.
boot environment, at the DXE stage. One way to modify
10) Privileged coprocessors, such as Intel ME/AMT, are
a DXE driver in the UEFI firmware image is to bypass
additional devices, which vulnerabilities allow to bypass
the SPI flash protection bits by exploiting a privilege
any other security mechanisms of a system [23], [24].
escalation vulnerability [10], [12]. Elevated privileges
allow the attacker to disable SPI flash protection by Good firmware implement mitigations on both software and
turning off the protection bits. Another way is to exploit hardware levels to reduce the impact of the attacks belonging
a vulnerability in the BIOS update process [11], [13] to each of these categories.
that allows an attacker to bypass update authentication
III. H ARDENING FIRMWARE FOR VIRTUAL MACHINES
and write malicious code to SPI flash memory.
3) Adding a new bootloader (bootkit.efi) The development of a secure firmware is a vast problem.
An attacker can add another bootloader (or replace To narrow this task we decided to focus our attention on a
the old one) to the list of the available bootloaders simpler problem of creating a secure firmware for the virtual
by modifying the BootOrder or Boot#### EFI- machines. During the development of the firmware we had to
variables, which determine the order of OS bootloaders keep in mind that the standard operating mode for the virtual

2
machines is rather atypical for physical machines owned by mechanism, named Snapshot, which became the key feature
ordinary users. In such a mode the system does not sleep and of our Amaranth project.
rarely reboots. When working in this mode, there is no need to The Snapshot mechanism works similar to the Apple Secure
emulate sleep states, which can be disabled in the settings of Boot manifests, which represent a configuration file contain-
the virtual machine. This measure allows us to reduce security ing: checksums of the files of critical importance to the boot
threats coming from the S3 resume boot-script. process of an operating system, the minimum version of the
The absence of additional devices (such as Intel ME / AMT) platform API (if the firmware is too old, boot is prohibited),
for virtual machines or the ability to disable them in the a set of rules that impose restrictions on the contents of some
settings (as in the case of Option ROM) also simplifies the directories.
task of developing a secure firmware and reduces the threat While Apple’s manifest is a file that is stored together
of DMA attacks. with the bootloader, in case of Amaranth, configuration
In the settings of the virtual machine, one can disable the file becomes part of the firmware. Unlike Apple, we also
ability to write to SPI flash memory and thereby get rid of cannot guarantee that the Windows or Linux bootloader will
the need to configure flash memory protection mechanisms not try to use any unverified files, which means we have
(registers BIOS CNTL, PRx). Such configuration of a virtual to sign more files (calculate their checksums) and check
machine substantially weakens the probability of implants in directories for the absence of files of certain types in them,
the UEFI firmware. since loaders most often do not check anyhow the code they
We could also turn off the SMM support in the virtual load. If the checksums do not match or directory contents
machine configurations and, consequently, reduce the security are inappropriate, the system will not be allowed to boot. As
threats caused by the SMM, as we developed our own OS long as the configuration file is managed by the host operating
integrity checking mechanism, which we used instead of the system and therefore comes from a trusted source, there is no
UEFI Secure Boot. The UEFI Secure Boot is the only reason need to implement any signature checking. However, if this
one would need to emulate the SMM in virtual machines and mechanism is ported to real hardware, the situation will have
as we managed to dispose the UEFI Secure Boot, we could to change.
also leave out the SMM. This approach could have been made better if the operating
Furthermore, the firmware update responsibility is handed systems cooperated with the process, for example, by using the
over to the hypervisor, running these machines. Taking into standard UEFI mechanisms to access the file system. This way
account all these simplifications, the resulting firmware state the requests could be intercepted and checked whether the file
machine can look like one, depicted in Fig. 1. is present in the configuration and thus trusted. Unfortunately
it is not the case for the official Windows bootloader, which
uses its own NTFS-driver, forcing us to run additional checks
in the firmware. While this is not the only possible solution as
we could have used some other Windows loader (for example,
Quibble [25]), which file system requests could be intercepted
in a standard way, ensuring the security and compatibility of
such a loader is non-trivial.
Apart from the need to maintain data integrity from the
external code, implemented with the Snapshot mechanism, it
should be understood that there is a need to protect a fair
amount of code in the firmware itself, which comes from
different parties. Obviously, all modern development tools for
mission-critical software should always be used during the de-
Fig. 1. Virtual machine flash storage structure corresponding to the firmware velopment of such a product. We performed formal verification
state machine. of the PE loader with the AstraVer toolset [28], fuzzed critical
parsing code parts, such as firmware configuration handling
We started the development of a secure firmware from the code, and ran static analysis with Svace [31]. To further
minimisation of the interface between the firmware and the reduce the risks of bugs residing in the codebase without
user (both a person and an operating system). To do so, we our knowledge we created a hardened operating environment
took the open-source reference implementation of the UEFI with the support for memory protection, stack canaries, stack
firmware for virtual machines – OVMF [5] and removed overflow guards, and automatic variable initialisation.
several redundant features from its code such as a complex
graphical user interface, network transfer protocol support, IV. S NAPSHOT MECHANISM ARCHITECTURE
as well as various unsafe ways of finding and restoring the Before we describe the main security mechanism of Ama-
operating system (for example, booting from a USB flash ranth firmware in greater detail, it seems reasonable to explain
drive). As a replacement for the UEFI Secure Boot, we de- the necessity of it in comparison with other integrity checking
veloped a prototype of an operating system integrity checking mechanisms. It must be noted that any attempt to pass the

3
responsibility of checking the integrity of the booted OS to 2) Partition N type Globally Unique Identifier (Partition-
the OS itself breaks the security chain, as only the code we TypeGUID).
already trust can check the code we do not trust yet. For 3) Partition N Globally Unique Identifier (UniqueParti-
this reason UEFI Secure Boot was created. This technology is tionGUID).
supposed to authenticate UEFI images, such as an OS loader 4) Path to a file (partN rules.txt) containing a set of rules
or an option ROM and it is the only link in a chain of describing the partition N contents. An example of such
trust. Thus in case of UEFI Secure Boot the overall security a description is shown in Listing 1.
of the system depends on the OS loader, and if it can not
be trusted (section II, 4th security issue), one will have to Listing 1. An example of partN rules.txt file.
sign all the system critical files and store them in SPI flash #WR
C:\Program Files\Common Files\System\msadc
memory along with the firmware, using mechanisms provided
*.dll
by UEFI Secure Boot. Not taking into the account other design *.inc
decisions (section II, 5th security issue) UEFI Secure Boot *.reg
ru-RU\*.dll.mui
was designed to authenticate several bootloaders and option #BN
ROMs, not a huge amount of system files, what resulted in C:\Windows\Boot\PCAT
overhead of 24 bytes per entry (WIN CERTIFICATE), where DtcInstall.log
certificate type and hash algorithm must be specified. These
This file describes the contents of the partition by listing
certificates are stored as authenticated UEFI variables in the
valid or invalid file names relatively to the base directory. The
SPI flash memory, thus the correctness of UEFI Secure Boot
full path to the base directory is specified in the line following
depends on the SPI flash memory protection mechanisms
the line of flags. A line of flags begins with the special
(section II, 6th security issue) and on the signature databases
character #, followed by a sequence of letters describing the
updating procedures. Section 32.5.1 of UEFI specification
contents of the base directory. There are 4 allowed flags:
[1] states that “signature databases may be updated by the
firmware, by a pre-OS application or by an OS application • W – indicates a list of valid files (whitelist).
or driver”. But leaving signature databases updates to guest • B – indicates a list of invalid files (blacklist).
OS application or driver can hardly be regarded as a wise • R – the lines following the line of the base directory up
decision (section II, 2nd security issue). Nevertheless even if to the next line of flags or the end of the file are regular
these databases are updated by firmware, it turns out that expressions (written relative to the base directory).
firmware from different vendors broadly reuse code from • N – the lines following the line of the base directory up
open source reference UEFI implementation [4] and that the to the next line of flags or the end of the file are ordinary
implementation (OVMF [5]) uses SMM in UEFI variable file names (written relative to the base directory).
driver stack (section II, 7th security issue). Taking into account The contents of each base directory can be described only
all the aforementioned considerations we decided to develop once. The regular expression syntax is extremely simple and
our own integrity checking mechanism (Snapshot). contains only 2 control sequences:
Checking disk partitions and specific directories within • ? – denotes one arbitrary but valid character;
them for the absence (presence) of files of a certain type is • ? – denotes an arbitrary number of such characters.
implemented in Amaranth with the help of a set of entries
Valid characters are those that can be used in file names.
stored in a configuration file. Each entry includes a full path
When the platform starts, the compliance of the OS state
to the base directory, a set of regular expressions describing
with the configuration file, the structure of which is shown in
the contents of the base directory, and a flag indicating whether
Listing 2, is checked by a special library firmware module,
the set of files described by the regular expressions is valid or
which has been designed taking into account critical security
not.
requirements. Despite the importance of these requirements,
A small utility named Snapshot was written to create the they are often neglected [28]. When applied to the configura-
firmware configuration files. This program takes text files tion file parser, the security requirements are quite simple:
for input, with each file containing a set of full paths to
critical files within a single disk partition or a set of rules 1) When one passes any structure to a function, one should
describing the contents of required directories within the same always pass not only a pointer to this structure, but also
partition. Upon obtaining all the necessary information, the its size. This allows one to make elementary checks
utility generates a binary file, which the user can then place inside the function, that any pointers (i.e. offsets relative
into the firmware and secure the operating system state at boot to the beginning of the binary file) inside this structure
time. To create a configuration file, the Snapshot utility needs do not point outside the memory allocated for this
multiple sets of 4 arguments, each one describing a single disk structure.
partition. These arguments are: 2) All address arithmetic operations must be performed
taking into account the possibility of overflow. If such
1) Path to a file (partN files.txt) containing a set of lines a situation occurs, an error must be reported and the
with full file paths, which hashes are to be computed. system must not be allowed to boot.

4
3) Upon completion of its execution, each function must } SS_STORAGE_ACL;
return the status of the operation it performed, so that
/**
no error could be left unnoticed. Storage partition describing one storage and
4) Files being checked for validity should be read into the its files.
buffer only once, and all the checks should be performed **/
typedef struct {
over this buffer only, in order to eliminate the possibility EFI_GUID PartitionTypeGUID;
of TOCTOU attacks (Time-of-check/Time-of-use). EFI_GUID UniquePartitionGUID;
UINT32 NumberOfAclRules;
Listing 2. Configuration file structure UINT32 AclRuleOffset;
/** UINT32 NumberOfFiles;
Storage magic. SS_STORAGE_FILE Files[];
} SS_STORAGE_PARTITION;
**/
#define SS_STORAGE_MAGIC SIGN_32 (’S’, ’S’, ’O’, ’H’)
/**
/** Storage set describing all the partitions
Storage version. in the configuration.
**/ **/
#define SS_STORAGE_VERSION 0x10010000U typedef struct {
UINT32 Magic;
/** UINT32 Version;
No boot partition index. UINT32 BootPartitionIndex;
UINT32 BooterFileOffset;
**/
#define SS_BOOT_PARTITION_UNUSED MAX_UINT32 UINT32 NumberOfPartitions;
UINT32 Partitions[];
/** } SS_STORAGE_SET;
File entry describing one file and its hash.
The configured firmware runs as follows: after the success-
All the files are alphabetically-sorted, ful completion of the SEC, PEI and DXE stages, the firmware
thus binary searching can be used to access files.
proceeds to the execution of the stage called Boot Device
Offset must point within the binary blob. Selection (BDS), at the end of which the BdsSnapshotDe-
**/ viceSelect() function is called, which passes the control to the
typedef struct {
UINT32 Offset; configuration file parser. First of all, the parser checks, that the
UINT8 Hash[SHA384_DIGEST_SIZE]; given file is indeed a configuration file by comparing the values
} SS_STORAGE_FILE; of the Magic and Version fields of the SS STORAGE SET
/** structure with the expected values. Further, the parser makes
Rules described in ACL contain a whitelist sure that the index of the disk partition in which the OS loader
when the bit flag is set and blacklist is stored (BootPartitionIndex) does not exceed the total number
when the bit flag is not set.
**/ of partitions (NumberOfPartitions).
#define ACL_FLAG_WHITELIST BIT0 On the next step the parser checks each disk partition. In-
/**
formation about partitions is stored in the configuration file as
Rules described in ACL contain regular expressions an array of SS STORAGE PARTITION structures. At first the
instead of raw strings. Currently supported format: parser checks, that different partitions on the disk do not have
- ? stands for any ASCII character. the same non-zero identifiers (UniquePartitionGUID). Then it
- * stands for any amount of ASCII characters.
**/ compares the contents of each partition with specifications in
#define ACL_FLAG_REGEX BIT1 the configuration file, namely: the parser makes sure, that the
/**
partition type matches the expected one (PartitionTypeGUID);
Access control rule is a rule describing after that the parser compares checksums of each of Num-
restrictions imposed on a directory berOfFiles files on the disk with those stored in configuration
referred by the rule. The rule can be viewed file as an array of SS STORAGE FILE structures, each con-
as a way to whitelist or blacklist directory
contents without explicitly checking file contents. taining 2 fields:
• offset from the beginning of the configuration file, which
This can be used to protect directories from
having new malicious files added in blacklist points at a string containing a full file name (+ end-of-line
or whitelist modes: character);
- Blacklist mode forbids the files
• a checksum of the file (Hash[SHA384 DIGEST SIZE]).
that can be matched by any rule
- Whitelist mode restricts the files to only those On the third step, the entire file system of the disk partition
that can be matched by any rule.
**/
is checked for compliance with each of NumberOfAclRules
typedef struct { rules, which impose restrictions on the types of files located
UINT32 Flags; in certain directories, and which are stored in the configuration
UINT32 DirectoryOffset;
UINT32 NumberOfRules; file as an array of SS STORAGE ACL structures. Each of these
UINT32 Rules[]; structures contains a set of fields:

5
 • an offset from the beginning of the configuration file one million checksums for messages, lengths of which are
(DirectoryOffset), which points at a line with a full name given in bytes. The time increase at 112 bytes is due to the
of the directory (+ end-of-line character), on the contents fact that the checksum is calculated for a padded message.
of which restrictions are imposed; On one of its steps the padding algorithm adds k zeros to
• an array of NumberOfRules lines, that are stored in the the original message. k is determined as the smallest non-
configuration file at the offsets specified in Rules[ ]; negative solution of the equation l + 1 + k ≡ 896 mod 1024,
• another field (Flags) contains a set of flags, which allows where l is the length of the original message in bits. Thus,
to interpret this array of strings. if l = 112 × 8 = 896, then k = 1023, which doubles the
Lines in the Rules[ ] array can contain either relative file length of the message being hashed compared to the case when
names or regular expressions. Both file names and regu- l = 104 × 8 = 832 and k = 63.
lar expressions are written relative to the base directory
(DirectoryOffset). What exactly is stored in the Rules[ ]
lines is determined by the ACL FLAG REGEX flag. The
ACL FLAG WHITELIST flag allows the parser to determine,
whether filenames matching the Rules[ ] are valid for the base
directory or, on the opposite, not allowed.
If all the checks complete successfully, the parser passes
the control to the bootloader, which location is determined
by BootPartitionIndex and a full file name (BooterFileOffset)
within this partition. If any discrepancy is found between the
contents of the disk and the configuration file, an error is
reported and the system is not allowed to start.
As it was mentioned earlier, the configuration file contains
checksums of files, that are important to the operating system
boot process. As there can be quite a lot of such files, it is Fig. 2. Dependence of the checksum calculation time on the size of the
reasonable to speed up the process of checksum calculations message being hashed.
in the firmware. For this purpose, the SHA384 algorithm was
implemented in the firmware, which uses the AVX (Advanced In order to increase robustness of the configuration files
Vector Extensions) command extension for x86 platforms firmware parser, fuzzing was conducted with the help of
to accelerate calculations at the hardware level [26], [27]. libFuzzer [29] library. The main difficulty in carrying out such
Acceleration is achieved as follows: testing was the preparation of a UEFI-compatible environment
in the user space of the operating system, i.e. we needed
• Xmm registers are used, with which one can perform functions, that would emulate the behavior of the platform
operations on two 8-byte words at a time. on which the firmware was running. So as to emulate the
• During checksum calculations cyclic permutations of 8- UEFI environment, a small utility from the OpenCore [30]
byte words of the intermediate result are done. In order project was used, which simplified the preparations to fuzzing
not to copy words from one register to another, virtual and reduced them to writing code, repeating the logics of the
registers are used instead (registers’ aliases are provided configuration file parser.
to the assembler instructions), what allows us to simply
rename them and spare some instructions. V. C ONCLUSION
• Since the basic calculations of the SHA384 algorithm can This paper introduced Amaranth, a project which aims to
be split into two subtasks, one of which is performed ex- develop a secure UEFI firmware for virtual machines. The
clusively on Xmm registers, and the other – exclusively on implemented solution for virtual machines running on the
general-purpose registers; to speed up the algorithm as a QEMU emulator includes:
whole, Xmm instructions can be interleaved with general- • a minimised interface between the firmware and the user
purpose instructions in a ratio of 1 to 2 and thus, one can (both a person and an operating system);
take advantage of the hardware parallelism of execution • a prototype of an operating system integrity checking
of vector instructions and general-purpose instructions mechanism implemented as a firmware library module
inside Intel processors (because on average it takes 2 based on the SHA384 hashing algorithm optimised with
clock cycles to execute a single vector instruction). the AVX (Advanced Vector Extensions) command exten-
As can be seen in Fig. 2, the use of aforementioned ideas sions for x86 platforms to accelerate calculations on the
allows to reduce the time of checksum calculation by 35%. hardware level;
The measurements were made on one Intel (R) Core (TM) • a hardened operating environment that supports some of
i5-3337U 1.80GHz processor (1 core), QEMU emulated the the latest security practices including memory protection,
Standard PC (Q35 + ICH9, 2009) chipset with 2GiB RAM. stack overflow guards, stack canaries, and automatic
The graph shows the time in milliseconds taken to compute variable initialisation;

6
 • the use of modern development tools for mission-critical [9] Trammell Hudson: Thunderstrike. [Online].
software such as formal verification (PE loader [28]), Available: https://trmm.net/Thunderstrike 31c3/
[10] Dong Wang and Wei Yu Dong: Attacking Intel UEFI by Using Cache
fuzzing (parser of firmware configuration files), and static Poisoning. 2019 J. Phys.: Conf. Ser. 1187 042072
analysis (Svace [31]); [11] John Butterworth, Corey Kallenberg, Xeno Kovah, Amy Herzog: BIOS
• the support for booting both Windows (from 7 to 10) and Chronomancy: Fixing the Core Root of Trust for Measurement. [Online].
Available: https://www.mitre.org/sites/default/files/publications/bios-
Linux operating systems, with the ability to bypass the chronomancy.pdf
GRUB boot loader for the latter, on x86 and x86 64; [12] Shawn Embleton, Sherri Sparks, Cliff C. Zou: SMM rootkit: a new breed
• utility code to create firmware configuration files on all of OS independent malware. Security Comm. Networks (2010)
[13] Corey Kallenberg, John Butterworth, Xeno Kovah, Sam
major desktop operating systems. Cornwell: Defeating Signed BIOS Enforcement. [Online]. Available:
The proposed set of tools of the Amaranth project allows https://www.mitre.org/sites/default/files/publications/defeating-signed-
bios-enforcement.pdf
one to substantially reduce the following threats: [14] ESET: LOJAX: First UEFI rootkit found in the wild, courtesy of the
• UEFI firmware implants, which may appear after soft- Sednit group. [Online]. Available: https://www.welivesecurity.com/wp-
ware reboots of the OS, bypassing the hypervisor. content/uploads/2018/09/ESET-LoJax.pdf
[15] Eclypsium: There’s a Hole in the Boot. [Online]. Available:
• OS bootloader modifications, as well as the alternation https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
of files it depends on in the boot process (in the same [16] Maxim Goryachy, Mark Ermolov: Where there’s a JTAG, there’s a way:
reboot scenario). obtaining full system access via USB. [Online]. Available: https://
www.ptsecurity.com/ww-en/analytics/where-theres-a-jtag-theres-a-way/
• Privilege escalation caused by the exploitation of the [17] Xeno Kovah, Corey Kallenberg, John Butterworth, Sam Corn-
vulnerabilities in firmware runtime services (e.g. over well: SENTER Sandman: Using Intel TXT to Attack BIOSes.
SMM or through non-volatile variable access). [Online]. Available: http://conference.hitb.org/hitbsecconf2014kul/wp-
content/uploads/2014/08/HITB2014KUL-SENTER-Sandman.pdf
Designing all the security measures as a part of the UEFI [18] Corey Kallenberg, Xeno Kovah, John Butterworth, Sam Cornwell:
firmware makes the approach highly portable. For this reason Extreme Privilege Escalation On Windows 8/UEFI Systems. [Online].
Available: https://paper.bobylive.com/Meeting Papers/BlackHat/USA-
we plan to continue to develop Amaranth with the existing 2014/us-14-Kallenberg-Extreme-Privilege-Escalation-On-Windows8-
and new security measures for UEFI-compatible workstations UEFI-Systems-WP.pdf
and embedded devices as well. [19] Rafal Wojtczuk, Joanna Rutkowska: Attacking SMM Memory via Intel
CPU Cache Poisoning. [Online]. Available: https://invisiblethingslab.com/
ACKNOWLEDGEMENTS resources/misc09/smm cache fun.pdf
[20] The Intel Converged Security and Management Engine IOMMU Hard-
We would like to thank our colleagues in the ISP RAS ware Issue – CVE-2019-0090 and CVE-2020-0566, [Online]. Available:
Linux Verification Center, Alexey Khoroshilov and Evgeniy https://www.intel.com/content/dam/www/public/us/en/security-advisory/
documents/cve-2019-0090-whitepaper.pdf
Baskov in particular, for their aid on the operating system [21] Rafal Wojtczuk, Corey Kallenberg: Attacking UEFI Boot Script. [On-
side. We would also like to thank Marvin Häuser from from line]. Available: https://bromiumlabs.files.wordpress.com/2015/01/
University of Kaiserslautern for his incredible contributions venamis whitepaper.pdf
[22] Dmytro Oleksiuk: Exploiting UEFI boot script table vulnerability.
into the EDK II and our firmware. [Online]. Available: http://blog.cr4.sh/2015/02/exploiting-uefi-boot-script-
table.html
R EFERENCES [23] Mark Ermolov, Maxim Goryachy: How to hack a turned-off
computer, or running unsigned code in Intel ME. [Online]. Available:
[1] UEFI Specification, UEFI Platform Initialization Specification [Online].
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-
Available: https://uefi.org/specifications
To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-
[2] David Cooper, William Polk, Andrew Regenscheid, Murugiah Souppaya:
Management-Engine-wp.pdf
NIST SP 800-147: BIOS Protection Guidelines. [Online]. Available:
[24] Dmitriy Evdokimov: Intel AMT vulnerability. Life after CVE-2017-5689.
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
[Online]. Available: https://www.blackhat.com/docs/us-17/thursday/us-
147.pdf
17-Evdokimov-Intel-AMT-Stealth-Breakthrough-wp.pdf
[3] Andrew Regenscheid: NIST SP 800-193: Platform Firmware Resiliency
[25] Quibble. [Online]. Available: https://github.com/maharmstone/quibble
Guidelines. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/
[26] Jim Guilford, David Cote, Vinodh GopalFast: SHA512 Imple-
SpecialPublications/NIST.SP.800-193.pdf
mentations on Intel Architecture Processors [Online]. Available:
[4] Jake Christensen, Ionut Mugurel Anghel, Rob Taglang, Mihai Chiroiu,
https://www.intel.com/content/dam/www/public/us/en/documents/
Radu Sion: DECAF: Automatic, Adaptive De-bloating and Hardening
white-papers/fast-sha512-implementations-ia-processors-paper.pdf
of COTS Firmware. In: 29th USENIX Security Symposium, USENIX
[27] FIPS PUB 180-4, Secure Hash Standard (SHS). [Online]. Available:
Security 2020.
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
[5] EDK II Project. [Online]. Available: https://github.com/tianocore/edk2
[28] Marvin Häuser, Vitaly Cheptsov: Securing the EDK II Image Loader,
[6] Xeno Kovah, Corey Kallenberg: How Many Million BIOSes Would you
2020 Ivannikov Ispras Open Conference (ISPRAS), 2020, pp. 16-25.
Like to Infect? [Online]. Available: http://legbacore.com/Research files/
[29] libFuzzer. [Online]. Available: https://llvm.org/docs/LibFuzzer.html
HowManyMillionBIOSesWouldYouLikeToInfect Whitepaper v1.pdf
[30] OpenCore. [Online]. Available: https://github.com/acidanthera/
[7] Corey Kallenberg, Sam Cornwell, Xeno Kovah, John Butterworth: Setup
OpenCorePkg/tree/master/User
For Failure: Defeating Secure Boot. [Online]. Available: https://infocon.
[31] Ivannikov V., Belevantsev Andrey, Borodin A.E., Ignatiev V., Zhurikhin
org/cons/SyScan/SyScan%202014%20Singapore/-SyScan%202014%20
D., Avetisyan Arutyun. (2014). Static analyzer Svace for finding defects
presentations/SyScan2014 CoreyKallenberg SetupforFailureDefeating
in a source program code. Programming and Computer Software. 40.
SecureBoot WP.pdf
265-275.
[8] Loukas K.: DE MYSTERIIS DOM JOBSIVS Mac EFI Rootkits. Black Hat
USA 2012 [Online]. Available: http://ho.ax/De Mysteriis Dom Jobsivs
Black Hat Paper.pdf