English isn’t my native language, so I used llm to translate and improve the comment. I’ll also note that whonix/kicksecure also uses a function similar to tails to clear RAM when shutting down the OS.
Related: ram-wipe - Wipe RAM on shutdown and reboot
///
However, while reviewing the code, I noticed a fundamental flaw in how the 40ram-wipe dracut module is implemented. Currently, it does not actually wipe the RAM.
In wipe-ram.sh, the script executes:
echo 3 > /proc/sys/vm/drop_caches
While the comment references the Tails OS pre-shutdown hook, drop_caches alone does not overwrite or wipe memory . It merely instructs the Linux kernel to release pagecache, dentries, and inodes.
In Tails OS, dropping caches is only a preparatory step. It forces file caches into “free” memory so that their actual memory-wiping mechanism can overwrite them.
Because the script stops at dropping caches, all active process memory (anonymous memory), encryption keys, and active buffers remain untouched in the RAM until the power naturally fades out, leaving the system vulnerable to Cold Boot Attacks.
How to fix this and achieve a true RAM wipe:
1. Add a real memory wiper (e.g., sdmem):
After dropping the caches, you need a tool that actually allocates and overwrites the freed memory. You can use sdmem (from the secure-delete package). The logic in wipe-ram.sh should be updated to run something like:
sync
echo 3 > /proc/sys/vm/drop_caches
sync
sdmem -f -ll # Overwrites all available free RAM with zeros
(Note: Users would need to install the secure-delete package in dom0 for this).
2. Add Kernel memory poisoning for Dom0:
Your script beautifully adds init_on_free=1 init_on_alloc=1 and xen_scrub_pages=1 to the DVMs via qvm-prefs, which is great! However, these parameters are missing in the custom GRUB entries for Dom0 (40_custom).
If you add init_on_free=1 init_on_alloc=1 to the Dom0 GRUB kernel parameters, the Linux kernel will automatically zero out memory pages as soon as they are freed by drop_caches or when processes are killed during shutdown.
Combining init_on_free=1 in Dom0 GRUB with drop_caches and sdmem during shutdown will give this script a true, Tails-grade anti-forensic RAM wipe.
Thanks again for your hard work on this project! I hope this feedback helps make it even more secure.
P.S. A couple of ideas for “Paranoid” / Ultimate Hardening:
Since we are on the topic of maximum anti-forensics and security, I have two more architectural suggestions that could take the Live modes (especially the Zram mode) to an absolute “paranoid” level against advanced persistent threats (APTs):
1. On-the-fly Physical Drive Disconnection (For Zram mode)
Since the Zram mode copies the entire system to RAM, the physical SSD/HDD is technically no longer needed for the OS to function during that session.
If we logically disconnect the block device via sysfs after the live boot, the physical disk completely disappears from the OS.
Proposed Implementation:
Since users might have multiple NVMe or SATA drives, the script shouldn’t hardcode nvme0 or sda. Instead, it can dynamically detect the underlying physical parent disk of the Qubes LUKS container.
To make this secure-by-default, the installer script can automatically append a custom kernel parameter (e.g., qubes.detach_disk=1) to the GRUB custom menu entries (/etc/grub.d/40_custom).
Then, a startup script (like swapoff.sh) checks /proc/cmdline. If the flag is present, it dynamically detects and detaches the drive:
if grep -q "qubes.detach_disk=1" /proc/cmdline; then
# Get the partition device (e.g., /dev/nvme0n1p2)
LUKS_PART=$(blkid -t TYPE="crypto_LUKS" -o device | head -n1)
# Find the parent physical disk (e.g., nvme0n1)
PARENT_DISK=$(lsblk -no pkname "$LUKS_PART" 2>/dev/null)
# Trigger removal based on device type
if [ -n "$PARENT_DISK" ]; then
if [[ "$PARENT_DISK" == nvme* ]]; then
echo 1 > /sys/block/"$PARENT_DISK"/device/device/remove
else
echo 1 > /sys/block/"$PARENT_DISK"/device/delete
fi
fi
fi
Why this approach is great: It implements a solid “secure by default” model. The disk is automatically isolated on every live boot. If a user needs to keep the disk attached for some reason (e.g., to mount a secondary partition) or if the hardware behaves unexpectedly, they can easily opt-out by pressing e in the GRUB menu during boot and deleting the qubes.detach_disk=1 flag.
2. Linux Kernel Lockdown (lockdown=confidentiality)
Adding the lockdown=confidentiality parameter to the GRUB menuentry for the Live modes would be a massive security boost. Even if the Live Dom0 is compromised, this native Linux feature prevents the root user from modifying the running kernel, reading raw memory (/dev/mem), or accessing low-level hardware ports (like SPI flash). This mitigates the risk of malware trying to flash a malicious UEFI/BIOS firmware to establish hardware-level persistence from the live environment.
I will add it to script now.