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 (
When such an interface is available we can ship shutdown scripts into
Maybe a good reason for replacing initramfs-tools with dracut.
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:
dracut upstream pull request:
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 $?
sudo sdmem -h
time sudo sdmem
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
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.
Wipe mode is insecure (one pass with 0x00)
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…).
Huge progress has been made.
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.
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.
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 - https://www.kicksecure.com/wiki/Security-misc 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: