Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inception: DMA Attack Against Linux, Windows, and Mac

github.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Inception: DMA Attack Against Linux, Windows, and Mac

#21

Post by rwh86 »

wtallis wrote: post #9
mmastrac wrote: post #8

Earlier quoted context omitted.

Isn't it on all the i5/i7 CPUs? I might be mistaken, but I can't recall a time in recent history I had a CPU without it.

Only the two most recent overclockable models ( Devils Canyon variant of Haswell ) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.

That's not what I see from searching Intel's ARK:

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

Re: Inception: DMA Attack Against Linux, Windows, and Mac

#22

Post by wtallis »

rwh86 wrote: post #21
wtallis wrote: post #9

Earlier quoted context omitted.

Only the two most recent overclockable models ( Devils Canyon variant of Haswell ) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.

That's not what I see from searching Intel's ARK: 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. edi…

For the purposes of this discussion, you really should be looking at more than just the current generation of chips, because the installed base that OS vendors have to worry about includes a lot of processors that are more than 18 months old, and a lot of processors from the budget product lines. The 5th generation parts so far are just ultra-low power tablet and ultrabook CPU, so almost all of the 4th-gen Haswell parts are still current.

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.

Re: Inception: DMA Attack Against Linux, Windows, and Mac

#23

Post by sweis »

0x0 wrote: post #12
sweis wrote: post #10

Earlier quoted context omitted.

You don't need a "protected processor". At PrivateCore, we kept all key material pinned in the L3 cache and ensured it was never evicted to main memory. Frozen Cache did something similar with No-Fill Mode. Tresor used CPU debug registers.

How can you be sure data doesn't leave the cache if the kernel interrupts - or worse, the BIOS performs an SMM interrupt?

You modify the kernel. As for SMIs, you know where SMRAM is located in memory and the cache geometry, so can ensure that there are cache ways available which SMIs won't evict.

Cache evictions can also be monitored by CPU performance counters, so you can detect any that do occur.

Re: Inception: DMA Attack Against Linux, Windows, and Mac

#24

Post by sweis »

java-man wrote: post #18
sweis wrote: post #10

Earlier quoted context omitted.

You don't need a "protected processor". At PrivateCore, we kept all key material pinned in the L3 cache and ensured it was never evicted to main memory. Frozen Cache did something similar with No-Fill Mode. Tresor used CPU debug registers.

There are cases when not only key material but also some data need to be protected. 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.

Yep, we ran the entire Linux stack pinned in the L3 cache, so no data or code hit main memory which was not encrypted.

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

Re: Inception: DMA Attack Against Linux, Windows, and Mac

#25

Post by mjg59 »

sweis wrote: post #10
java-man wrote: post #2

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…

You don't need a "protected processor". At PrivateCore, we kept all key material pinned in the L3 cache and ensured it was never evicted to main memory. Frozen Cache did something similar with No-Fill Mode. Tresor used CPU debug registers.

Can you guarantee that the storage driver doesn't DMA your key material to RAM during initial boot?

Re: Inception: DMA Attack Against Linux, Windows, and Mac

#26

Post by potatosareok »

java-man wrote: post #4
teacup50 wrote: post #3

Earlier quoted context omitted.

> 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…

I agree, there should exists explicit OS mechanisms to prevent leakage, be it via DMA, paging, or any other way. 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.

You can disable paging if you really care about that but setting swapiness to 0.

Or use something like https://github.com/LucidWorks/mlockall-agent

Re: Inception: DMA Attack Against Linux, Windows, and Mac

#28

Post by wtbob »

wyldfire wrote: post #17
wtallis wrote: post #9

Earlier quoted context omitted.

Only the two most recent overclockable models ( Devils Canyon variant of Haswell ) have VT-d, and artificially excluding all the budget product lines is not a responsible way to handle what should be seen as a security feature first and foremost.

Well, I doubt Intel sees it as a security feature first and foremost. But even if they did, they don't have an obligation to be "responsible" in how they market their features. Many of their pricing choices ultimately end up being related to yield. If they need to devote more transistors in order to enable an IOMMU, seems like it makes sense to charge more for it.

> But even if they did, they don't have an obligation to be "responsible" in how they market their features.

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.

Post reply on HN