> What are the implications for firewire device compatibility of doing > this? I am no expert on ieee1394, but I have read up a bit on this and tested Metlstorm's memory dumping tool and here's what I understand: Firewire chipsets allow drivers to configure a particular memory range which is open to access by DMA devices. Since the memory transfers occur completely without software intervention, the only way to restrict this is to tell the chip ahead of time what to allow and what not to allow. Before these tools came out, most free OSes simply opened up access completely to physical memory for any device. However, Windows would not do this. It would only open up access to devices that it thought needed DMA. This is why Metlstorm had to make his Linux machine behave like an iPod to fool Windows into spreading it's legs. Since the exploit tools came out for this, free OSes quickly started providing options to tell the chips not to open up access. I have tested the Linux drivers with the phys_dma=0 option, and found that some disk devices worked fine while others did not. I can confirm that the memory dumping tools did not work with this option set. Of course this is not an optimal fix. The drivers should just automatically restrict the DMA accesses in real time to a range that is safe but still permits devices to use it. (Presumably to buffers allocated specifically for I/O.) Not sure if some devices would still have problems with this, but I think this is the intended operation of ieee1394 based on the specs and I'd imagine it would work on a greater number of devices than having it disabled completely. Someone please correct me if I'm wrong on any of this. tim
