Linux 5.10 Hardens Against Possible DMA Attacks By External PCIe Devices

[phoronix]

Phoronix: Linux 5.10 Hardens Against Possible DMA Attacks By External PCIe Devices

The PCI changes were submitted on Wednesday for the Linux 5.10 kernel...

http://www.phoronix.com/scan.php?pag...Linux-5.10-PCI

[kobblestown]

One change is the enabling of ACS translation blocking for external PCIe devices in protecting against possible DMA attacks.

This should probably be done for internal PCIe devices as well. Most devices these days are entire computers with complex firmware that can be exploited. We don't want those to be able to run amok.

[Brane215]

One change is the enabling of ACS translation blocking for external PCIe devices in protecting against possible DMA attacks.

This should probably be done for internal PCIe devices as well. Most devices these days are entire computers with complex firmware that can be exploited. We don't want those to be able to run amok.

There might be a reason they skipped it. This is probably used by a government to surveill citizens en-mass.
AS you said, every NIC has microcontroller. And those are usually tied to particular computer, location and user.
Once they have the green light, NIC is gewts "magic packet" that makes it go zombie and opens the machine.
It's obvious, why would they want to keep this vector for themselves.

But they can't have all those DIY enterpreneurs walk around with enrichened USB drives etc.

[skeevy420]

It's because external implies a plug and play hack, internal implies a plug and play hack after you've opened up the system. One hack takes literal seconds and can be accomplished by anyone with decent social engineering skills, the other hack requires the person to open a computer. Most people will realize that the person disassembling their work PC isn't Jeff from IT.

[jntesteves]

One change is the enabling of ACS translation blocking for external PCIe devices in protecting against possible DMA attacks.

This should probably be done for internal PCIe devices as well. Most devices these days are entire computers with complex firmware that can be exploited. We don't want those to be able to run amok.

If you can't trust the hardware inside your computer your data is already pwned.
That said, it's indeed a sad state of computing that closed-source drivers and firmware are still a thing.

[yariv]

If you can't trust the hardware inside your computer your data is already pwned.
That said, it's indeed a sad state of computing that closed-source drivers and firmware are still a thing.

That's not exactly true. Ensuring that, say, a network controller only accesses the network buffers - as opposed to the entire physical RAM - makes a lot of sense.

[jntesteves]

That's not exactly true. Ensuring that, say, a network controller only accesses the network buffers - as opposed to the entire physical RAM - makes a lot of sense.

I haven't ever looked at Kernel code so I have no idea how that works, but I never thought what you are describing was possible anyway. I thought a device could only access memory mapped and made available to it by it's in-kernel driver. If that driver is a blob, then yes that's true, but I didn't expect it otherwise.

[ssokolow]

I haven't ever looked at Kernel code so I have no idea how that works, but I never thought what you are describing was possible anyway. I thought a device could only access memory mapped and made available to it by it's in-kernel driver. If that driver is a blob, then yes that's true, but I didn't expect it otherwise.

Only if driver is written to use the IOMMU, which is a surprisingly recent addition to x86-family machines. Otherwise, the DMA-capable device has unrestricted access for backwards compatibility.