BLUF: I'm using an SSD on my system, so my primary reason to use tmpfs to increase the life of my drive by moving high read/write files to volatile memory. But from a security point of view, I'd also like to know if it would make any sense to encrypt volatile memory for security purposes.

Current System Specs:

OS:                 Custom Arch Linux Build

RAM:                6GB  
My build rarely goes over 1GB of RAM usage. 

Primary Drive:      128GB SSD 
    Holds the OS, setup with LUKS on LVM for full disk (-boot) encryption. 

Secondary Drive:    1TB HDD (much slower) 
    For long term storage and backup (fully encrypted).


As it stands once my system shuts down, a user requires the key to be able to access my system hard drive. However, from an anti-forensics point of view the RAM would be viable target for recovery for at least a few minutes after shutdown (possibly longer with some air-duster hacking).

My question is: To prevent a cold-boot recovery in this very unlikely case, would encrypting the contents of a tmpfs with something like dm-crypt be a viable option?

Basically I'm asking for a check on logic. What possible holes am I missing?

  • Encrypting /tmp with a random key should do the trick, yes. I'm not sure how to achieve this directly, but maybe you could mount some arbitrary location into tmpfs, create an encrypted loopback file there, and mount that one's content on /tmp? I'm not even sure if the indirection is necessary... May 13, 2015 at 18:01
  • With that amount of RAM,I'd use /tmp as shmfs.
    – ott--
    May 13, 2015 at 20:09

1 Answer 1


If you consider that attackers may recover the RAM contents (a cold boot attack) then you have to take into account that attackers may recover the RAM contents. Your /tmp filesystem is used by application as a temporary repository for some data elements, but the same applications read it back -- into RAM. That is, the RAM-based filesystem is unlikely to contain the only copy in RAM for the sensitive data. Whatever you do with /tmp, be it encryption or anything else, will only be a partial solution.

Another point is that an encrypted filesystem is still a storage for files, that the live system can read and write. Thus, even if encrypted, the decryption key (in the live machine) must be somewhere in it... i.e. in the RAM. If attackers can read RAM, then they can recover that key, and remove all your encryption.

What you could do to lower the probability of data recovery by attackers is to make sure you empty the RAM as part of the shutdown procedure. This would entail, from the last process running in the machine:

  • Unmounting /tmp.
  • Deactivating swap space (by the way, do you encrypt your swap partition ? Alternatively, you could simply deactivate swap; I do that on my laptop).
  • Filling the RAM with random bytes (or zeros), allocating pages and filling them until allocation fails. At that point, you know that the kernel found all available RAM and filled it with randomness; this would include all pages that were corresponding to the RAM-based /tmp.

From what I explain above, such a procedure would both be necessary anyway (since sensitive data may lurk outside of /tmp), and makes any encryption of /tmp irrelevant.

Remaining issues are that non-application RAM, in the kernel space, might still need some cleansing; and a shutdown procedure has any effect only when a shutdown is applied. If the attacker steals the live machine, then he may pull the plug (or the battery, for a laptop) to get a fresh, live snapshot of the RAM. Encryption would not help you there (because the encryption key would be part of the snapshot).

  • Thank you for that well thought out reply Dr. Pornin. I don't use swap on my system currently. My system rarely goes above 1GB of RAM, and I currently have 6GB installed. As to the RAM wiping, prior to shutdown, what would something like that look like? Do know of any current implementations of this? May 13, 2015 at 19:58

You must log in to answer this question.

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