Login
You're viewing the chinwag.org public feed.
  • niconiconiniconiconi@mk.absturztau.be
    Aug 11, 2026, 6:08 AM

    Hackers, 2000: DMA allows arbitrary memory access!
    Vendors: Isn't that great? Kernel debugging is so convenient!

    Hackers, 2010: FBI and NSA can use ExpressCard and IEEE 1394 DMA to access memory at will and steal full-disk encryption keys from participants in movements like "Occupy Wall Street"!
    Vendors: How many dissidents across the US are actually going to get targeted by the FBI like that?

    Hackers, 2020: USB 4 allows arbitrary memory access via DMA, any standard USB device can be used to steal data!
    Vendors: Physical security isn't our responsibility - you can just seal off the USB ports.

    Hackers, 2025: PCIe DMA enables online game cheats that the system can't detect!
    Vendors: Right now! Immediately! Enable IOMMU! Anyone who doesn't enable it gets their account banned!

    💬 4🔄 12⭐ 1

Replies

  • 💬 2🔄 1⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0
  • David Chisnall (*Now with 50% more sarcasm!*)david_chisnall@infosec.exchange
    Aug 11, 2026, 6:29 AM

    @niconiconi

    When we reported the Thunderclap attacks (DMA from malicious Thunderbolt devices) Linux distros told us the IOMMU support was there and users could enable it if they wanted. Apple reduced the duration that IOMMU windows were open and separated the data and metadata in mbufs used for DMA so a device impersonating the network card [1] could provide fake data but couldn’t fake kernel pointers and do the attack we’d been using to get arbitrary code execution. Microsoft told us that it was out of scope for their threat model.

    [1] In theory, XNU sets per-device IOMMU policies but this is intended to defend against malicious software (e.g. VMs with device pass through) initiating a DMA from a non-malicious device. It doesn’t defend against a malicious device because the device can just lie about its device ID on the bus (until you have TDISP and IDE).

    💬 1🔄 0⭐ 0
  • Val Packett 🧉valpackett@treehouse.systems
    Aug 12, 2026, 1:21 AM

    @david_chisnall "just lie about its device ID".. well you can always have impersonation if there's no cryptographic authentication, but the hope is that for whatever it is that the device would impersonate, the drivers shouldn't have catastrophic vulnerabilities that can still do real damage from behind an iommu xD

    💬 0🔄 0⭐ 0
  • David Chisnall (*Now with 50% more sarcasm!*)david_chisnall@infosec.exchange
    Aug 12, 2026, 6:35 AM

    @valpackett TDISP and IDE add the end-to-end attestation and on-the-wire encryption parts that solve this. The impersonation is a bit silly to allow because PCIe isn’t really a bus, it’s a switched network. Each bridge could be configured with the device IDs that are supposed to be there and not allow messages that claim to come from a device attached elsewhere (that, for example, would prevent a device plugged into a Thunderbolt port pretending to be your SSD).

    The IOMMU configuration can prevent a lot of things but even most full-disk encryption approaches aren’t hardened against replay, so a malicious device can, when you try to read a block from disk, overwrite it with an old version of the same block. With TDISP and IDE, this becomes impossible.

    💬 1🔄 0⭐ 0
  • Val Packett 🧉valpackett@treehouse.systems
    Aug 13, 2026, 8:08 AM

    @david_chisnall I meant, impersonation in terms of VID/PID still happens, not in terms of "from elsewhere"… That one should already be prevented without attestation, just by SoC design! Modern reasonable SoCs (i.e. not x86) tend to have a bunch of totally separate single-port roots, all isolated by IOMMU.

    💬 0🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0