Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I wonder if it is possible to write a kernel that would keep all of its RAM encrypted, storing the key in the CPU cache, so that the machine would be resistant to cold-boot attacks?

share|improve this question
Possible duplicate of this question: – Xander Feb 20 '13 at 23:28
Not really, I think. – d33tah Feb 20 '13 at 23:32
PrivateCore's vCage is designed around the assumption that everything but the CPU is untrusted, so that includes the RAM. The kernel itself is locked to the CPU cache, and the entirety of the RAM is encrypted, so the most the RAM could do, if it were maliciously modified, is cause the system to crash. The same applies to malicious PCI devices, the motherboard going haywire, etc. – forest Apr 8 at 1:13
up vote 13 down vote accepted

Data in L1 cache will not remain in L1 cache only; the hardware will copy it to main RAM transparently and almost immediately. At least so operate modern CPU. If you want to keep sensitive data out of RAM, then you must keep it in registers only. Context switches will be a problem, also, since they automatically flush registers to a designated RAM space.

While it is theoretically possible to operate only in registers and do encryption and decryption in the CPU only, it will be hard to do correctly (random-access encryption with updates is difficult to design without weaknesses) and it will be very expensive (you would more or less have to implement a virtual machine, where each opcode entails some decryption, so expect a slowdown of a factor 50 at least).

The TRESOR project appears to be much more limited in scope; it does not want to protect generic data from leaking to RAM, only encryption keys. Which, in my opinion, misses the point. You encrypt data because that data is sensitive and should be kept confidential. The encryption key is a high-value target because it concentrates secrecy, but certainly not the only target.

share|improve this answer
How about allocating as much RAM as possible and putting an encrypted swapfile then? – d33tah Feb 21 '13 at 13:09
Question is about not letting clear content make it to the RAM itself, not to the swapfile. Cold boot attacks plunder the contents of the RAM chips directly. – Tom Leek Feb 21 '13 at 15:20

... keep all of [the] RAM encrypted, storing the key in the CPU[?]

Yes, you could write a kernel that stored the key in a CPU register. SSE processors (basically any running Intel architecture) have 128 bit "XMM" registers that the key can be stored in, and the latest Intel chips can do hardware-based AES. One register, one key, one CPU instruction.

You'd lose a multipurpose register and have to swap into kernel mode very often (massive performance killer) or give each application its own key that is encrypted with the kernel's key, but it'd work. The wicked catch is that a context switch usually puts the register values into RAM. The key and anything else in the kernel have to be bumped because any application can use all general-purpose registers.

What's really needed is a persistent register that is addressable only by ring 0. I know these exist as control registers, but wasn't sure of any general purpose ones are laying around for the taking. I then looked at d33tah's link to TRESOR and it turns out somebody actually implemented it. Do read up on the caveats and such.

share|improve this answer

Some Googling pointed me to - using it with an encrypted swapfile sounds like a solution.

share|improve this answer
what encrypted swap did you go with? is the swap a ram drive? what do you think of cryptkeeper? – user24408 May 30 '13 at 4:23
CryptKeeper, if you mean the kernel patch which encrypts memory, only works for very old kernels. I don't know if anyone ported it to newer kernels yet, but it'd probably be a pain. – forest Apr 8 at 1:15

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.