.png){kind=small}
This post will follow up on our journey with the secure ram-wipe solution. After diving deep into its capabilities recently, we are excited to share our heartfelt discoveries of how our modified, simplified version fiercely protects your data from unseen RAM-based attacks. Join us in unveiling this essential defense that could change the future of operational security.
This research has been supported by Power Up Privacy, a privacy advocacy group that seeks to provide support to privacy projects so they can accomplish their objective of improving the world.
Introduction
The init_on_free boot option enables a mechanism in Linux that zeroes out
memory after it has been freed. According to its relevant thread in the Linux
Kernel Mailing
List,
Enabling init_on_free also guarantees that pages and heap objects are initialized right after they’re freed, so it won’t be possible to access stale data by using a dangling pointer.
[…]
The init_on_free feature is regularly requested by folks where memory forensics is included in their thread models.
A good approach to operational security involves the knowledge of how exactly one’s tools operate and what their limitations are. It would be disastrous to expect a workstation with anti-memory forensics mechanisms to fail at the most unexpected time and place. As the Kicksecure documentation on ram-wipe suggests, several ram-wipe components might require improvements.
Today, we will explore an alternative: whether it’s sufficient to replace the
aforementioned troublesome mechanisms with the kernel-supplied init_on_free
option to protect against user space information disclosure. We’ll try to
perform the same warm boot attack as last
time
and see how much data we can recover.
Testing methodology and tools
Just like in our earlier
exploration,
we will experiment with the same EFI
application for determining the
locations of EFI structures and dumping the memory after a system reboot.
Furthermore, we will use the Dasharo firmware,
v0.2.1,
which has proven itself as a stable, mature solution for both production use
and test platforms. We will modify the ram-wipe
tooling
by removing the non-robust sdmem mechanism and the second wipe
pass, and
relying on the init_on_free option supplied as a GRUB
drop-in.
At last, we will analyze the dumped memory, if no user space information
disclosure took place, especially the LUKS secret key.
From power on to power down, this diagram provides a high-level overview of the updated ram-wipe installation in action.
Testing environment
We will once
again
use Debian Trixie installed on QEMU
with Dasharo as our test
system, with rootfs and swap space encrypted with LUKS. Then, we will
install our modified version of ram-wipe with no sdmem mechanism, and only
one wiping
stage.
After Debian has been installed, we can dump the LUKS secret key for future comparison:
1user@debian:~$ sudo cryptsetup luksDump --dump-master-key /dev/sda3
2
3WARNING!
4========
5The header dump with volume key is sensitive information
6that allows access to encrypted partition without a passphrase.
7This dump should be stored encrypted in a safe place.
8
9Are you sure? (Type 'yes' in capital letters): YES
10Enter passphrase for /dev/sda3:
11LUKS header information for /dev/sda3
12Cipher name: aes
13Cipher mode: xts-plain64
14Payload offset: 32768
15UUID: 00b4b79c-209a-4dcf-adf3-7e310778f583
16MK bits: 512
17MK dump: 88 fb 2f aa 42 be 5c cd 6b f0 2f 32 5d e8 e6 4a
18 b6 31 41 67 62 35 79 ab 56 ca 65 ce 18 ff b5 18
19 60 1a 95 c1 0f 7e ea 5c c4 9d 8e 62 42 b8 50 ca
20 af 80 a9 87 84 f7 cb 3c 25 d4 15 f1 c6 1f 6b 6a
Important note: This is a laboratory setting, hence why the key disclosure was done on purpose. Do not share your secrets in production environments.
Currently, the initramfs-tools utility supplied by Debian does not support the
functionality required by
ram-wipe.
Therefore, we migrate to dracut:
|
|
Then, as the Kicksecure documentation suggests, we add the text
|
|
to /etc/dracut.conf.d/fix.conf and regenerate initrd:
|
|
Next, we install the modified version of
ram-wipe
and its helper-scripts dependency:
|
|
We can confirm that dracut is being used, as well as ram-wipe being executed
just before the system is restarted:
1Broadcast message from root@debian on pts/0 (Thu 2025-08-14 03:28:17 EDT):
2
3The system will reboot now!
4
5user@debian:~$
6device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
7at24 0-0050: supply vcc not found, using dummy regulator
8[ OK ] Stopped session-2.scope - Session 2 of User user.
9[ OK ] Stopped user@110.service - User Manager for UID 110.
10[...]
11[ 42.017416] watchdog: watchdog0: watchdog did not stop!
12[ 42.474323] dracut INFO: wipe-ram.sh: RAM extraction attack defense... Starting RAM wipe pass during shutdown...
13[ 42.501159] dracut INFO: wipe-ram.sh: RAM wipe pass completed, OK.
14[ 42.502837] dracut INFO: wipe-ram.sh: Checking if there are still mounted encrypted disks...
15[ 42.508801] dracut INFO: wipe-ram.sh: Success, there are no more mounted encrypted disks, OK.
16[ 42.530125] reboot: Restarting system
Modified ram-wipe’s warm boot attack tests
The testing steps are the same as in our earlier laboratory, except there is only one stage. We will
- Boot to our EFI application and choose option 1 to write the pattern.
- Reboot to the application and select option 2 to exclude RAM modified by firmware.
- Reboot to our Debian installation, decrypt the
rootfsvolume, and reboot to run ram-wipe. - Reboot to the application and dump memory.
The available memory ranges received by the EFI application are:
|
|
With the following pages and addresses excluded (reserved for firmware):
|
|
By reading /proc/iomem, we can see that the kernel is loaded under the
following addresses, which should be excluded from the analysis:
|
|
Now that we have the memory dump in the files:
2025_08_14_07_28_0x0000000000001000.csv2025_08_14_07_28_0x0000000000100000.csv2025_08_14_07_28_0x0000000001630000.csv2025_08_14_07_29_0x000000007BD48000.csv2025_08_14_07_29_0x000000007FC00000.csv2025_08_14_07_29_0x000000007FD20000.csv
it’s time to analyze them. The idea is simple: check the dumps for the memory being zeroed, or containing the pattern written by the EFI application. Otherwise, check them for information, which could be related to user space memory. Most importantly, check if there are keys still residing, in particular the LUKS secret key we printed earlier.
The following regions are indeed zeroed or contain the pattern:
|
|
The next ones are more complex. One idea for a basic static analysis is to run
the strings program on them and analyze the printed text. While there are
some human-readable text snippets, there is no indication of user space memory
being present.
|
|
The last two files are quite big. Therefore, it might be worthwhile to decompose the analysis into multiple steps: let’s extract the human-readable text to separate files first, and then check those files for any user space information disclosure.
There is a lot of relevant text, too much for the post. Some more interesting portions have been provided below as part of the listing. In particular, we can see mentions of:
auditevents aboutapparmor_parser(while running primarily in the kernel space, the disclosed information is about the user space utility for loading AppArmor profiles)
|
|
- X11 X Keyboard Extension rules or symbols
|
|
- udev, along with devices' UUIDs
|
|
- systemd units
|
|
- PAM (Pluggable Authentication Modules)
|
|
Most importantly, searching the memory dump results in no secret keys being found. In particular, the secret LUKS key we intentionally disclosed earlier was not located in the dumped memory:
|
|
Summary
Protecting private information, especially in the context of confidential work,
is quite a challenging task. While the init_on_free mechanism in Linux,
replacing sdmem and the second stage in the ram-wipe
solution,
successfully protects the user’s LUKS secret key against warm boot attacks,
there is still partial information disclosure, which could be detrimental to
the user’s security.
The considerations on how to resolve this challenge include:
-
Improving the
init_on_freemechanism. A diagnosis, how it works, what information is not zeroed, and enhancing the zeroing mechanism with support for that kind of information might be sufficient. A thread on this matter has been started on the Linux Kernel Mailing List, where future research and conversations might take place. -
Building up on current
sdmemtechnology or running the second stage: continued maintenance and future improvements might ensure the robustness of the mechanisms. -
Developing a custom Linux kernel module that will be loaded last and will wipe selected memory.
Unlock the full potential of your hardware and secure your firmware with the
experts at 3mdeb! If you’re looking to boost your product’s performance and
protect it from potential security threats, our team is here to help. Schedule
a call with
us or
drop us an email at contact<at>3mdeb<dot>com to start unlocking the hidden
benefits of your hardware. And if you want to stay up-to-date on all things
firmware security and optimization, be sure to sign up for our newsletter:
