Controlling device peer-to-peer access from user space

imMute — Wed, 21 Oct 2020 17:50:09 +0000

It's the same vulnerability. To sum it up: PCIe devices can initiated read and write commands. Typically, those commands target system RAM (this is how DMA works). Devices can just as easily target Memory or I/O space in other devices.
The solution is the same: IOMMUs as firewalls between devices you want to segregate.

>could a rogue device read and transmit an entire drive with nothing on the system aware of it?
Yes. It's exactly the same hole as reading and transmitting system RAM without the CPU noticing (except that it's typically more involved to access disk data than it is to access RAM).

Controlling device peer-to-peer access from user space

ScottMinster — Tue, 19 Mar 2019 16:11:21 +0000

> He mentioned a number of possible use cases, including one device controlling another device's command queue. An example of this situation is a network card accessing a block device command queue so that it can submit storage transactions without the CPU's involvement.

This sounds like it could really enhance those Thunderclap vulnerabilities (https://lwn.net/Articles/782381/). A network adapter that could send read (or write) commands to the storage device without any mediation from the main system seems dangerous. While things would be fine with a well behaving device, could a rogue device read and transmit an entire drive with nothing on the system aware of it? Or some other nefarious behavior writing to the drive.

What sort of security precautions are there to mitigate a rogue device, especially one plugged into an external port?

LWN: Comments on "Controlling device peer-to-peer access from user space"

Controlling device peer-to-peer access from user space

Controlling device peer-to-peer access from user space