>>What points are you trying to stab at for an article? You've hit on them pretty well. My own experience with DMA programming was 20 years ago with real mode DOS drivers, but I was surprised to learn from this thread that a DMA mass storage device on Linux, Mac and Windows gets unimpeded access to the full stretch of system memory. I take what I read here with a grain of salt, but the non-nut cases seem to be out and in agreement, at least about that. I'm not going to be writing a 20 page paper. I think I have 2 main questions I'll write about: How much should you worry about this and is it fixable (beyond disabling DMA, which is not a good solution if you ask me). You say it's fixable; that still leaves some questions for me whether the fix comes at the expense just of additional sophistication in the Firewire drivers or also a performance burden. I'll probably just leave it at a question. I actually do have a response fom Microsoft on the broader issue, but it doesn't address these issues or even concded that there's necessarily anything they can do about it. They instead speak of the same precautions for physical access that they spoke of a couple weeks ago with respect to the "frozen notebook memory" attack - use drive encryption, use 2-factor authentication, use hibernate instead of sleep, use group policy to enforce them. I don't think it's a bad response under the circumstances. The fact that you can turn off DMA on Linux seems in fact inferior to simply disabling the Firewire port and driver at run-time in Windows. They both suck as solutions. Incidentally, Microsoft made a few other points in their response that were interesting, but raised more questions than they answered: * it's possible for a user to disable 1394 DMA. I'm still looking into how you can do this. * it's possible for a user to "constrain a DMA device's memory access to specific ranges by using the physical DMA type." They say that some devices cannot be so restricted at all, and for others the restriction would only come at the cost of additional complexity and a performance hit, as I allude to above. I assume these considerations are generic to the hardware and not specific to Windows. How much should the average user worry about this? Not very much. Most notebooks from average users don't even have Firewire on them and you would have an easier time cracking them with a dictionary attack on the password and other such things, which means that this attack makes you no more vulnerable to compromise if you've already granted physical access than you were before. The frozen notebook memory attack seems a little too Mission Impossible for me to get worked up about. And if you're the sort of high-value target who needs to worrry about this sort of attack, there are measures you can take: use drive encryption, use 2-factor authentication, use hibernate instead of sleep, use group policy to enforce them. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blogs.pcmag.com/securitywatch/ Contributing Editor, PC Magazine larry.seltzer@xxxxxxxxxxxxxxxxxxxxxxx
