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.
secure-delete* package name in debian (sdmem: secure-delete memory)
Wipe mode is secure (38 special passes)
Using /dev/urandom for random input.
real 1m40.819s
user 0m0.072s
sys 0m0.163s
Wipe mode is insecure (one pass with 0x00)
real 0m0.503s
user 0m0.008s
sys 0m0.089s
Happen to me, i opened xfce-terminal and start moving it right and left until the screen freezed permanently (play for less than 3 minutes with anything like browse some stuff and open close terminal…).