{{Header}} {{#seo: |description=ram-wipe - Implementation notes. }} {{title|title= Cold Boot Attack Defense - RAM Wipe Design Documentation }} {{intro| [[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. }} = Design = == cold-boot-attack-defense == Implemented by dracut module [https://github.com/{{project_name_short}}/ram-wipe/tree/master/usr/lib/dracut/modules.d/ cold-boot-attack-defense] (by [[ram-wipe]]). # /usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh runs need_shutdown. # TODO: Does dracut run cryptsetup luksClose during shutdown? The 90crypt module does not have a shutdown hook? grep -r hook /usr/lib/dracut/modules.d | grep shutdown # A dracut cleanup hook is declared in [https://github.com/{{project_name_short}}/ram-wipe/blob/master/usr/lib/dracut/modules.d/40cold-boot-attack-defense/module-setup.sh /usr/lib/dracut/modules.d/40cold-boot-attack-defense/module-setup.sh] (by ram-wipe): inst_hook cleanup 80 "$moddir/wipe-ram-needshutdown.sh" Priority is 80. TODO # During boot, that dracut cleanup hook [https://github.com/{{project_name_short}}/ram-wipe/blob/master/usr/lib/dracut/modules.d/40cold-boot-attack-defense/wipe-ram-needshutdown.sh /usr/lib/dracut/modules.d/40cold-boot-attack-defense/wipe-ram-needshutdown.sh] (by ram-wipe) is calling dracut API function need_shutdown which results in file /run/initramfs/.need_shutdown being created. # In result, at shutdown time when /lib/systemd/system/dracut-shutdown.service (by dracut) runs, /usr/lib/dracut/dracut-initramfs-restore (by dracut), will restore the initramfs and pivot into it. # During shutdown, dracut will run its usual cleanup tasks such as unmounting the root (main) drive. # The shutdown module (by dracut) will source and other shutdown hooks set up by other dracut modules. # At time of writing there were no other dracut modules using the dracut shutdown hook known the the author of this website. # [https://github.com/{{project_name_short}}/ram-wipe/blob/master/usr/lib/dracut/modules.d/40cold-boot-attack-defense/wipe-ram.sh wipe-ram.sh] (by ram-wipe) is the dracut shutdown hook. # A alternative description of the mechanism of dropping back to the initramfs during shutdown can be found under [https://systemd.io/INITRD_INTERFACE/ The initrd Interface of systemd]. # At a very late stage during the shutdown process when all disks were already unmounted by dracut, the wipe-ram.sh dracut shutdown hook is executed. # The shutdown hook runs: * echo 3 > /proc/sys/vm/drop_caches ** To ensure any remaining disk cache is erased by Linux' memory poisoning. Inspired by Tails. https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/usr/local/lib/initramfs-pre-shutdown-hook * sdmem -l -l -v: To wipe the ram using sdmem. ** The parameters -l -l result in a single pass of RAM wiping using zeros. *** This is to optimize for speed. Otherwise RAM wiping could take several minutes. However, the longer the shutdown process is delayed, the more users would disable this feature. Also after wiping the RAM, it could actually be more important to shutdown to aid decay of RAM contents rather than wiping the RAM over and over for minutes before actually removing power. *** When run sdmem manually using these command line parameters it will show "Wipe mode is insecure (one pass with 0x00)" but no evidence that this would be actually insecure could be found. The sdmem manpage refers to Peter Gutmann, but the Gutmann method is about hard drives, not about RAM. No research how many times RAM has to be wiped to be non-recoverable has been found by the author of this website. ** The parameter -v is for verbose output which only results in a progress indicator. ** Any output (default or verbose) is only visible if a [[Recovery#Serial_Console|serial console]] is connected. This is because dracut by default hides output of commands it runs. Redirecting the output of sdmem to /dev/kmsg would result in hundreds or thousands of separate * to be written to the console, each in its own line, which would not actually be useful. For a better progress meter of the RAM wipe process, if needed after user feedback, perhaps some buffer mechanism would have to be implemented. * dmsetup ls --target crypt: To check if all encrypted disks are unmounted. ** Because only if all encrypted disks are unmounted, it will be possible for the kernel to wipe the [[Full Disk Encryption]] (FDE) key from the kernel. ** Deletion of FDE key is considered among the most crucial information to be wiped from RAM because if the FDE key could be recovered from RAM then FDE could be broken. ** Informs the user if all encrypted disks are unmounted in console output. Otherwise shows a warning. Quote [https://tails.boum.org/contribute/design/memory_erasure/ Tails' Memory erasure]:
First, most memory is erased at the end of a normal shutdown/reboot sequence. This is implemented by the [https://tails.boum.org/contribute/design/kernel_hardening/ Linux kernel's freed memory poisoning feature], more specifically: * page_poison * passing "P" to slub_debug * zeroing heap memory at free time (init_on_free=1)
These kernel parameters are implemented in ram-wipe [https://github.com/{{project_name_short}}/security-misc/blob/master/etc/default/grub.d/40_kernel_hardening.cfg /etc/default/grub.d/40_kernel_hardening.cfg]. RAM wipe is omitted in virtual machines (VMs) by default because it is unclear if that could actually lead to the host operating system using swap. Through use of kernel parameter wiperam=force it is possible to force RAM wipe inside VMs which is useful for testing, development purposes. Kernel parameter wiperam=skip is provided to support disabling RAM wipe at shutdown, which might be useful to speed up shutdown or in case should there ever be issues. For potential limitations, the same limitations as under Quote [https://tails.boum.org/contribute/design/memory_erasure/ Tails' Memory erasure] chapter "Limitations" applies. == ram-wipe-exit == dracut module ram-wipe-exit: * The other module dracut module cold-boot-attack-defense is independent. ** The first RAM wiping mechanism is useful irrespective of this supplemental kexec based RAM wipe which might be more prone to bugs. ** The other dracut module cold-boot-attack-defense in its main source code file wipe-ram.sh uses kexec to boot into a new kernel. ** That new kernel is actually the same kernel image but thanks to kexec, the old kernel stops and a new kernel is run which should result in overwriting the old kernel's RAM. ** kexec is used with the --reuse-cmdline parameter for simplicity and to keep already existing RAM wipe related kernel parameters (the linux kernel's freed memory poisoning feature mentioned above). ** Additionally kernel parameter wiperamexit=1 is appended by dracut module cold-boot-attack-defense. ** kexec is used to load a new kernel into the memory so the old kernel memory is overwritten gets overwritten by the new kernel. * Kernel parameter wiperamexit=1 in dracut module ram-wipe-exit results in only wiping the RAM and then rebooting or powering off. * It refrains from mounting the root image. ** In other words, ram-wipe-exit runs at very early boot before mounting the root image. This can is being done using dracut hook pre-udev (because that hook runs before pre-mount). ** Therefore the full disk encryption (FDE) password entry should is not required. ** The RAM wipe is be done during dracut initramfs stage before FDE password is requested / before root disk is mounted. ** The root image is not be mounted at all when kernel parameter wiperamexit=1 is set. * When kernel parameter wiperamexit=1 is set, after RAM wipe at early dracut initramfs stage, the system should is rebooted, powered off depending on the wiperamaction setting, which was set by the previous kernel. * kexec based wipe cannot be based on systemd with Before=unmount.target because unmounting the root disk and using cryptsetup luksClose so the full disk encryption (FDE) key gets wiped from RAM is one of the most important points of RAM wipe. It would need to be After=unmount.target. But at that stage, there is no more disk mounted with tools. Hence, dropping back to initramfs at shutdown is the correct design. * Runs reboot, poweroff, halt as instructed by the previous kernel. {{Anchor|Differences of security-misc Wipe RAM versus Tails Memory Erasure}} = Differences of ram-wipe versus Tails Memory Erasure = Tails memory erasure: * based on Linux memory poisoning * requires initramfs-tools * based on systemd-shutdown /lib/systemd/system-shutdown * requires Tails specific hook scripts such as [https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/usr/local/lib/initramfs-restore /usr/local/lib/initramfs-restore] / /usr/local/lib/udev-watchdog-wrapper * ISO specific / Live boot specific / squashfs specific ** https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/usr/local/lib/udev-watchdog-wrapper ** https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/usr/local/lib/initramfs-pre-shutdown-hook * mixes the panic button / emergency shutdown / ISO removal trigger into the same scripts * blueprints ** https://gitlab.tails.boum.org/tails/blueprints/-/wikis/more_efficient_memory_wipe ** https://gitlab.tails.boum.org/tails/blueprints/-/wikis/more_efficient_memory_wipe/grub ** https://gitlab.tails.boum.org/tails/blueprints/-/wikis/more_efficient_memory_wipe/memtest86plus ram-wipe: * based on Linux memory poisoning and and additional run of sdmem * requires dracut * more generic * should work on any Debian * should be relatively easy to port to any Linux distribution since implemented as a dracut module * should work equally for persistent boot from hard drive, [[grub-live|live boot from hard drive]] or ISO live boot * A [https://forums.whonix.org/t/panic-button-panic-shutdown-buskill-the-usb-kill-cord-for-your-laptop/13755 panic button / panic shutdown / USB kill cord for your laptop] feature is not mixed together with this feature. It should be implemented separately as a standalone feature. = Debugging = * A Kicksecure or Whonix VM using VirtualBox with a virtual [[Recovery#Serial_Console|serial console]] (<-- see this already existing, fully tested and functional documentation on how to set that up) as this can show/persist echo messages even after the VM was already powered off or rebooted. * A boot menu entry to run dracut module ram-wipe-exit without needing to poweroff or reboot (similar to [https://github.com/{{project_name_short}}/grub-live/blob/master/etc/grub.d/11_linux_live grub-live 11_linux_live]). File /etc/grub.d/12_linux_wiperamexit * In Kicksecure / Whonix, package [https://github.com/{{project_name_short}}/debug-misc debug-misc] might be useful (sudo apt update && sudo apt install debug-misc) due to: ** https://github.com/{{project_name_short}}/debug-misc/blob/master/etc/default/grub.d/45_debug-misc.cfg ** https://github.com/{{project_name_short}}/debug-misc/blob/master/etc/sysctl.d/40_debug-misc.conf ** https://github.com/{{project_name_short}}/debug-misc/blob/master/etc/dracut.conf.d/40_debug-misc.conf ** (these files could be used standalone / manually installed or "bulk" installed though installing the debug-misc package) (This file would be shipped out commented by default. Only useful for development / debugging.)
#!/bin/sh

## Copyright (C) 2022 - 2023 ENCRYPTED SUPPORT LP 
## See the file COPYING for copying conditions.

## Untested!

set -e

#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX wiperamexit=1 wiperamaction=reboot"
#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX wiperamexit=1 wiperamaction=poweroff"
#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX wiperamexit=1 wiperamaction=halt"

GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX wiperamexit=1 wiperamaction=debug"

export GRUB_CMDLINE_LINUX

if test -x /etc/grub.d/10_linux ; then
	/etc/grub.d/10_linux
fi
sudo update-grub
Maybe useful during development: * grep -r pre-udev --color /usr/lib/dracut A [https://forums.whonix.org/t/panic-button-panic-shutdown-buskill-the-usb-kill-cord-for-your-laptop/13755 panic button / panic shutdown / USB kill cord for your laptop] feature is not mixed together with this feature. It should be implemented separately as a standalone feature. = Status of initramfs-tools Support = Support for initramfs-tools is not planned by the authors of ram-wipe. No progress on initramfs-tools support should be expected. The problem with initramfs-tools support is, that in contrast to dracut, while initramfs-tools supports initrd (initial ramdisk) it does not support exitrd (exit ramdisk). dracut supports both, initrd (initial ram disk at boot time) as well as exitrd (dropping back to initial ramdisk at shutdown time). A feature request has been posted against the [https://packages.debian.org/search?keywords=initramfs-tools Debian initramfs-tools] package [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778849 Support restoring initrd on shutdown and pivoting into it]. Contributors wishing to add initramfs-tools support to ram-wipe, should add exitrd support to upstream, original initramfs-tools. As a starting point, Tails has implemented [https://gitlab.tails.boum.org/tails/tails/-/blob/master/config/chroot_local-includes/usr/local/lib/initramfs-restore initramfs-restore] which might help to look at, provide inspiration when developing the exitrd functionality for initramfs-tools. The Tails initramfs-tools exitrd implementation would have to be made generic, meaning made unspecific to Tails (no code references to other Tails specific code) and made acceptable for the initramfs-tools developers for inclusion into the upstream source code. However using the Tails implementation as a starting point is of course not a strict requirement. Once initramfs-tools gets exitrd support, it might be easy to add initramfs-tools support to ram-wipe. = Development TODO = * security testing: similar to https://gitlab.tails.boum.org/tails/blueprints/-/wikis/more_efficient_memory_wipe/memtest86plus * A number of [[Ram-wipe#ram-wipe_Known_Issues|ram-wipe known issues]] requires fixing. * SecureBoot breaks kexec = ram-wipe Testing inside a VM = '''1.''' Platform specific notice. * Other than Qubes OS: No special notice. * Qubes OS: Not for Qubes OS. '''2.''' Install ram-wipe because it's not installed by default in VMs because it's normally not needed there. {{Install_Package|package= ram-wipe }} '''3.''' Add the wiperam=force kernel parameter to the grub configuration because otherwise ram-wipe will be skipped inside VMs. {{CodeSelect|code= echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT wiperam=force"' {{!}} sudo tee -a /etc/default/grub.d/50_user.cfg }} '''4.''' Update the grub configuration. {{CodeSelect|code= sudo update-grub }} '''5.''' Reboot {{CodeSelect|code= sudo reboot }} '''6.''' Set up a virtual serial console. A virtual serial console helps to read all the journal kernel messages during early boot and shutdown. Can be set up as per [[Recovery#Serial_Console|serial console documentation]]. Only a read-only serial console was somewhat recently tested and should suffice. An interactive serial-console might not be required. '''7.''' Status. Now a serial console should nicely show the output during boot and shutdown of ram-wipe. '''8.''' Bug [https://github.com/dracutdevs/dracut/issues/1888 dracut should unmount the root encrypted disk `cryptsetup luksClose` during shutdown] will not be reproducible because Kicksecure images do not use full disk encryption. As a workaround, install Debian bookworm using Debian DVD ([[Debian Tips]]), then install Kicksecure as per [[Debian|distribution morphing Debian into Kicksecure]] instructions. Then re-apply the instructions listed here. = Forum Discussion = https://forums.whonix.org/t/is-ram-wipe-possible-inside-whonix-cold-boot-attack-defense/5596 = See Also = * [[Dev/RAM Wipe Old Notes|RAM Wipe Archived Development Notes]] * [[Cold Boot Attack Defense]] * [[ram-wipe|ram-wipe User Documentation]] * https://github.com/{{project_name_short}}/ram-wipe = Footnotes= {{Footer}} [[Category: Design]] [[Category: Development]]