The Thunderclap vulnerabilities

Posted Mar 9, 2019 1:34 UTC (Sat) by nix (subscriber, #2304)
In reply to: The Thunderclap vulnerabilities by rweikusat2
Parent article: The Thunderclap vulnerabilities

In Intel's defence, "I allocated 2K of memory rather than a full page" is not exactly an *obvious* equivalent to "now externally-connected peripherals can spy on kernel data structures". Developers do generally assume kernel memory is only readable by the kernel, and that the PCIe bus is trusted -- both of which are, it is true, questionable assumptions, but it's damn hard to write useful code at that level without making at least one of them. (And the e1000e driver is much older than Spectre and other similar families of oh-just-blow-away-access-protection attacks.)

The Thunderclap vulnerabilities

Posted Mar 11, 2019 0:17 UTC (Mon) by mtaht (subscriber, #11087) [Link]

Millcomputing's PLB is the only way out. ( http://millcomputing.com/wiki/Protection )

Too bad I don't have a spare billion $ to get it past plausible promise.

The Thunderclap vulnerabilities

Posted Mar 11, 2019 19:50 UTC (Mon) by rweikusat2 (subscriber, #117920) [Link] (9 responses)

The point was supposed to be that "Linux" doesn't "put function pointers in the same page as network packets" in the way this statement suggests.

Linux has a general purpose kernel memory allocator. This is a power-of-2-freelist allocator sitting atop the page allocator (more precisely it's implemented as set of object caches for objects whose sizes are powers-of-two). As detailed in the paper, the e1000 driver allocates skbs via kmalloc. This means its network buffers will usually occupy some part of a page. An access control mechanism with page granularity thus cannot prevent malicious devices from accessing the remaining part of the page. As that's just one of the pages currently allocated to one of the kmalloc caches, any other part of the kernel which uses kmalloc could end up using this "remaining part of the page".

The gist of this is that a (page-based) IOMMU can only prevent malicious devices from accessing data they're aren't supposed to access if the devices drivers used for such devices do their own memory management based getting complete pages from the page allocator.

The Thunderclap vulnerabilities

Posted Mar 12, 2019 11:02 UTC (Tue) by westeri (subscriber, #62678) [Link] (8 responses)

There is now a patch series from Lu Baolu aiming to fix the remaining issues here:

https://lore.kernel.org/lkml/20190312060005.12189-1-baolu...

The Thunderclap vulnerabilities

Posted Mar 12, 2019 14:25 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (7 responses)

"Copy the data into a dedicated page" is an ugly workaround for the issue.

The Thunderclap vulnerabilities

Posted Mar 12, 2019 16:16 UTC (Tue) by westeri (subscriber, #62678) [Link] (6 responses)

Feel free to propose a better one that does not involve fixing all the possible PCI drivers using DMA ;-)

The Thunderclap vulnerabilities

Posted Mar 12, 2019 19:48 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (4 responses)

"Don't buy devices from the people who wrote the paper"?

Assuming that memory protection/ accesss control with page granularity is available, DMA buffers used by untrusted devices (and this should really be all kinds of devices) must not share memory pages with code whose information said untrusted devices are not supposed to access if the access control is supposed to be used effectively. This means *if* such a facility is to be used in a sensible way, DMA buffer allocation must be per-device and separate from all other allocations, including other DMA buffer allocation.

There are obviously tradeoffs here as most real-world devices won't be untrusted but singling out a certain kind of devices and adding an additional DMA buffer allocation system working on top of the existing DMA buffer allocation systems is a technically seriously unpleasant workaround for a highly unlikely fringe case.

The Thunderclap vulnerabilities

Posted Mar 12, 2019 21:01 UTC (Tue) by westeri (subscriber, #62678) [Link] (3 responses)

The problem here is that you can essentially plug in any PCIe device to a Thunderbolt enclosure (as they come with one or multiple PCIe slots). This means that you would need to fix each and every PCI driver to make sure they only do DMA to/from buffers that fill the whole page (the minimum IOMMU window size). Doing it in the IOMMU driver allows us to prevent the DMA attack now without need to modify all the PCI drivers. Since it only bounces buffers not filling the whole page so when a driver gets "fixed" it won't bounce anymore and eventually we can turn the bouncing off completely.

The Thunderclap vulnerabilities

Posted Mar 12, 2019 21:50 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (2 responses)

> The problem here is that you can essentially plug in any PCIe device to a Thunderbolt enclosure (as they come with one or multiple > PCIe slots). This means that you would need to fix each and every PCI driver

Yes. I thought I already wrote this ("this should really be all kinds of devices"): If this issue is supposed to be mitigated by the IOMMU, any driver which supports DMA would need to use its own DMA buffer backing pages cache. There's no need for individual buffers to span a complete page (or some number of complete pages) provided management information used by a driver isn't kept in the unused parts of some page a part of which is currently used as DMA buffer, at least not in a way where corruption could go unnoticed. Malicious device snooping on itself sounds pretty harmless to me ;-).

Assuming that fixing this is considered desirable (the underlying issue has existed forever --- there's no reason why hardware designed by an unknown entity ought to be trustworthy, especially not if this 'hardware' is in itself complicated enough to contain a general purpose CPU running some decidedly non-trivial software), this cries out for some sort of infrastructure support for DMA buffer allocation drivers could easily make use of.

NB: I understand the benefits of the existing approach. But that's still just life-patching of a more fundamentally deficient (in this respect) memory management model.

The Thunderclap vulnerabilities

Posted Mar 13, 2019 15:21 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (1 responses)

> any driver which supports DMA would need to use its own DMA buffer backing pages cache

The page cache would need to be separate for each *device*, not each driver. A device snooping on itself may be harmless, but the same is not necessarily true for snooping on other devices managed by the same driver. Besides the fact that one driver might manage multiple brands and models of devices, some more trustworthy than others, one can also envision e.g. a system with two identical NICs surreptitiously snooping on each other and transmitting internal network data over the external network.

The Thunderclap vulnerabilities

Posted Mar 13, 2019 19:17 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link]

>> any driver which supports DMA would need to use its own DMA buffer backing pages cache
> The page cache would need to be separate for each *device*, not each driver.

A driver capable of managing more than one device would obviously need one cache per currently managed device. Do you think somebody wouldn't immediately recognize this if such a driver was under discussion?

The Thunderclap vulnerabilities

Posted Mar 19, 2019 13:31 UTC (Tue) by nix (subscriber, #2304) [Link]

It feels to me like a pooled allocator is what you want: each DMA-capable device gets a separate pool, and memory the allocator gives back to a given pool uses pages distinct from that used by all other pools; memory is zeroed before being placed in the pool. That way, a hostile device can only spy on memory it itself has populated (assuming that page-level protection still functions properly: so even this still needs a working IOMMU).