Is RAM Wipe possible inside Whonix? Cold Boot Attack Defense

Patrick · January 31, 2025, 11:12am

Thoughts dereferenced from the scratchpad noise. | Research of RAM data remanence times, part 2

Patrick · April 17, 2025, 7:17pm

Clarify ram-wipe dependencies

opened 07:04AM - 17 Apr 25 UTC

I tried to install and run `ram-wipe` lately. The installation was done via self…-built packages from repositories: https://github.com/Kicksecure/ram-wipe (from commit `99cddffc08041eb896cc4295e118a9831bf50d0a`) and https://github.com/Kicksecure/helper-scripts (from commit `7534ee5874277fdebce8d91bebee7e0b02c8acdc`). The installation went without errors. But when rebooting and powering on I did not notice anything apart from: ```bash [ 350.165760] cold-boot-attack-defense-kexec-prepare[3815]: INFO: wiperamaction: reboot [ 350.184377] cold-boot-attack-defense-kexec-prepare[3815]: 'disabled' (mokutil_output: 'SecureBoot disabled') [ OK ] Stopped ram-wipe-kexec-prepare.ser�.|oot Attack Defense Reboot RAM Wipe. ``` The result is different from [what was expected](https://www.kicksecure.com/wiki/Ram-wipe#Sample_Printout). I did not add any Linux Kernel boot arguments during tests. I did not use Secure Boot or any encrypted partitions during tests. The tests were done on Debian Trixie. The question is, are Secure Boot, encrypted partitions or any Linux Kernel boot arguments required for `ram-wipe` to launch? Because [the installation guide](https://www.kicksecure.com/wiki/Ram-wipe) did not mention anything related directly, but from brief code exploration I know that Secure Boot is being checked and the entire `ram-wipe` relies on Kernel boot args. I am going to look closer on `ram-wipe` code, as well as check, whether RAM is actually being zeroed, but any help will be appreciated.

Patrick · May 7, 2025, 9:08am

Patrick · May 7, 2025, 12:08pm

Patrick · August 22, 2025, 10:11am

github.com/Kicksecure/ram-wipe

Remove sdmem and kexec (second stage)

master ← zarhus:master

opened 08:57AM - 21 Aug 25 UTC

aronowski

+3 -190

As per testing kernel memory zeroing with `init_on_free=1`, remove all the refer…ences to `sdmem` and the second RAM wipe pass. See https://www.kicksecure.com/wiki/Dev/RAM_Wipe#ram-wipe_improvements for more information. An analysis of the `init_on_free` mechanism in the context of ram-wipe has been described [here](https://beta.blog.3mdeb.com/2025/2025-08-12-ram-wipe-further-analysis/). The mechanism [might use some future improvements](https://beta.blog.3mdeb.com/2025/2025-08-12-ram-wipe-further-analysis/#summary) for people with high operational security requirements, when wiping the LUKS secret key is not enough - perhaps as part of improving this draft PR. While it has `sdmem` and the second RAM wipe pass removed, it can be reworked further to clean up more related, unnecessary code. ## Changes References to sdmem and kexec have been removed. Mentions of second stage have been rewritten to mention the only one stage. ## Mandatory Checklist - [x] Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements: [Terms of Service](https://www.kicksecure.com/wiki/Terms_of_Service), [Privacy Policy](https://www.kicksecure.com/wiki/Privacy_Policy), [Cookie Policy](https://www.kicksecure.com/wiki/Cookie_Policy), [E-Sign Consent](https://www.kicksecure.com/wiki/E-Sign_Consent), [DMCA](https://www.kicksecure.com/wiki/DMCA), [Imprint](https://www.kicksecure.com/wiki/Imprint) ## Optional Checklist The following items are optional but might be requested in certain cases. - [x] I have tested it locally - [ ] I have reviewed and updated any documentation if relevant - [ ] I am providing new code and test(s) for it

Patrick · August 22, 2025, 10:14am

https://beta.blog.3mdeb.com/2025/2025-08-12-ram-wipe-further-analysis/

EDIT: Fixed link.

Patrick · August 25, 2025, 3:12pm

Quote @arraybolt3 in Upgrade `sysctl` settings and docs on kernel panics by raja-grewal · Pull Request #313 · Kicksecure/security-misc · GitHub

By forcing instant reboots what we have done is at least begin wiping some memory contents that were previously frozen in place.

This makes me wonder if some form of RAM wiping that happens on bootup might be useful…