article_acpi.pdf

(167 KB) Pobierz
ACPI: Design Principles and Concerns
Lo¨ Duflot, Olivier Levillain, and Benjamin Morin
ıc
DCSSI 51 bd. de la Tour Maubourg 75700 Paris Cedex 07 France
Abstract.
ACPI (Advanced Configuration Power Interface) allows op-
erating systems to efficiently configure the hardware platform they are
running on and deal with power management tasks. These tasks used to
be achieved by the BIOS because it was the only platform component
to know which specific chipset or device registers dealt with power man-
agement. In this paper, we illustrate how this shift in the global power
management model introduces additional threats, especially for trusted
platforms, by showing how rootkits can use ACPI to conceal some of
their functions. We also study the relationship between trusted comput-
ing blocks and ACPI.
Keywords:
ACPI, trusted platforms, rootkits.
1
Introduction
ACPI (Advanced Configuration and Power Interface) [8] was specified by Intel ,
Hewlett-Packard, Microsoft , Phoenix and Toshiba to establish common in-
terfaces for platform-independent configuration and power management. In the
ACPI model, the OSPM (Operating System-directed configuration and Power
Management) is the specific operating system component in charge of power
management tasks. ACPI has been widely accepted as a de-facto standard to
replace the former APM [16] (Advanced Power Management) approach, where
power management was mostly performed by the BIOS. Pushing power man-
agement at the operating system level allows more flexibility and more complex
power management schemes. However, operating systems are generic objects by
nature, so the hardware platform must provide the operating system with some
means of understanding how power management should be achieved on this
specific platform. This is the purpose of the ACPI tables.
On a trusted platform, the trusted computing base is generally in charge of
power management. If the trusted computing base is to run on several platforms,
then it must make use of the ACPI tables provided by the BIOS. In this paper,
we try to determine whether the trusted computing base can trust the ACPI
tables, or if there is a way for an attacker to modify those tables as a means for
privilege escalation on a platform, and what would be the impact of a bug in
one of the ACPI tables.
It is well understood in the industrial world that ACPI is one of the most com-
plex components to deal with from a security perspective on a trusted platform
(along with System Management Mode for instance). During the 2006 Blackhat
L. Chen, C.J. Mitchell, and A. Martin (Eds.): Trust 2009, LNCS 5471, pp. 14–28, 2009.
c Springer-Verlag Berlin Heidelberg 2009
ACPI: Design Principles and Concerns
15
forum, John Heasman [6] presented how it is possible to design an ACPI-based
rootkit. However, to our best knowledge, our paper is one of the first attempt to
study the initial design flaws and to present a comprehensive proof-of-concept
of an ACPI rootkit-like function that can be triggered by external hardware
events (laptop lid opening, power adapter plugged and removed twice in a row
for instance).
In section 2, we present the way ACPI works on a traditional computer and
show how ACPI is handled on a Linux system. Section 3 gives a description of
the flaws in the ACPI model that make it possible for an attacker to use ACPI
to conceal rootkit functions. In section 4, we present an actual proof-of-concept
of an ACPI rogue code that allows an attacker to install a remanent backdoor on
a Linux-based laptop that will be triggered when the power adapter is plugged
and unplugged twice in a row. In section 5, we describe how the problem can be
handled on so-called trusted platforms. Section 6 concludes the paper.
2
ACPI Design Principles
For the sake of simplicity, we only consider in this paper traditional x86 and
BIOS-based computer platforms.
2.1
Traditional PC Architecture
Figure 1 shows a traditional PC architecture. User code (trusted computing
bases, operating systems, applications) run on the CPU [10]. The chipset com-
ponent is in charge of hardware devices management. The northbridge [9] part
of the chipset is connected to main system memory (RAM) and to the graphic
adapter. The southbridge [14] part of the chipset is connected to other devices
(network interface controller, sound device, USB devices) through various com-
munication buses. Power management of a device is achieved at the hardware
level by modifying the content of configuration registers hosted by the chipset
(northbridge, southbridge or both depending on the device) and in the device
itself. Those registers can be accessed from the CPU using several different mech-
anisms [13]:
–
some registers are mapped by the chipset into the main system memory
space. Those so-called Memory-Mapped I/O registers can thus be accessed
by the CPU in the same way as RAM is, but at different addresses;
–
some registers are mapped into a separate 16-bit bus. These registers are
called Programmed I/O (PIO) registers. They are given an address in the
PIO space and can be accessed from the CPU using “in” [11] and “out” [12]
assembly langage instructions;
–
the chipset can also choose to map configuration registers into the PCI con-
figuration space [17]. One way to access those registers is to use two dedicated
PIO registers, 0xcf8 and 0xcfc, by specifying the PCI address of the register
(composed of a bus number, a device number, a function index and an offset)
16
L. Duflot, O. Levillain, and B. Morin
PCI Express bus
Graphic
adapter
CPU
Chipset
Northbridge
RAM
PCI devices
Southbridge
TPM
PCI bus
LPC bus
USB bus
USB devices
IDE, SATA
Fig. 1.
Traditional PC architecture (example Pentium 4-based architecture)
in the 0xcf8 register and reading (resp. writing to) the 0xcfc register to read
(resp. write) the content of the PCI register.
2.2
ACPI Components
In the model, the chipset itself does not attempt to configure power management
registers. Configuration is actually initiated by software components running on
the CPU. At boot time, the BIOS is likely to configure the hardware, while op-
erating systems or trusted computing bases are in charge of power management
once the boot process is over.
In the ACPI model, the platform provides an ACPI BIOS, several ACPI
registers that are accessed for power management purpose (they can be either
Memory Mapped registers, Programmed I/O registers or PCI configuration reg-
isters), and ACPI tables that basically specify how ACPI registers should be
accessed.
ACPI tables have different types and purposes:
–
the Root System Description Table (RSDT) contains a set of pointers to
the other tables. The address of the RSDT is provided by the Root System
Description Pointer (RSDP), which must be stored in the Extended BIOS
Data Area (EBDA), or in the BIOS read-only memory space. The OSPM
will only locate the RSDP by searching for a particular magic number (the
RSDP signature) that the RSDP is required to begin with;
–
the Differentiated System Description Table (DSDT), the address of which
can be determined thanks to the pointer provided by the RSDT, contains
those methods that should be used by the component in charge of power
management and specifies how the power characteristics of the devices shall
be modified. The ACPI specification only defines the methods that are avail-
able for each device and their meaning. Actions defined in the methods are
ACPI: Design Principles and Concerns
17
machine-specific. The DSDT is written in AML (ACPI Machine Langage)
[8], which can be disassembled into a more comprehensible language, called
ASL (ACPI Specification Langage)[1];
–
many other tables are also provided, but for the sake of simplicity, we will
not give details on them.
ACPI does not standardise power management at the software level, but oper-
ating systems are advised to include the following components to perform power
management tasks:
–
an Operating System-directed configuration and Power Management com-
ponent (OSPM) running at the kernel level should be in charge of the overall
power management strategy;
–
an ACPI driver and AML interpreter should be used by the OSPM to execute
the contents of the methods specified in the DSDT;
–
device drivers should optionally make use of the AML interpreter to perform
power management independently of the OSPM.
ACPI components and their relationships with the kernel are summarized in
Figure 2.
2.3
DSDT Basic Structure
The DSDT describes those devices that support power management. Devices
are organized in packages in a tree-like structure. Several standardized packages
are located under the root (labelled
\)
of the tree, such as the
\_PR
Processor
tree package, which stores all CPU related objects and the
\_SB
System Bus
tree package, which stores all bus-related resources. PCI resources (e.g., PCI0,
PCI1) are located in the
\_SB
package. In turn, devices can be defined in other
devices’ subtrees. For instance, IDE or USB controllers can be accessed in the
tree below the PCI0 device; the path to the USB0 host controller on the DSDT
tree is thus
\_SB.PCI0.USB0.
Power management-related methods are the leaves
of the tree. For example, the method that allows the USB0 controller to transit
to the S5 power state is
\_SB.PCI0.USB0._S5.
Most method names are defined
in the ACPI standard, so that the OSPM knows which method to call. Example
of such standard methods are given in [8].
Power management basically works as follows: in response to some hardware-
triggered event, or based on its own policy, the OSPM can initiate a power
management-related action by executing the corresponding AML method in the
DSDT. For instance, in order to put one of the USB controller in the S5 power
state, the OSPM simply has to run the
\_SB.PCI0.USB0._S5
method.
2.4
ACPI Machine Language and ACPI Source Language
AML-written tables can be disassembled in ACPI source language (ASL) using
for instance the ACPIca tools [1]. The ASL language provides basic constructs in
18
L. Duflot, O. Levillain, and B. Morin
Software. Outside of the scopeof ACPI specifications
Applications
Kernel
OSPM
Device
drivers
AML
interpreter
ACPI
Provided by the platform
ACPI BIOS
ACPI
Registers
ACPI
Tables
Hardware devices
Fig. 2.
ACPI architecture
order to define ACPI registers and methods. Logical and arithmetic operations
on registers, branching instructions and loops are available. Special commands
are also available, like the
Notify()
command, which can be used by the OSPM
to send messages to other parts of the operating system. Section 2.5 shows how
Notify events are handled under Linux.
The ACPI registers are defined by the ASL
OperationRegion()
command.
Memory, PCI configuration and PIO spaces can be mapped as ACPI registers.
Different fields of each ACPI register can be given a name using the
Field()
command (see 2.5).
2.5
Use of ACPI in Practice: Linux Example
In this section, we study how ACPI is handled by an ACPI-compliant Linux
system. This will be useful as most of the examples we give in the next sections
will be related to Linux systems.
ACPI software in Linux is mostly composed of two different parts:
–
a kernel service which includes an AML interpreter, ACPI drivers for differ-
ent devices (e.g, fan, CPU, batteries) and part of the OSPM. The modular

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin