Clever but useless. Cold boot attack does not work on RAM with DDR3+. Pretty much all new computers are safe. http://superuser.com/a/464396

Plenty of other attacks work, such as sniffing memory lines on a running system.

That is not CBA so it's not on topic. Extracting encryption keys on a running system is completely other vector attack and I doubt using registers is much safer than RAM in such case. Might be wrong though. :)

Previous discussions: https://hn.algolia.com/?query=Tresor%20erlangen%20points%3E1...

DMA attacks (tb, firewire, etc) also have to be prevented so nobody injects code to pop the registers

Pretty clever, but do intel CPUs guarantee that xmm regs are zeroed on boot?

The key for AES is held in the four debug registers. On a 32-bit machine you get 4x32-bit for AES-128, or on a 64-bit machine 4x64-bit up to AES-256. The ptrace(2) system call is patched so these registers are not exposed to user space. And yes, they are zeroed on power-up or reset of the CPU.

patching ptrace is nice, but it does not stop me booting an unpatched kernel after pressing the reset button and reading them

hence my question.

thanks for answering

where in the intel cpu doc can i see this?

https://www-ssl.intel.com/content/www/us/en/processors/archi...

  Volume 3A
  Chapter 9, Processor Management and Initialization
  Table 9-1. IA-32 Processor States Following Power-up, Reset, or INIT

The debug registers are named DR0-3 and will be initialized with 00000000H. I can't find an explicit statement for IA-32e mode (Intel's name for x86_64), but I think it is safe to assume the remaining upper 32 bits will be cleared as well.

and sse regs?

Ah, suggesting that cold boot cpu hacks next?

CPU registers aren't as persistent.

Another implementation using ARM support for cache locking: http://research.microsoft.com/~ssaroiu/publications/asplos/2...

Ein wunderschönes Name!