|
|
Log in / Subscribe / Register

Controlling device peer-to-peer access from user space

Controlling device peer-to-peer access from user space

Posted Mar 19, 2019 16:11 UTC (Tue) by ScottMinster (subscriber, #67541)
Parent article: Controlling device peer-to-peer access from user space

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


to post comments

Controlling device peer-to-peer access from user space

Posted Oct 21, 2020 17:50 UTC (Wed) by imMute (guest, #96323) [Link]

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


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds