If a computer is switched off, the data can stay in RAM memory for a while; decaying over about 5 minutes. This can be made longer by cooling the chips:


This makes it possible to do a cold boot attack on cryptographic keys.

There is TRESOR which stores the secret key inside CPU registers rather than in RAM.

Although if people would use FDE with ex.: LUKS, the "password/key in RAM in plaintext" could be still an issue.

Can TRESOR or a TRESOR-like solution solve these problems (?) or does it introduce new ones?

The Question: Was this method (encrypting RAM and store the key for it in CPU?) integrated in the Linux kernel? Or is it just not enabled by default?

  • 1
    Welcome to Information Security Stack Exchange! I have edited your question. I believe it explains the question better. If you disagree with my (rather extensive) edit, you can roll it back. To roll it back, click on the "edited ... ago" link. That takes you to the edit history page where you can do rollbacks. Commented May 15, 2015 at 18:14
  • TRESOR wasn't even discussed on lkml and no related commit can be found. So, even though the patches are licensed as GPL, nobody proposed to push them upstream.
    – ckujau
    Commented May 22, 2015 at 21:46
  • I registered to LKML (I can see now the many-many mails from it flowing in my inbox), sent an e-mail about this topic, but I cannot see that it got posted in reality to the list. What am I missing? Commented May 26, 2015 at 15:50
  • Do you mean this?
    – ckujau
    Commented Jun 12, 2015 at 19:30

1 Answer 1


No, TRESOR was never integrated into the Linux kernel. It is specific to the x86 architecture, and requires AES-NI in order to not have a pretty nasty overhead. Due to the limited size of DR registers where the key is stored, it cannot store and precompute round keys (a common AES optimization), and thus must recompute them every single time. This isn't much of a problem if you have AES-NI, but it can be a pain if you don't. Linux devs don't like adding a feature that's a hacky workaround to a specific forensic technique applied against a hardware bug, especially when the mitigation only works well on newer x86 CPUs with AES-NI.

In addition, it prevents setting hardware breakpoints. Now, people usually set software breakpoints when debugging, because you can only set a maximum of 4 hardware breakpoints at a time, but some people cannot use software breakpoints because of the lower performance. TRESOR, because it uses all DR registers, requires the kernel tell userland that the number of DR registers is 0, and block all access to them for security reasons.

Regarding whether or not it solves the problem of cold boot attacks, the answer is partially. It completely mitigates the issue of stealing encryption keys from memory, but it does not encrypt the rest of memory. If you open a super secret file, it will stay in your page cache for a while. If your system is cold booted right then, the majority of your disk may be protected, along with your AES key, but all the files in your cache, including that super secret file, are exposed. The same goes with the rest of the data in RAM, like pages open in your web browser, etc.

  • the idea could be ported to x64 easily, no? Commented Apr 15, 2016 at 7:03
  • increasing the HW DR register could help, no? Commented Apr 15, 2016 at 7:04
  • "but it does not encrypt the rest of memory" - what are you talking about? full memory would be encrypted, the keys would be in the register, no? Commented Apr 15, 2016 at 7:05
  • 2
    The idea does work on x86_64. But no, TRESOR only keeps your disk encryption keys in the debug registers, it does not encrypt all of your memory any more than using LUKS/dm-crypt encrypts all of your memory. There is an alternative called RamCrypt which partially encrypts memory (only individual processes, though) by using TRESOR, but the performance is pretty poor.
    – forest
    Commented Apr 15, 2016 at 10:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .