In order to protect against memory recovery such as cold boot attack, the system RAM is overwritten when Tails is being shutdown or when the boot medium is physically removed.
The big picture
The previous 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.
In order to erase the biggest possible part of the system memory, the hereby described new implementation, shipped in Tails 0.7, 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.
The Linux kernel and initramfs used to erase the memory are the same as the ones normally used by a Tails system... that actually includes some bits of code dedicated to this mission.
An initramfs-tools hook includes the necessary files in the initramfs
at build time. A runtime init-premount script either does nothing, or
erases memory before shutting down or rebooting the system; its
behaviour depends on the
sdmem kernel command line parameter value.
sdmemopts kernel command line parameter allows
fine tuning the options passed to the
- config/chroot local-includes/usr/share/initramfs-tools/hooks/sdmem
- config/chroot local-includes/usr/share/initramfs-tools/scripts/init-premount/sdmem
sdmemopts are appended to the fresh kernel command
line parameters, when memory erasure is triggered, by the
tails-kexec initscript that is itself parameterized by the usual,
slightly customized, kexec-tools configuration file.
Actual memory erasure process
The software that performs the actual memory erasure is sdmem, which
is part of the secure-delete package. sdmem is
called using the
-v (verbose mode) option to give feedback to the
user, as well as the
-llf options: memory is only overwritten once
with zeros; this is the fastest available mode, and is enough to
protect against every memory forensics attack we know of.
Different kinds of events trigger the memory erasure process. All lead
to run the
First, the memory erasure process is triggered at the end of a normal
shutdown/reboot sequence. This is implemented by slightly modifying
the System V initscripts shipped by the
kexec-tools Debian package:
kexec-load initscript, that normally only runs at reboot time,
is enabled to run at shutdown time as well. A custom
initscript replaces the
kexec one in order to support the case when
the boot medium is not available anymore at the time this script runs;
it also provides an improved user interface more suitable for Tails
target users needs. Finally, the standard Debian
initscripts are taken over by having the
tails-kexec initscript run
before they have a chance to be run (implemented with
in the LSB headers).
- config/chroot local-patches/run kexec-load on halt.diff
- config/chroot local-patches/disable kexec initscript.diff
- config/chroot local-includes/etc/init.d/tails-kexec
- config/chroot local-hooks/52-update-rc.d
Second, the memory erasure process is triggered when the boot medium
is physically removed during runtime (USB boot medium is unplugged or
boot CD is ejected). This is implemented by a custom
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
- config/chroot local-includes/usr/local/sbin/udev-watchdog-wrapper
- config/chroot local-includes/usr/src/udev-watchdog.c
- config/chroot local-hooks/52-udev-watchdog
- config/chroot local-includes/etc/init.d/tails-sdmem-on-media-removal
- config/chroot local-hooks/52-update-rc.d
Making sure needed files are available
memlockd daemon, appropriately configured, ensures every file
needed by the memory erasure process is locked into memory from boot
to memory erasure time.
Care have to be taken during the shutdown sequence, as
memlockd is normally
unloaded before the
kexec happens. This is done by preventing
be stopped, and also by adding memlockd PID to the list of process that are
omitted by the
sendsigs script (responsible for sending TERM and KILL signals
to remaining processes).
- config/chroot local-includes/etc/memlockd.cfg
- config/chroot local-patches/keep memlockd on shutdown.diff
- config/chroot local-includes/etc/init.d/tails-reconfigure-memlockd
Since this process can take a while the user can leave the computer and let it finish on its own after removing the boot medium, or simply turn it off if he or she is not worried about this attack: if Tails was booted from a CD it is ejected before the memory wiping is started, and if it was booted from a USB drive it can be removed as soon as the memory wiping has been started.
A short but visible message, displayed for a few seconds, explains the user what is going to happen.