It's a shame that Intel only advertises VT-d as an enterprise-oriented virtualization feature and only offers it on a few models of consumer CPUs. They should have treated it like the NX bit and made it universal so that operating systems could rely on it.
It's frankly disgusting that they are withholding an efficient hardware solution to an entire class of security problems, when they could make it available to almost everyone with a microcode update.
This attack is relevant for password storage apps.
As an additional countermeasure, I encrypt editor field and text area buffers that might contain sensitive information, see for example:
https://github.com/andy-goryachev/PasswordSafe/blob/master/s...
A symmetric key used to encrypt/decrypt RAM-based data is generated on the fly. There is a brief period in time when data is present in the clear in memory - when it's used - but nothing can be done about it, short of moving the code to some kind of protected processor.
This is an impressive attack -- but as far as I can tell, it requires physical access to the machine. Is that correct?
Since I'm sure people will comment without reading it ;p, here is a copy of the Caveats section:
> OS X > 10.7.2 and Windows > 8.1 disables FireWire DMA when the user has locked the OS and thus prevents inception. The tool will still work while a user is logged on. However, this is a less probable attack scenario IRL.
> In addition, OS X Mavericks > 10.8.2 on Ivy Bridge (>= 2012 Macs) have enabled VT-D, effectively blocking DMA requests and thwarting all inception modules. Look for vtd[0] fault entries in your log/console.