On Sun, Oct 14, 2012 at 9:57 PM, Steve Weis <steveweis@???> wrote:
> There are two alternative driver stacks (e.g. ieee1394 and firewire-core)
> and the docs talk about them both interchangeably. It's a bit confusing. The
> CONFIG_FIREWIRE_OHCI_REMOTE_DMA kernel hacking option may only be relevant
> to the legacy ohci1394 module.
Indeed, the doc is confusing, but it's easier to look at the source
files. CONFIG_FIREWIRE_OHCI_REMOTE_DMA is used by the new stack, and I
was actually wrong previously when saying that physReq* registers are
only written to if the option is disabled (missed an #else in an
#ifdef). The ohci_enable_phys_dma() function in
drivers/firewire/ohci.c enables physical DMA for a specified node, and
this function is called by none other than the sbp2 module (via a
wrapper), in sbp2_probe() and sbp2_update().
So:
> One thought is that it the sbp2 module might be allowed to circumvent
> whatever filtering is happening. Sbp2 enables full DMA access, and I haven't
> been able to carry out Firewire DMA attacks via Inception without it.
This must be exactly the case. Sbp2 actually uses DMA filtering — it
“filters” physical DMA to a specific Firewire node.
> blacklist firewire_sbp2
This (or disabling CONFIG_FIREWIRE_SBP2) should be enough to prevent
physical DMA attacks on Firewire — there is currently no other way to
enable physical DMA in Firewire than via firewire_sbp2 or via
unfiltered physical DMA (enabled by CONFIG_FIREWIRE_OHCI_REMOTE_DMA).
Of course, there is also asynchronous DMA, but its accessible memory
regions are kernel's responsibility.
--
Maxim Kammerer
Liberté Linux:
http://dee.su/liberte
