However, he does this by using the NAND as a PCIe master, which implies that the peer (main SoC) would be switched to device mode, and the whole PCIe handshake happens properly.
While I can't dismiss that possibility entirely, I'm not holding my breath for it to work out.
No, you don't have to switch "Master" and "Device" mode (what does that even mean in PCIe?).
You might be surprised to hear that your networking card, the AHCI-SATA interface and even the sound-card soldered onto your computer's mainboard is allowed to, and does, read from and write to your computers memory whenever you are using it. {that's just where I had to dig in, in the past, almost any modern peripheral uses DMA}
If the operating system needs a block from your harddisk to be read, and stored in a certain memory location it will actually tell the physical memory location to the AHCI controller and tell it to write the contents into memory, on it's own. It will signal an interrupt when it has finished transfering the data.
Your networking card will have "ring descriptors" which tell the card a list of buffers (in RAM) into which to save new incoming packets. It will raise an interrupt after it has finished writing to the first buffer.
Your sound-card will likewise have a list of buffers from which it reads, and to which it writes just as you are listening to mp3s, or having a phone conversation with google hangouts.
The worst offender would probably be Firewire which, ifnotconfiguredtoblockthis (modern OSes do), allows these reads from/writes to memory triggered by any connected external device, and from/to addresses supplied by this external device. It can be a huge help for debugging, though.
On typical computers, there's no safeguard against this happening. But some have a IOMMU which can be used to limit DMA and redirect DMA accesses with respect to physical memory.
To what degree can misbehaving PCIe devices (as in the device as a whole being malicious, not simply manipulated) override IOMMU protections? Can they pretend to be another device or otherwise send unexpected signals to confuse this defense?
Violating the timing specs for PCI signalling would put the whole system into an undefined state. It's possible you could glitch the thing on the other end into doing whatever you want. Who knows?
PCIe devices can identify themselves to the host with whatever vendor and device IDs they want.
Since PCIe is a point to point link rather than a shared bus, it is not really possible for a malicious peripheral to pretend to be connected through a different port. PCIe switches may weaken this security somewhat.
No, root pendrives must exploit bugs in USB/block/fs/UI subsystems of the OS. PCIe devices can read/write RAM directly as they please unless isolated behind IOMMU.
Comments
That isn't what he's describing. He is commanding the storage controller to initiate DMA from host memory over the PCI-Express bus.
Ah good point.
However, he does this by using the NAND as a PCIe master, which implies that the peer (main SoC) would be switched to device mode, and the whole PCIe handshake happens properly.
While I can't dismiss that possibility entirely, I'm not holding my breath for it to work out.
No, you don't have to switch "Master" and "Device" mode (what does that even mean in PCIe?).
You might be surprised to hear that your networking card, the AHCI-SATA interface and even the sound-card soldered onto your computer's mainboard is allowed to, and does, read from and write to your computers memory whenever you are using it. {that's just where I had to dig in, in the past, almost any modern peripheral uses DMA}
If the operating system needs a block from your harddisk to be read, and stored in a certain memory location it will actually tell the physical memory location to the AHCI controller and tell it to write the contents into memory, on it's own. It will signal an interrupt when it has finished transfering the data.
Your networking card will have "ring descriptors" which tell the card a list of buffers (in RAM) into which to save new incoming packets. It will raise an interrupt after it has finished writing to the first buffer.
Your sound-card will likewise have a list of buffers from which it reads, and to which it writes just as you are listening to mp3s, or having a phone conversation with google hangouts.
The worst offender would probably be Firewire which, if not configured to block this (modern OSes do), allows these reads from/writes to memory triggered by any connected external device, and from/to addresses supplied by this external device. It can be a huge help for debugging, though.
On typical computers, there's no safeguard against this happening. But some have a IOMMU which can be used to limit DMA and redirect DMA accesses with respect to physical memory.
To what degree can misbehaving PCIe devices (as in the device as a whole being malicious, not simply manipulated) override IOMMU protections? Can they pretend to be another device or otherwise send unexpected signals to confuse this defense?
Violating the timing specs for PCI signalling would put the whole system into an undefined state. It's possible you could glitch the thing on the other end into doing whatever you want. Who knows?
PCIe devices can identify themselves to the host with whatever vendor and device IDs they want.
Since PCIe is a point to point link rather than a shared bus, it is not really possible for a malicious peripheral to pretend to be connected through a different port. PCIe switches may weaken this security somewhat.
It is a similar vector of attack as with root achieving pendrives, except PCIe devices are even less verified.
TCB verification in TPM and firmware to verify the code running on the microcontroller is required to prevent such an attack.
No, root pendrives must exploit bugs in USB/block/fs/UI subsystems of the OS. PCIe devices can read/write RAM directly as they please unless isolated behind IOMMU.
Unless they are USB-C devices and the host supports Thunderbolt 3 without an IOMMU. An innoculous looking device could perform a DMA exploit.