On Sun, Oct 14, 2012 at 9:57 PM, Steve Weis <[email protected]> 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 _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
