Some documentation on cold boot attack defense is indeed required.
I was wondering to add it here: Full Disk Encryption (FDE) (FDE) - but strictly while it matters a lot for FDE it also matters for non-FDE and use with Live Mode for Kicksecure. Created a stub here and added links to it:
In summary: says cannot be implemented using systemd. Should be done by the kernel.
Quote Lennart Poettering:
Uh, we can’t do that from userspace, we don’t even et access to that. This is something that needs to be implemented in the kernel, for example with a magic sysrq thing.
I think this feature requests has merits, but it really needs to be filed against the kernel as a feature request, systemd is not the right place where we could implement that.
Request that the firmware clear the contents of RAM after a reboot using the TCG Platform Reset Attack Mitigation specification. This protects against an attacker forcibly rebooting the system while it still contains secrets in RAM, booting another OS and extracting the secrets. This should only be enabled when userland is configured to clear the MemoryOverwriteRequest flag on clean shutdown after secrets have been evicted, since otherwise it will trigger even on clean reboots.
So the kernel has support for RAM wipe when firmware supports it.
Does the kernel also support RAM wipe if the firmware does not support it? If no, worth writing a feature request against the kernel?
No, the firmware is what wipes RAM. The kernel just enables that feature in the firmware. The kernel isn’t able to wipe all of the RAM itself which is why it must be done at a lower level like the firmware or Tails’ magic.
Some things such as importantly, full disk encryption (FDE) is handled by the kernel. Probably user space couldn’t wipe the kernel memory holding the FDE key (unless there is a kernel API for that which would be related but separate).
On that view, wiping RAM might make sense for a live system such as Tails or Whonix / Kicksecure Host Live Mode (specifically when not using encrypted persistence) but would it also make sense for an FDE Whonix-Host or FDE Kicksecure-Host?
Without actual memory forensics we would not really know how severe any RAM wipe leftovers would be. If it includes the FDE key, then wiping the rest was worth little.
Even if RAM wipe by Linux kernel without firmware support would not be complete it could still per perfect and it could certainly better than anything doable in user space such as the Tails implementation. The kernel can certainly has the power to wipe any program from RAM since these are below the kernel in the hierarchy. And the kernel would not have to wipe things where the kernel knows that wiping these memory parts is not important because these are public anyhow, not private/secrets, or recoverable from the hard drive (assuming unencrypted /boot).
Any userspace to kernel memory has been greatly limited by security changes to Linux in recent years. A lot of attacks were basically about doing that to root the system. Unlikely that the memory erasure test can tell you anything about data remnance related to the kernel. This is done in more complicated way according to the cold boot attack papers.
You cannot trust third party firmware to do the wiping for you as they could be buggy or maliciously designed to not do a good job.
You should make a poll to see how many DRAM 2 systems are in use and or have non-removable batteries. Note that for the latter this isn’t guaranteed to aid data remnance, but may in some cases do unlike older RAM families which will always have slower data decay.
Summary: only a kernel solution makes sense and it is only worth pursuing if a substantial (20%+) number of systems need it.
Yes, we can’t wipe as much RAM without it but it seems complicated to implement.
The kernel already has a RAM wiping function, init_on_free which is what Tails uses. Tails just improves this and makes it wipe more by returning to the initramfs upon shutdown and unmounting the filesystem, thereby freeing more memory and having it wiped.
This essentially wipes all user space memory which is the most important part but leaves some kernel memory as the kernel cannot wipe itself hence why a complete implementation must be done at a lower level.
"cryptsetup close" of root device during shutdown is already implemented.
iff your initrd/distro of choice do so. For the root disk it doesn’t matter what systemd does, it matters what the initrd/distro do. hence ping the maintainers of those.
AFAICT dracut has dracut-shutdown(8) which you can extend at will, or
convince the maintainer to ship the required logic for everyone.
However Debian’s default initramfs, namely initramfs-tools(7) currently
has no interface to hook into at shutdown, and init doesn’t even hand
execution over to the initramfs during the shutdown phase (#778849).
When such an interface is available we can ship shutdown scripts into
cryptsetup-initramfs.
Note: There’s a chance it might freeze a VM or host operating system. It didn’t happen to me yet but better to have this in mind.
Installation:
sudo apt update
sudo apt install secure-delete time
Disabling swap is required. Otherwise smem would fill up all RAM and the system highly likely to permanently freeze.
sudo swapoff --all
To verify that swap is off:
sudo swapon --show ; echo $?
Expected output:
0
Built-in help:
sudo sdmem -h
Default mode:
time sudo sdmem
Verbose mode:
time sudo sdmem -v
Probably better because it shows some progress.
For just a single pass of RAM wipe with zeros:
without verbose mode:
time sudo sdmem -l -l
with verbose mode:
time sudo sdmem -l -l -v
The time command is optional. Can be dropped. But useful here to measure how long it takes.
Default mode does, quote:
27 passes with special values defined by Peter Gutmann.
Not sure that is really necessary because if I remember right, Peter Gutmann was about hard drives, not RAM. Is there any research how many passes RAM wipe requires?
Should RAM wipe be skipped inside VMs for faster reboot / shutdown times? I am not sure about the dynamics of RAM wipe in VMs. In worst case, the VM might start use swap file on the host operating system. Therefore I tend to say RAM wipe should be skipped if a VM is detected.