> 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.
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.
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.
`mlock()` can be used to prevent the memory from being paged out, but the DMA issue itself isn't something that can be (or should be) solved in userspace; if someone can do DMA reads/writes, rewriting any code or data, there's nothing an application can do.
In the absence of such mechanisms, especially when mlock() is unavailable (if running a Java app, for example), the app designer can use tricks like one described above to increase the level of difficulty for an attacker. It is not a solution, but an additional countermeasure.
Frozen Cache did something similar with No-Fill Mode.
Tresor used CPU debug registers.
For example, in a context of password storage app, the passwords and associated text should not remain in the clear in memory, and possibly even the character buffer of entry fields such as JPasswordField.
This is the reason for the MemCrypt code mentioned earlier.
Or use something like https://github.com/LucidWorks/mlockall-agent
Ironically, we could test this by disabling VT-d and using a DMA device to read encrypted main memory. Here's an old demo video: https://www.youtube.com/watch?v=chvJpEmXvDk
Cache evictions can also be monitored by CPU performance counters, so you can detect any that do occur.
http://ark.intel.com/search/advanced
Here's a list of Intel's latest CPU series, and how many have VT-d support:
* 5th gen i7: 5/5
* 5th gen i5: 6/6
* 5th gen i3: 5/5
* 4th gen i7 extreme: 2/2
* 4th gen i7: 42/49
* 4th gen i5: 46/55
* 4th gen i3: 5/37
So the summary: all but the slowest gen 4 i5 and i7 chips have it, and all gen 5 chips currently released have it.
edit: formatting
Intel's been a lot better about including VT-d on laptop chips, especially recently, and haven't disabled it on the consumer rebrands of their server chips (the "i7 Extreme" parts) in the past few generations, but did on earlier generations. Among the desktop parts, they've been all over the place, and most notably all but two of their flagship overclockable desktop processors (-K models) have had it disabled. Those models have most likely outsold their i5 and i7 counterparts that do have VT-d, and probably themselves been cumulatively outsold by the i3, Pentium, and Celeron processors that also lack VT-d. A raw count of the model numbers shows that in the time since VT-d has been released, the desktop processor models have been split 134 to 63 in favor of not supporting it.
The overall picture is that VT-d support is at least as hit-or-miss as HyperThreading support, which the Steam Hardware Survey finds to be present on about two thirds of Intel machines. Motherboard firmware support for VT-d is even worse, and of those that do support it, it's usually off by default.
This means that previous *-K (multiplier-unlocked) models have VT-d disabled, right? So you have to choose between overclocking and VT-d.
Intel is a corporation; its shareholders are shielded from personal financial liability for its errors; thus is seems appropriate that it be required to be responsible in exchange for the privileges it has been granted.