I know there have been questions on this in the past but they all seem quite outdated, or not that specifically relevant.

I need to use a 1394(Firewire) connection, however am concerned with possible DMA vulnerabilities. From my understanding a firewire device could spoof the amount of memory it requires access to, such that all memory address can be potentially read from the system. Within Linux for example is there a way in which this space can be restricted, possibly using mmap?? Any ideas are greatly appreciated.

  • I believe with a modern motherboard that has an IOMMU it is possible to avoid this vulnerability. However, I don't know the specifics.
    – paj28
    Commented Jan 21, 2014 at 10:01

3 Answers 3


FireWire controllers of the type used in PCs (OHCI) have the ability to allow other FireWire devices to do remote DMA. This feature must be enabled by the driver before it works.

The SBP-2 protocol is the only FireWire protocol that uses remote DMA; therefore, the Linux kernel enables remote DMA only for SBP-2 devices (i.e., hard disks and other storage devices), or any device that claims to be a SBP-2 device.

You can disable that driver by disabling it; write the line

blacklist firewire-sbp2

into any .conf file in /etc/modprobe.d, or disable CONFIG_FIREWIRE_SBP2 when compiling the kernel.

At the moment, the firewire-sbp2 driver relies on remote DMA for data transfers, so you have to choose between FireWire storage devices and protection from remote DMA attacks. (It would be possible to implement those transfers in software, but this has not yet been implemented.)

The ability to read/write any memory is also useful for debugging from another system, so there is the option CONFIG_FIREWIRE_OHCI_REMOTE_DMA that enables remote DMA for any FireWire device. However, this option is not enabled by default.


Do you need the SBP-2 protocol? If not, blacklist it: Add the following to /etc/modprobe.d/blacklist-firewire.conf:

blacklist firewire-sbp2

This should at least protect against tools like inception.


There is not a software mitigation for the DMA attack. In some cases even disabling the port doesn't work because the manufacture relies on a software off switch for the 1394 device.

By the time a Operating System level call could be invoked the attack has already succeeded.

Remove the 1394 device if its not needed (however be aware of other DMA vectors like PCMCIA, Thunderbolt, etc...) or use epoxy on the port.

  • user3192427 whilst I understand where your coming from I have also done a small amount of research into @paj28 comment about IOMMU. This component exists on most modern Intel chip sets such that (I think) it creates a virtual memory map that is then passed back up to the OS, where presumably it is translated into user space memory maps (where some control could be interjected), or have I got this all wrong.
    – Nark
    Commented Jan 21, 2014 at 22:26
  • @Nark you've got the right idea. To be protected you need both an IOMMU and an operating system that correctly uses the IOMMU to restrict the firewire port. I've no idea if Linux can do the latter. I suspect there will be some attempts; if you're lucky it may be mainstream.
    – paj28
    Commented Jan 21, 2014 at 22:54
  • 1
    This is wrong; remote DMA is disabled by default and must be enabled by software.
    – CL.
    Commented Jan 22, 2014 at 10:20
  • -1 As @CL. says. DMA over a PCIe device requires the PCIe configuration space's command register to have the "bus master enable" bit set. This bit is unset by default (except for the LPC on most modern Intel PCH, according to their datasheets), and the driver must explicitly set it to 1. Only then can the device make DMA requests.
    – forest
    Commented Mar 31, 2018 at 5:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .