[sweis]

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.

[0x0]

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

[sweis]

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.

[java-man]

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.

[sweis]

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

[mjg59]

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