Is RAM Wipe possible inside Whonix? Cold Boot Attack Defense

Debian feature request:
Wipe LUKS Disk Encryption Key for Root Disk from RAM during Shutdown to defeat Cold Boot Attacks from Initial Ramdisk (initramfs-tools or dracut)

Control: severity -1 wishlist
Control: reassign -1 cryptsetup-initramfs
Control: block -1 by 778849


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


Support restoring initrd on shutdown and pivoting into it (#778849)

Maybe a good reason for replacing initramfs-tools with dracut.

Debian dracut feature request:
Wipe LUKS Disk Encryption Key for Root Disk from RAM during Shutdown to defeat Cold Boot Attacks from Dracut Initramfs

dracut upstream feature request:

1 Like

dracut upstream pull request:

Review welcome.

Could you please test the sdmem(1) — secure-delete — Debian bookworm — Debian Manpages command. Check the timing. How long the command requires to complete. Because the same time will be required on every reboot / shutdown.

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.


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:


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.

1 Like

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…).

1 Like

Huge progress has been made.

Implemented by dracut module cold-boot-attack-defense (by security-misc).

Will in near future be available for Kicksecure hosts. Should be easy to port to other Linux distributions.

See design documentation, review welcome:

More documentation, call for testers coming in near future.

1 Like

Future design (additional kexec based RAM wipe) has been elaborated:

I’ll try to assign this task to implement also the future design to a contractor. Hopefully there will be a good news soon.

[systemd-devel] What is the shutdown sequence with systemd and dracut?

Migration from GitHub - Kicksecure/security-misc: Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - to

is in process.

This was done.

This was implemented.

ram-wipe wipes the RAM twice during poweroff/reboot.

  • 1. RAM Wipe Pass 1/2: During poweroff/reboot.
  • 2. RAM Wipe Pass 2/2: It kexec’s into a new kernel for the purpose of overwriting the first kernel’s memory and performs a second ram wipe pass.

A dedicated user documentation wiki page has been created:

If the following feature request gets implemented in memtest86+ that might result in a major security improvement for ram-wipe: