LWN: Comments on "Bounce buffers for untrusted devices"

Bounce buffers for untrusted devices

bobot — Wed, 01 May 2019 08:02:56 +0000

It could be a first step which doesn't require any modifications of the user code. Later user code could be modified to avoid the need of bounce buffers.

Bounce buffers for untrusted devices

kevincox — Tue, 30 Apr 2019 16:44:46 +0000

Why use a bounce-buffer instead of just ensuring that nothing shares the page of the regular buffer? It seems like you now have an "owned page" plus an additional copy.

Bounce buffers for untrusted devices

Trelane — Tue, 30 Apr 2019 12:30:03 +0000

How does this work where peer-to-peer transfers are a feature, e.g. Nvidia gpudirect?

Bounce buffers for untrusted devices

jezuch — Tue, 30 Apr 2019 10:08:18 +0000

...To protect against regular incompetence in addition to malice.

Bounce buffers for untrusted devices

jic23 — Mon, 29 Apr 2019 07:45:04 +0000

It's worth noting that the performance lost by not doing lazy invalidations of the TLBs may well be significant. Shall we say, that 'optimization' is there for a reason.

Bounce buffers for untrusted devices

remleduff — Sun, 28 Apr 2019 21:13:51 +0000

I don't understand why the kernel doesn't allocate to the granularity of the IOMMU. There doesn't seem much harm in wasting part of a single 4k page if the device only wants part of it.

Bounce buffers for untrusted devices

mfuzzey — Sun, 28 Apr 2019 17:03:04 +0000

There will be a performance hit certainly but I don't think it completely negates the advantages of DMA.

As you say for large transfers the bounce buffer will only be used for the first and last partial pages.
But, even without that if you read directly from the device it has to be word by word to/from the peripheral by the processor.
Peripheral access is often slower than memory, due to wait states, uncached access, barriers etc.
Peripherals designed for DMA use may also have faster DMA access than CPU access (that all depends on the bus interconnects).

Furthermore even if the DMA is done to a bounce buffer that can be done quickly, potentially freeing the FIFO registers in the peripheral device for the next transfer while the CPU copies the first one.

Bounce buffers for untrusted devices

alison — Sun, 28 Apr 2019 05:59:08 +0000

Doesn't having a bounce buffer rather defeat the purpose of DMA? Is DMA via a bounce buffer faster than just plain copying the data in the processor's address space via normal mechanism? Perhaps the answer is that devices that perform small transfers that need sub-page allocations also perform many large transfers for which DMA makes sense.

Bounce buffers for untrusted devices

tau — Sat, 27 Apr 2019 19:25:40 +0000

Not if the root disk is encrypted using a TPM-protected key

Bounce buffers for untrusted devices

hmh — Sat, 27 Apr 2019 17:53:52 +0000

Do read their errata sheets/hardware defect lists... :(

Bounce buffers for untrusted devices

tao — Sat, 27 Apr 2019 11:58:37 +0000

Wouldn't such a scenario be kind of bye-bye anyway? Remote the root disk, replace it with one that has a replaced kernel or /etc/shadow or /bin/login or /bin/ssh or /bin/gpg or a gazillion other neat little backdoors.

Bounce buffers for untrusted devices

pabs — Sat, 27 Apr 2019 02:28:17 +0000

While researching the answer, I came across this question, which includes some links to research related to my question:

https://security.stackexchange.com/questions/176503/dma-a...

Bounce buffers for untrusted devices

pabs — Sat, 27 Apr 2019 02:16:55 +0000

Has there been any research into how trustworthy IOMMU devices are?

Bounce buffers for untrusted devices

flussence — Fri, 26 Apr 2019 23:59:45 +0000

And not just network devices either; things like DVB decoders on TV cards would make for an interesting target.

Bounce buffers for untrusted devices

sbates — Fri, 26 Apr 2019 22:55:39 +0000

> A PCI device is marked untrusted if the firmware marks its root port as external (currently only if the ExternalFacingPort ACPI property is set); that should be the case for Thunderbolt devices.

Is this setting also done for removable NVMe SSD slots in storage servers? If not then one could envision someone with physical access to the server could remove a trusted NVMe SSD and insert something more malicious. There are already several NVMe form-factors and servers that can support hot plugging of new PCIe devices and many more are coming....

Bounce buffers for untrusted devices

josh — Fri, 26 Apr 2019 20:10:21 +0000

Yeah, at the end of the day *all* devices should be untrusted and use an IOMMU.

Bounce buffers for untrusted devices

cesarb — Fri, 26 Apr 2019 18:24:54 +0000

> A PCI device is marked untrusted if the firmware marks its root port as external (currently only if the ExternalFacingPort ACPI property is set); that should be the case for Thunderbolt devices.

I won't be surprised when we find in the wild a computer where external Thunderbolt ports are not marked as ExternalFacingPort (or the opposite, a non-removable built-in device on the motherboard marked as ExternalFacingPort).

Bounce buffers for untrusted devices

hkario — Fri, 26 Apr 2019 17:25:37 +0000

I'd say that as a defence in depth approach, this should be applied to all devices, not only ones that have non-free or known buggy firmware.

Bounce buffers for untrusted devices

lkundrak — Fri, 26 Apr 2019 17:15:09 +0000

> PCI devices are usually built into the system, there was not much concern about them going rogue

There certainly are PCIe devices running firmware of very [1] questionable [2] quality that have network access. Can the MCUs generate arbitrary PCIe bus transactions? If so, I suppose they should also be marked untrusted? Is the untrusted property exposed in sysfs? Perhaps something like an udev rule that would mark net/wwan devices with non-free firmware (or at least known bad firmware) as untrusted would make sense?

[1] https://googleprojectzero.blogspot.com/2017/04/over-air-e...
[2] https://blog.quarkslab.com/reverse-engineering-broadcom-w...