LWN: Comments on "The Thunderclap vulnerabilities"

The Thunderclap vulnerabilities

nix — Tue, 19 Mar 2019 13:31:21 +0000

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).

standard plug and play security convenience tradeoff thing

Garak — Sat, 16 Mar 2019 01:51:32 +0000

Not for at least 5 years,-

https://arstechnica.com/information-technology/2013/12/inside-the-nsas-leaked-catalog-of-surveillance-magic/

the NSA has built and deployed its own USB cables at target locations—complete with spy hardware and radio transceiver packed inside."

I also recall a few articles from those key early Snowden days where one of the oddly louder complaints from the government about Snowden's leak related to them having to replace a large number of cables.

The COTTONMOUTH series of implants are USB devices that provide a covert wireless bridge into a target network. They can be integrated into any USB plug, so check your mouse.

The Thunderclap vulnerabilities

rweikusat2 — Wed, 13 Mar 2019 19:17:07 +0000

>> 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

nybble41 — Wed, 13 Mar 2019 15:21:17 +0000

> 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

rweikusat2 — Tue, 12 Mar 2019 21:50:00 +0000

> 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

westeri — Tue, 12 Mar 2019 21:01:52 +0000

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

rweikusat2 — Tue, 12 Mar 2019 19:48:34 +0000

"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

k8to — Tue, 12 Mar 2019 17:18:01 +0000

I think this complexity doesn't prevent categorically the idea of a device which tries to limit the interaction to charging. However, it does make it challenging, and fairly hard to imagine proving it safe.

Which is probably what you were getting at.

The Thunderclap vulnerabilities

westeri — Tue, 12 Mar 2019 16:16:42 +0000

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

The Thunderclap vulnerabilities

rweikusat2 — Tue, 12 Mar 2019 14:25:56 +0000

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

The Thunderclap vulnerabilities

westeri — Tue, 12 Mar 2019 11:02:57 +0000

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

rweikusat2 — Mon, 11 Mar 2019 19:50:43 +0000

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

mtaht — Mon, 11 Mar 2019 00:17:56 +0000

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

marcH — Sun, 10 Mar 2019 19:07:10 +0000

> How is it Intel's fault that Linux puts function pointers in the same page as network packets?

It's a brand new Remote Procedure Call technology; did you read the article? :-)

Remember: code is data and data is code https://lwn.net/Articles/778550/

The Thunderclap vulnerabilities

marcH — Sun, 10 Mar 2019 17:35:00 +0000

Probably the best technical blog about Type-C
https://plus.google.com/collection/0Vdov
moving to https://medium.com/@leung.benson

The Thunderclap vulnerabilities

nivedita76 — Sat, 09 Mar 2019 08:39:19 +0000

Really? You wouldn’t find it highly surprising that what looks like a wall wart is reading out your laptop’s memory?

The Thunderclap vulnerabilities

nix — Sat, 09 Mar 2019 01:34:52 +0000

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

flussence — Fri, 08 Mar 2019 23:33:55 +0000

Basic USB2 is limited to 5V@500mA - 2.5W. There's fast charging “standards” that go up to 900mA or more and most of them use passive components to signal it.

USB-C power negotiation however… makes the Linux x86 early-boot code sound simple and reasonable in comparison. Cables have their own CPUs, voltages aren't fixed, the hardware has to be prepared to put up to 100 watts into a tiny, fully bidirectional connector (and it's already infamous for doing it in the wrong direction too often - your phone will probably make a futile attempt to charge your laptop at some point). The technology's a disaster at every level.

The Thunderclap vulnerabilities

cpitrat — Fri, 08 Mar 2019 21:58:36 +0000

It will be highly surprising for the average user I guess.

The Thunderclap vulnerabilities

JFlorian — Fri, 08 Mar 2019 18:53:20 +0000

Seems like a good time to mention usbguard [https://usbguard.github.io/]. Obviously this is only one attack surface but it helps.

The Thunderclap vulnerabilities

rweikusat2 — Thu, 07 Mar 2019 20:49:03 +0000

One could argue that Intel wrote the e1000 driver which uses kmalloc to allocate 2K areas which thereby enables the malicious device to access what's in the other 2K of the page the buffer resides in. Shockingly, other kernel code also uses kmalloc, hence, this can lead to a variety of interesting observations.

The Thunderclap vulnerabilities

mebrown — Thu, 07 Mar 2019 17:39:11 +0000

Thunderbolt 3 - 40Gbps top speed
USB 3.2 2x2 superspeed - 20Gbps top speed

We don't get equivalent top speeds until USB4 is released.

The Thunderclap vulnerabilities

dirkhh — Thu, 07 Mar 2019 15:52:36 +0000

Hi Jon,

The problem with that is the USB A would limit you to something like 12.5W, right? And for a modern phone that's disappointing whereas for a MacBook Pro that isn't even enough to keep it from discharging while idle...

But yes, it sounds like we need a "USB C condom"...
Having that name actually gives me more interesting Google result - but from what I can see so far there have been quite a few requests similar to mine, but only USB-A versions appear to actually exist.

The Thunderclap vulnerabilities

corbet — Thu, 07 Mar 2019 15:42:59 +0000

I have a "USB condom" for USB A that, naturally, can be used with an A-to-C cable for charging (and I do just that). I haven't seen such a thing for native USB C yet.

The Thunderclap vulnerabilities

dirkhh — Thu, 07 Mar 2019 15:29:22 +0000

Ever since buying my first Mac with USB-C charging I wondered if there's a simple way to have a hardware dongle that allows JUST the charging, but none of the data access. I.e., male/female USB-C connector with enough electronics in between to enable charging, but nothing else.

Obviously that would be equally useful when charging your USB-C phone.

The Thunderclap vulnerabilities

robclark — Thu, 07 Mar 2019 13:58:00 +0000

Seems like we need the concept of a "less trusted" dma capable device that both sits behind iommu plus gets bounce buffer for things smaller than a page..

using hardware filters...

Herve5 — Thu, 07 Mar 2019 10:35:59 +0000

I for one have been happily using a couple of "USG" filters (https://github.com/robertfisk/USG), which work absolutely well for USB1; I see now the author builds USB2 filters (faster, but not fully open anymore apparently)

This may become an opportunity to prepare something for USB3/Thunderbolt?

The Thunderclap vulnerabilities

mangix — Thu, 07 Mar 2019 08:35:01 +0000

Actually there will be a USB 3.2 which brings the same speed as thunderbolt 3 but for USB (so no DMA).

The Thunderclap vulnerabilities

halla — Thu, 07 Mar 2019 07:34:37 +0000

" In addition, because USB Type-C connectors are used for charging these days, it will be highly surprising that a "charger" may actually also be a Thunderbolt device—with all of the access that implies."

I think there's a 'not' missing between 'will' and 'be'. At least, I was not highly surprised.

The Thunderclap vulnerabilities

mjg59 — Thu, 07 Mar 2019 02:50:08 +0000

How is it Intel's fault that Linux puts function pointers in the same page as network packets?

The Thunderclap vulnerabilities

arekkusu — Thu, 07 Mar 2019 02:15:47 +0000

Nothing new with DMA being dangerous (and also useful of debugging). However we're in 2019 and I think providing unrestricted DMA to external device should not be acceptable.

What constitute an external or internal interface might not be obvious for some attack. For example the SATA port on my ThinkPad UltraBay is quite accessible. Disabling FireWire and other unused port in the BIOS is something I've been doing for a long time.

But a USB Type-C connector is something everyone will be using. Considering Thunderbolt 3 will become USB4, it is a real concern. And just telling user to not plug in "untrusted device" is not good enough.

And my understanding is that this can not be fully fixed at the OS level:

"Kernel DMA Protection only protects against drive-by DMA attacks after the OS is loaded. It is the responsibility of the system firmware/BIOS to protect against attacks via the Thunderbolt™ 3 ports during boot."
Ref: https://docs.microsoft.com/en-us/windows/security/informa...

The Thunderclap vulnerabilities

flussence — Thu, 07 Mar 2019 00:42:16 +0000

Yet another Intel-designed thing full of holes? What a shocker.

It's pretty shameful that these exploits are happening over and over after the industry's had approximately two decades to learn the risks of giving DMA to external peripherals. The kernel even advertises Firewire debugging as a *feature*!