linux-kernel - Re: linux firewire implementation & DMA attack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 1 Mar 2015 11:16:07 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Pali Rohár <pali.rohar@...il.com>
Cc:	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: linux firewire implementation & DMA attack

On Feb 21 Pali Rohár wrote:
> I would like to know if current firewire implementation in Linux 
> kernel v3.19 still have security problems like DMA attack. If yes
> are there any prevention for it (maybe with intel_iommu)?

Remote DMA via the OHCI 1394 physical response unit is still enabled by
the Linux 1394 drivers:

  - The option "Remote debugging over FireWire early on boot"
    (PROVIDE_OHCI1394_DMA_INIT) links a minimal driver into the kernel
    which switches on unfiltered remote DMA at an early time, without/
    before the firewire-ohci driver is bound to any OHCI, if the boot
    parameter ohci1394_dma=early is passed to the kernel.

  - After the firewire-ohci driver is bound to an OHCI, the driver module
    parameter firewire_ohci.remote_dma "Enable unfiltered remote DMA
    (default = N) (bool)" does what it says until firewire-ohci is
    unbound from the OHCI.

  - After the firewire-sbp2 driver is bound to an actual or an apparent
    SBP-2 or SBP-3 target unit, this driver switches on filtered remote
    DMA for the node on which the target unit resides.  This lasts until
    the target unit is logically or physically removed from the bus
    (combined with a bus reset), or until firewire-sbp2 is unbound from
    the target, whichever happens first.  "Filtered remote DMA" means that
    remote DMA requests are only accepted from the selected node(s), unless
    firewire_ohci.remote_dma=true.

The OHCI 1394 remote DMA feature maps the lowest 4 GB of local physical
address space into the IEEE 1212 address space which remote 1394 nodes can
access.  Some OHCIs can be programmed to map much more than 4 GB (see
commit fcd46b34425d) but we leave it limited to the low 4 GB (see commit
2fe2023adf69).

I am not sure whether an IOMMU influences remote DMA via
PROVIDE_OHCI1394_DMA_INIT, i.e. whether or not the IOMMU (if one is
present in the system) maps all device addresses 1:1 during early boot
stages.  However, firewire-ohci's --- and with it, firewire-sbp2's ---
remote DMA is subject to remapping by an IOMMU.
-- 
Stefan Richter
-=====-===== --== ----=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/