From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: linux1394-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: linux firewire implementation & DMA attack
Date: Sun, 1 Mar 2015 11:16:07 +0100 [thread overview]
Message-ID: <20150301111607.485520e2@kant> (raw)
In-Reply-To: <201502211231.26090@pali>
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/
prev parent reply other threads:[~2015-03-01 10:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-21 11:31 linux firewire implementation & DMA attack Pali Rohár
2015-03-01 10:16 ` Stefan Richter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150301111607.485520e2@kant \
--to=stefanr@s5r6.in-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=pali.rohar@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox