11

Upcoming Intel CPUs have TME, current AMD processors have SME.

These are full-memory encryption techniques to protect against physical attacks such as cold boot attacks.

Both support encrypting the entire RAM from boot so that software does not have to be modified to support them.

In combination with full-disk encryption and a TPM1 (which solves the boot key problem and can guarantee booting unmodified software all the way to unlocking the disk encryption without user input), this should allow operating and safely booting machines in fully untrusted environments without physical security (please correct me if this is wrong). The machine should either boot unmodified software, or refuse to boot; the encryption keys cannot be extracted at run-time due to the full-memory encryption.

It is unclear to me to what extent these techniques protect against DMA attacks. Usually, you can read the entire machine's memory directly via such an attack, e.g. by plugging into a PCIe port. If all memory is encrypted, then you can likely not.

  • How do devices like GPUs, which rely on DMA, even work in the presence of full-memory encryption?
  • Does using such a device spoil the benefits of full-memory encryption and thus safety without physical security?

Thanks!

1 Note conventional on-mainboard TPMs were susceptible to physical TPM reset attacks and bus spying attacks, but on the new processors mentioned above (such as AMD EPYC), the TPM is integrated into the processor die as it is part of AMD SPS or Intel ME respectively, so there "messing with the cables" should be very difficult.

nh2
  • 483
  • 3
  • 11
  • I'm certainly not an expert on memory encryption, but my guess is these types of protections are only designed to protect against software attacks as described in the AMD link you provided, not hardware attacks. To protect against hardware attacks, you'd need some kind of trusted hardware based system that exchanges keys in some secure way. (Like HDMI does). That would almost certainly be backwards incompatible with existing PCIe cards. – Steve Sether Jul 19 '18 at 15:55
  • DMA can read memory as though it were unencrypted, the mobo seemlessly decodes it on-the-fly' – dandavis Jul 19 '18 at 16:15
  • 1
    @SteveSether This depends on the kind of hardware attack you're talking about. There is no need to securely exchange a key since the key is created and managed by the chipset (presumably the MCH). There's no reason the RAM or PCIe devices themselves need access to the key. – forest Jul 20 '18 at 02:40
  • `please correct me if this is wrong` No, you are correct, though to be pedantic, it doesn't provide a trusted environment even without physical security. Rather, it reduces the components you need to trust all the way down to the TPM and CRTM (a typically read-only component of the BIOS). While it may protect you from an evil hard drive, option ROM, or even BIOS, it won't protect you from a malicious TPM or writable CRTM. Thankfully, TPMs are designed to be tamper-resistant... – forest Jul 20 '18 at 02:50
  • @forest Oops sorry, done! – nh2 Oct 22 '18 at 22:08

1 Answers1

11

How does memory encryption impact DMA attacks?

Full-memory encryption is not designed to protect against DMA attacks. That is what an IOMMU is for. The IOMMU is configured using a type of ACPI table for DMA Remapping, or DMAR. This table contains a list of regions used by each DMA-capable device connected to the PCH. The IOMMU will then restrict memory access to those regions and those regions only:

DMA Remapping

How do devices like GPUs, which rely on DMA, even work in the presence of full-memory encryption?

There are two techniques to support DMA. The first is to exploit the fact that memory accesses over PCIe still go over the PCH, meaning that the chipset has the opportunity to transparently encrypt and decrypt the DMA buffers. The other technique is simply to mark the pages used for DMA as unencrypted. The latter technique prevents DMA attacks, but it is likely that the former is implemented instead. The latter technique is more common for experimental software-based memory encryption such as vCage and HyperCrypt. This is not an issue at all, as I explain later.

According to the TME link you provided, a single exclusion range is supported where encryption is not supplied. This range is designed for things such as the BIOS (which has components loaded very low in the address range). Since it specifies that only a single range is supported, this means it cannot be used for DMA buffers as they are spread out among multiple ranges.

Also, you should be comparing TME with TSME, not SME. Regular SME only encrypts individual pages. TSME, on the other hand, behaves more like TME by transparently encrypting almost all system memory, making it unnecessary for software to explicitly support the feature.

Does using such a device spoil the benefits of full-memory encryption and thus safety without physical security?

Not at all! When memory encryption is in place, the data will be transparently decrypted and sent over the PCIe bus when the device requests it. This is actually not that different from memory scrambling, a technique to reduce di/dt on DRAM chips by encrypting memory with an algorithm called an LFSR. This algorithm is very weak, so it is not used for confidentiality, only to improve the reliability of hardware. TME and SME just takes this to another level, using hardware-accelerated encryption with a real, strong cipher instead of the weak LFSR algorithm.

As a bus gets faster and faster, successive bursts of 1s or 0s become very stressful on the device. This can cause severe, rowhammer-like interference (a single 0 in the burst of a million 1s will not be very happy). It can also cause power surges, as every capacitor that is charged needs to be recharged every 64ms. Memory scrambling prevents this from being an issue by ensuring that, on average, each bit being stored in physical DRAM capacitors will have an equal chance of being a 1 or 0, regardless of the logical data that is actually being stored. This is not unique to DRAM in any way and is employed by a wide range of high-speed buses.

Note conventional on-mainboard TPMs were susceptible to physical TPM reset attacks [...]

Once you have unrestricted physical access to a machine, maintaining integrity becomes very, very hard. An attacker can simply attach a JTAG probe and control the processor like a puppet.

How do DMA attacks and DMA work?

So, what happens if you plug in a rogue PCIe device? First, the computer will configure the device. If a driver requests it (which is usually the case if the PCIe device pretends it is, say, a WiFi card), it will be given bus master, which allows it to mount a DMA attack (which is also often called evil busmastering for this reason). Each PCI or PCIe device is part of what's called an IOMMU group. Without ACS at least (see section 4.3 in the Intel document), each IOMMU group has its own dedicated memory range and any device in that group will have the same restrictions applied to it.

Taken from a question I asked, you may look at your kernel log and see something like this:

DMAR: Setting identity map for device 0000:00:1d.0 [0xa95dc000 - 0xa95e8fff]
...
iommu: Adding device 0000:00:1d.0 to group 11

This means that any device in group 11, including 0000:00:1d.0, will only be able to read physical memory from address 0xa95dc000 to 0xa95e8fff. The kernel is configured to look at that region of memory for any DMA buffers that needs to be shared between it and the device.

I describe how DMA works and why it is needed on another answer. The relevant part:

It might be useful to understand why DMA exists and how it works. When DMA is supported, a dedicated region of memory is set up and the controller (whether the ICH or PCMCIA) directly writes the data read over IDE to that memory region (using the DMA-based UDMA or MDMA protocols). From the CPU's perspective, it issues a command to read data and then can go do its own thing, knowing it will be asynchronously alerted with an interrupt as soon as the process has been finished, with the requested data waiting right there in memory for it. Likewise if it wants to write over IDE, it can simply populate that memory region with the desired data and tell the controller to take it. Just like when reading data, the CPU is free to go off and do its own thing without needing to micromanage the transfers. It will be alerted with an interrupt as soon as the task is completed. This is why transferring data to and from devices (GPUs, NICs, storage devices using IDE or SATA, etc) can be made so fast and require so little CPU to perform.

How secure is an IOMMU?

There are some ways to bypass an IOMMU or reduce its effectiveness. For example, older IOMMUs on Intel using VT-d1 which lack x2apic and interrupt remapping are vulnerable, and Address Translation Services, or ATS, can bypass restrictions. A properly implemented IOMMU will, however, completely prevent a DMA attack from reading arbitrary system memory. This is what you will be relying on for protection from DMA attacks, not memory encryption. Memory encryption is designed to protect from passive bus sniffing and from cold boot attacks.

Memory management on x86 is incredibly complex, with their specifications including thousands of pages of dense technical information. All this complexity can have strange security implications, such as allowing a GPU to reconfigure an IOMMU to reduce security. While in theory, an IOMMU will prevent a device from accessing illegal memory ranges, there is no end to the complexity that underlies this technology and the potential vulnerabilities that come with this.

If this wasn't bad enough, DMAR tables, which an IOMMU relies on to restrict devices, are managed by a computer's OEM. It's not uncommon that a computer ships with a broken DMAR table, forcing the computer to completely disable DMA attack protection. For this reason, some operating systems (such as Debian GNU/Linux) actually have the IOMMU disabled by default!

forest
  • 64,616
  • 20
  • 206
  • 257
  • Interesting. I had no idea MMUs were now being applied to IO devices. I think it's worth mentioning somewhere that this is done for Virtualization reasons, not for security ones. – Steve Sether Jul 20 '18 at 14:11
  • 1
    Wow, what a fantastic answer. Thanks for the effort. – nh2 Jul 20 '18 at 19:28
  • One clarification: _"Not at all! When memory encryption is in place, the data will be transparently decrypted and sent over the PCIe bus when the device requests it."_ This first sounds like a contraction, if any data the device requests will be transparently decrypted. But from your answer, it seems like this is not an issue because the DMA is only possible into the specific area the kernel has reserved for that device (or group), and the kernel will not allocate anyting that's not for that device into this area. Is this an accurate summary? – nh2 Jul 20 '18 at 19:31
  • And another question: If a JTAG continues to give you unlimited power over the CPU, why do CPU vendors bother to add these features? In what realistic scenario could you mount a cold boot attack but not plug in a JTAG? – nh2 Jul 20 '18 at 19:33
  • 1
    @nh2 Some motherboards do not have JTAG headers and would require someone with a very fine point and a microscope to actually connect to the traces. Simply freezing and removing RAM is more reliable and takes less expertise. – forest Jul 20 '18 at 21:35
  • 1
    @nh2 Yes, that is an accurate summary. These ranges of memory will be dedicated only for use with DMA buffers. Nothing else will be allocated there. – forest Jul 20 '18 at 21:42
  • You may be interested in: **1**) "[Exploitation from malicious PCI Express peripherals](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-934.pdf)", by Colin Rothwell, page 26, **2**) "[Bypassing IOMMU Protection against I/O Attacks](https://hal.archives-ouvertes.fr/hal-01419962/document)", by Benoît Morgan, Eric Alata, Vincent Nicomette, and Mohamed Kaâniche. and **3**) "**[Exploitation from Malicious PCI Express Peripherals](https://www.repository.cam.ac.uk/handle/1810/274352)**", by Colin Rothwell, on page 47. – Rob Nov 20 '21 at 11:13