\HeadingLevelB{Software Attacks on Peripherals}
\label{sec:device_attacks}

Threat models for secure architectures generally only consider software attacks that directly target other components in the software stack running on the CPU.
This assumption results in security arguments with the very desirable property of not depending on implementation details, such as the structure of the motherboard hosting the processor package.

The threat models mentioned above must classify attacks mounted via motherboard components other than the CPU as physical attacks.
Unfortunately, these models miscategorize the attacks described in this section, which can be carried out solely by executing software on the victim processor.
The incorrect classification matters a great deal in cloud computing scenarios, where physical attacks often deemed out of scope as prohibitively expensive to carry out.

By way of specific example, this section discusses attacks primarily in the context of Intel's Core processors, which at the time of publication are by far the most widely available processor systems in their class, and offer a well-studied target for type of attack.

\HeadingLevelC{PCI Express Attacks}
\label{sec:pcie_attacks}

The PCIe bus~(\S~\ref{sec:motherboard}) allows any device connected to the bus to perform \textit{Direct Memory Access}~(DMA), reading from and writing to blocks of addresses in the computer's DRAM without the involvement of a CPU core.
Each device is assigned a range of DRAM addresses via a standard PCI configuration mechanism, but can perform DMA on DRAM addresses outside of that range.

Without any additional protection mechanisms, an attacker who compromises system software can take advantage of programmable devices to access any DRAM region, yielding capabilities that were traditionally associated with a DRAM bus tap.
For example, an early implementation of Intel TXT~\citep{grawrock2009txt} was compromised by programming a PCIe network interface card (NIC) to read TXT-reserved DRAM via DMA transfers~\citep{wojtczuk2011txt}.
Recent versions have addressed this attack by adding extra security checks in the DMA bus arbiter.
\S~\ref{sec:sgx_related_intel_txt} provides a more detailed description of Intel's TXT.


\HeadingLevelC{DRAM Attacks}
\label{sec:rowhammer_attack}

The rowhammer DRAM bit-flipping attack~\citep{kim2014rowhammer, google2015rowhammer, gruss2015rowhammer} is an example of a different class of software attacks that exploit design defects in the computer's hardware.
Rowhammer took advantage of the fact that some mobile DRAM devices~(\S~\ref{sec:motherboard}) refreshed the DRAM's contents slowly enough that repeatedly changing the contents of a memory cell could impact the charge stored in a neighboring cell, which resulted in changing the bit value obtained from reading the cell.
By carefully targeting specific memory addresses, the attackers caused bit flips in the page tables used by the CPU's address translation (\S~\ref{sec:paging}) mechanism, and in other data structures used to make security decisions.

The defect exploited by the rowhammer attack most likely stems from an unfortunate and incorrect design assumption.
The DRAM engineers likely only considered non-malicious software and assumed that an individual DRAM cell is not often accessed, as repeated accesses to the same memory address would be absorbed by the CPU's caches (\S~\ref{sec:caching}).
However, malicious software can take advantage of the \texttt{CLFLUSH} instruction, which flushes the cache line that contains a given DRAM address.
\texttt{CLFLUSH} is intended as a method for applications to extract more performance out of the cache hierarchy, and is therefore available to software running at all privilege levels.
Rowhammer exploited the combination of \texttt{CLFLUSH}'s availability and the DRAM engineers' incorrect assumptions, to obtain capabilities that are normally associated with an active DRAM bus attack.


\HeadingLevelC{The Performance Monitoring Side Channel}
\label{sec:perfmon_attacks}

% On Die Digital Thermal Sensors: SDM S 14.7.5

Intel's \textit{Software Development Manual}~(SDM)~\citep{intel2015sdm} and Optimization Reference Manual~\citep{intel2014optimization} describe a vast array of performance monitoring events exposed by recent Intel processors, such as branch mispredictions (\S~\ref{sec:out_of_order}).
The SDM also describes digital temperature sensors embedded in each CPU core, whose readings are exposed using Model-Specific Registers~(MSRs)~(\S~\ref{sec:address_spaces}) that can be read by system software.

An attacker able to compromise a computer's system software and gain access to the performance monitoring events or the temperature sensors can obtain the information needed to carry out a power analysis attack, which normally requires physical access to the victim computer and specialized equipment.
Simpler yet, the attacker may learn private information from various performance counters affected by the victim's execution.

\HeadingLevelC{Attacks on the Boot Firmware and Intel ME}
\label{sec:firmware_attacks}

Virtually all motherboards store the firmware used to boot the computer in a flash memory module (\S~\ref{sec:motherboard}) that can be written by system software.
This implementation strategy provides an inexpensive avenue for deploying firmware bug fixes.
On the other hand, an attack that compromises the system software can subvert the firmware update mechanism to inject malicious code into the platform firmware.
The malicious code can be used to carry out a cold boot attack, which is typically considered a physical attack.
Furthermore, malicious firmware can execute code at the highest software privilege level, System Management Mode (SMM, \S~\ref{sec:rings}).
Last, malicious firmware can modify the system software as it is loaded during the boot process.
These avenues give the attacker many capabilities that have traditionally been associated with DRAM bus tapping attacks.

The Intel Management Engine (ME)~\citep{ruan2014intelme} loads its firmware from the same flash memory module as the main computer, which opens up the possibility of compromising its firmware.
Due to the vast management capabilities (\S~\ref{sec:intel_me}) of a ME, if compromised, it would offer an attacker similar capabilities to active probes on the DRAM bus, the PCI bus, and the System Management bus (SMBus), as well as a wealth of power meters.
Thanks to its direct access to the motherboard's Ethernet PHY, the probe would be able to communicate with the attacker while the computer is in the Soft-Off state, also known as S5, where the computer is mostly powered off, but is still connected to a power source.
The ME has significantly less computational power than probe equipment, however, as it uses low-power embedded components, such as a 200-400MHz execution core, and about 600KB of internal RAM.

The computer and ME firmware are protected by a few security measures.
The first line of defense is a security check in the firmware's update service, which only accepts firmware updates that have been digitally signed by a manufacturer key that is hard-coded in the firmware.
This protection can be circumvented with relative ease by foregoing the firmware's update services, and instead accessing the flash memory chip directly, via the PCH's SPI bus controller.

The deeper, more powerful, lines of defense against firmware attacks are rooted in the CPU and ME's hardware.
The bootloader in the ME's ROM will only load flash firmware that contains a correct signature generated by a specific Intel RSA key.
The ME's boot ROM contains the SHA-256 cryptographic hash of the RSA public key, and uses it to validate the full Intel public key stored in the signature.
Similarly, the microcode bootstrap process in recent CPUs will only execute firmware in an Authenticated Code Module (ACM, \S~\ref{sec:uefi_sec_details}) signed by an Intel key whose SHA-256 hash is hard-coded in the microcode ROM.

However, both the computer firmware security checks \citep{wojtczuk2010bios, furtak2014bios} and the ME security checks \citep{tereshkin2009amt} have been subverted in the past.
While the approaches described above are theoretically sound, the intricate details and complex interactions in Intel-based systems make it very likely that security vulnerabilities creep into implementations.
Further proving this point, a security analysis~\citep{ververis2010security} found that early versions of Intel's
Active Management Technology~(AMT), the flagship ME application, contained assorted of security issues that allowed an attacker to completely take over a computer whose ME firmware contained the AMT application.


\HeadingLevelC{Software Attacks on Peripheral Devices}

The attacks described in this section show that a system whose threat model assumes no physical access attacks must be designed with an understanding of all of the system's buses, and the programmable devices that may be attached to them.
The system's security analysis must argue that the devices cannot be used in physical-like attacks.
The argument will rely on barriers that prevent untrusted software running on the CPU from communicating with other programmable devices, and on barriers that prevent compromised programmable devices from tampering with sensitive buses or DRAM.

Unfortunately, at the time of publication, the ME, PCH and DMI are proprietary in Intel's processors and remain largely undocumented. We therefore cannot assess the security of the measures set in place to protect the ME from compromise, and we cannot rigorously reason about the impact of a compromised ME on the security of a computer system.
