In order to protect against memory recovery such as cold boot attack, most of the system RAM is overwritten when Tails is being shutdown or when the boot medium is physically removed. Also, memory allocated to processes is erased upon process termination.

The big picture

Tails now relies on the Linux kernel's freed memory poisoning feature.

But memory poisoning only works when memory is actually freed, and a regular shutdown would not free the memory used by the aufs read-write branch. So we use the systemd-shutdown ability to return to the initramfs, to ensure the root filesystem is unmounted.

The initramfs is unpacked in /run/initramfs at boot time:

… so that the copy of systemd-shutdown that runs in the real, non-initramfs system can switch root into /run/initramfs, and run another copy of systemd-shutdown that's included in the initramfs. That one will unmount all filesystems, run a custom hook that helps us automatically test this behavior, and finally perform the requested poweroff/reboot action.

Triggers

Different kinds of events trigger the memory erasure process. All lead to run the shutdown process that erases memory.

First, most memory is erased at the end of a normal shutdown/reboot sequence. This is implemented by the Linux kernel's freed memory poisoning feature, more specifically:

  • page_poison
  • passing "P" to slub_debug

Automated tests ensure that the most important parts of memory are erased this way.

Second, the memory erasure process is triggered when the boot medium is physically removed during runtime (USB boot medium is unplugged or boot DVD is ejected). This is implemented by a custom udev-watchdog program monitors the boot medium; it's run by a wrapper, started at boot time, that brutally invokes the memory erasure process, bypassing other system shutdown scripts, when this medium happens to be physically removed.

Making sure needed files are available

The memlockd daemon, appropriately configured, ensures every file needed by the memory erasure process is locked into memory from boot to memory erasure time.

Limitations

As discussed in an email thread with the authors of PAX_MEMORY_SANITIZE, kernel memory poisoning does not clear all kinds of memory once it's freed:

  • we enable free poisoning for the buddy allocator and the slub/slab ones, but there may be other ways the Linux kernel allocates memory, that are not subject to poisoning;
  • on shutdown all process memory is freed (and thus erased), but some kernel memory is not erased on shutdown, and is currently not erased.

It's not obvious that our previous approaches (see below) did any better, and this one is much more reliable, so we think this trade-off is the most sensible one with the resources and skills currently available for Tails.

Obsolete approaches

The initial implementation of the Tails memory erasure feature suffered from flaws that were demonstrated by external audit. In short, it only erased free memory and let data in the aufs read-write branch in recoverable state.

Then, in order to erase the biggest possible part of the system memory, a new implementation, shipped from Tails 0.7 to 2.12, runs in a fresh environment provided by a newly started Linux kernel. This way, a given part of the memory either is used by the memory erasure process itself or it is considered as free and thus erased by this process; in any case, it is at least overwritten once.

Sadly, this approach suffered from severe usability and reliability problems (e.g. #12354, #11786). So it was removed in Tails 3.0.