Question: a module for wiping userspace RAM before shutdown/reboot/halt

Question: a module for wiping userspace RAM before shutdown/reboot/halt

[Danill Klimuk]

Hello everyone. I have received a request to write a Linux kernel module 
that will wipe any processes leftovers from userspace RAM during/before 
Linux kernel shutdown/reboot/halt sequences. The reason I am going to do 
it inside a module is to do it in a more deterministic way that does not 
depend on any processes. AFAIK Linux kernel does not have any other 
functionalities to wipe leftovers from RAM apart from the command line 
arguments "init_on_free" and "init_on_alloc" that results in memory 
poisoning only during memory allocation and memory deallocation. These 
arguments cause the kernel to clean processes memory several times 
during runtime, that is not deterministic because of processes 
non-deterministic behavior. Hence, I want to bring the memory wiping 
mechanism in one place and make it more deterministic. The question is:

Maybe the Linux kernel already have such functionalities implemented?

Currently I am planning to implement the wiping process to be triggered 
by "reboot_notifier_callback", so to wipe RAM after PID 1 process 
finishes and no other processes are executing. I am looking forward to 
merging the module into Linux kernel upstream too.

Best regards, Daniil.
3mdeb Zarhus team leader.

Re: Question: a module for wiping userspace RAM before shutdown/reboot/halt

[Christophe Leroy]

Le 15/05/2025 à 15:30, Danill Klimuk a écrit :

> Hello everyone. I have received a request to write a Linux kernel module
> that will wipe any processes leftovers from userspace RAM during/before
> Linux kernel shutdown/reboot/halt sequences. The reason I am going to do
> it inside a module is to do it in a more deterministic way that does not
> depend on any processes. AFAIK Linux kernel does not have any other
> functionalities to wipe leftovers from RAM apart from the command line
> arguments "init_on_free" and "init_on_alloc" that results in memory
> poisoning only during memory allocation and memory deallocation. These
> arguments cause the kernel to clean processes memory several times
> during runtime, that is not deterministic because of processes
> non-deterministic behavior. Hence, I want to bring the memory wiping
> mechanism in one place and make it more deterministic. The question is:
> 
> Maybe the Linux kernel already have such functionalities implemented?

Linux memory management topics should be sent to linux-mm@kvack.org

> 
> Currently I am planning to implement the wiping process to be triggered
> by "reboot_notifier_callback", so to wipe RAM after PID 1 process
> finishes and no other processes are executing. I am looking forward to
> merging the module into Linux kernel upstream too.

What do you mean by 'wiping', do you mean 'clearing' ?

Can you explain the reason this is needed ?

Christophe

Re: Question: a module for wiping userspace RAM before shutdown/reboot/halt

[Danill Klimuk]

Hi Christophe, thank you for the answer.

 > What do you mean by 'wiping', do you mean 'clearing' ?

Yes, by 'wiping' I mean 'clearing'.

 > Can you explain the reason this is needed?

Some of our clients want to clear user space RAM during 
shutdown/reboot/halt sequences of Linux kernel, so the process data or 
any other leftovers do not leak outside current Linux kernel session 
(that is to firmware, or the next boot software, etc.). The reason for 
it to be a module that will execute in a specific moment of the 
sequences is to make it more predictable.

I thought that if the clients want to use it, maybe it will be useful 
for others too :).

On 5/17/25 7:25 PM, Christophe Leroy wrote:
>
>
> Le 15/05/2025 à 15:30, Danill Klimuk a écrit :
>
>> Hello everyone. I have received a request to write a Linux kernel module
>> that will wipe any processes leftovers from userspace RAM during/before
>> Linux kernel shutdown/reboot/halt sequences. The reason I am going to do
>> it inside a module is to do it in a more deterministic way that does not
>> depend on any processes. AFAIK Linux kernel does not have any other
>> functionalities to wipe leftovers from RAM apart from the command line
>> arguments "init_on_free" and "init_on_alloc" that results in memory
>> poisoning only during memory allocation and memory deallocation. These
>> arguments cause the kernel to clean processes memory several times
>> during runtime, that is not deterministic because of processes
>> non-deterministic behavior. Hence, I want to bring the memory wiping
>> mechanism in one place and make it more deterministic. The question is:
>>
>> Maybe the Linux kernel already have such functionalities implemented?
>
> Linux memory management topics should be sent to linux-mm@kvack.org
>
>>
>> Currently I am planning to implement the wiping process to be triggered
>> by "reboot_notifier_callback", so to wipe RAM after PID 1 process
>> finishes and no other processes are executing. I am looking forward to
>> merging the module into Linux kernel upstream too.
>
> What do you mean by 'wiping', do you mean 'clearing' ?
>
> Can you explain the reason this is needed ?
>
> Christophe
>
>
-- 
Best regards, Daniil.
3mdeb Zarhus team leader.

Re: Question: a module for wiping userspace RAM before shutdown/reboot/halt

[David Hildenbrand]

On 19.05.25 09:26, Danill Klimuk wrote:
> Hi Christophe, thank you for the answer.
> 
>   > What do you mean by 'wiping', do you mean 'clearing' ?
> 
> Yes, by 'wiping' I mean 'clearing'.
> 
>   > Can you explain the reason this is needed?
> 
> Some of our clients want to clear user space RAM during
> shutdown/reboot/halt sequences of Linux kernel, so the process data or
> any other leftovers do not leak outside current Linux kernel session
> (that is to firmware, or the next boot software, etc.). The reason for
> it to be a module that will execute in a specific moment of the
> sequences is to make it more predictable.
> 
> I thought that if the clients want to use it, maybe it will be useful
> for others too :).

We do have the init_on_free=1 boot option, whereby any pages freed back 
to the page allocator will get immediately zeroed.

This also makes sure that if you quit a process and then 
shutdown/reboot, that the page content was already cleared. (otherwise, 
it would simply be free memory in the allocator and no longer "userspace 
RAM")

-- 
Cheers,

David / dhildenb

Re: Question: a module for wiping userspace RAM before shutdown/reboot/halt

[Kamil Aronowski]

[-- Attachment #1.1.1: Type: text/plain, Size: 2373 bytes --]

Recently, we evaluated the effectiveness of the `init_on_free`
mechanism, particularly in the context of preserving privacy by
clearing RAM for individuals with high operational security
requirements.

As mentioned
(https://lore.kernel.org/all/e71bd62c-5ba7-4363-9af1-d9c9de394a54@3mdeb.com/),
we'd like to ensure that our clients do not have their confidential
data leaked after their session has ended with a shutdown/reboot/halt.

In short, `init_on_free` appears to wipe the LUKS secret key
successfully, but some non-kernel space snippets remain in memory.
Some tests have been performed by dumping memory after booting Debian
13 (with `init_on_free` enabled) and then rebooting to our custom EFI
memory dumping application.  For instance, the mentions of
`apparmor_parser`, XKB, udev, or systemd units have been found in the
memory dump:

```
audit: type=1400 audit(1755156467.556:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="Discord" pid=967 
comm="apparmor_parser"r"
[...]

partial alphanumeric_keys
xkb_symbols "tib_asciinum" {
     include "cn(tib)"
     name[Group1]= "Tibetan (with ASCII numerals)";
     key <AE01> { [ 1, 0x1000f21, 0x1000f04, 0x1000f76 ] }; # 1
[...]

I:10114000
E:ID_MM_CANDIDATE=1
S:disk/by-id/dm-uuid-CRYPT-LUKS2-00b4b79c209a4dcfadf37e310778f583-sda3_crypt
[...]

[Unit]
Description=Switch Root
AssertPathExists=/etc/initrd-release
DefaultDependencies=no
Wants=initrd-switch-root.service
Before=initrd-switch-root.service
AllowIsolate=yes
Wants=initrd-udevadm-cleanup-db.service initrd-root-fs.target 
initrd-fs.target systemd-journald.service initrd-cleanup.service
After=initrd-udevadm-cleanup-db.service initrd-root-fs.target 
initrd-fs.target emergency.service emergency.target initrd-cleanup.service
[...]
```

Is this the expected behavior, a bug, or a misconfiguration on our
end?

If it is indeed a bug, we'd be happy to cooperate on improving the
`init_on_free` mechanism. If it is expected behavior than we will
consider wiping userspace memory some other way, e.g. by implementing
a separate Linux Kernel module as described in the previous email
(https://lore.kernel.org/all/e71bd62c-5ba7-4363-9af1-d9c9de394a54@3mdeb.com/).

-- 
Kamil Aronowski
Junior Embedded Firmware Engineer
GPG: 3510148A5CD67908
https://3mdeb.com | @3mdeb_com

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 5529 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Question: a module for wiping userspace RAM before shutdown/reboot/halt

[Christophe Leroy]

+mm list

Hi Kamil,

Le 21/08/2025 à 14:13, Kamil Aronowski a écrit :
> Recently, we evaluated the effectiveness of the `init_on_free`
> mechanism, particularly in the context of preserving privacy by
> clearing RAM for individuals with high operational security
> requirements.
> 
> As mentioned
> (https://lore.kernel.org/all/e71bd62c-5ba7-4363-9af1- 
> d9c9de394a54@3mdeb.com/),
> we'd like to ensure that our clients do not have their confidential
> data leaked after their session has ended with a shutdown/reboot/halt.
> 
> In short, `init_on_free` appears to wipe the LUKS secret key
> successfully, but some non-kernel space snippets remain in memory.
> Some tests have been performed by dumping memory after booting Debian
> 13 (with `init_on_free` enabled) and then rebooting to our custom EFI
> memory dumping application.  For instance, the mentions of
> `apparmor_parser`, XKB, udev, or systemd units have been found in the
> memory dump:
> 
> ```
> audit: type=1400 audit(1755156467.556:2): apparmor="STATUS" 
> operation="profile_load" profile="unconfined" name="Discord" pid=967 
> comm="apparmor_parser"r"
> [...]
> 
> partial alphanumeric_keys
> xkb_symbols "tib_asciinum" {
>      include "cn(tib)"
>      name[Group1]= "Tibetan (with ASCII numerals)";
>      key <AE01> { [ 1, 0x1000f21, 0x1000f04, 0x1000f76 ] }; # 1
> [...]
> 
> I:10114000
> E:ID_MM_CANDIDATE=1
> S:disk/by-id/dm-uuid-CRYPT-LUKS2-00b4b79c209a4dcfadf37e310778f583- 
> sda3_crypt
> [...]
> 
> [Unit]
> Description=Switch Root
> AssertPathExists=/etc/initrd-release
> DefaultDependencies=no
> Wants=initrd-switch-root.service
> Before=initrd-switch-root.service
> AllowIsolate=yes
> Wants=initrd-udevadm-cleanup-db.service initrd-root-fs.target initrd- 
> fs.target systemd-journald.service initrd-cleanup.service
> After=initrd-udevadm-cleanup-db.service initrd-root-fs.target initrd- 
> fs.target emergency.service emergency.target initrd-cleanup.service
> [...]
> ```
> 
> Is this the expected behavior, a bug, or a misconfiguration on our
> end?
> 
> If it is indeed a bug, we'd be happy to cooperate on improving the
> `init_on_free` mechanism. If it is expected behavior than we will
> consider wiping userspace memory some other way, e.g. by implementing
> a separate Linux Kernel module as described in the previous email
> (https://lore.kernel.org/all/e71bd62c-5ba7-4363-9af1- 
> d9c9de394a54@3mdeb.com/).
> 

This topic seems to be a memory management topic, not a modules topic.

As I mentionned already in this thread, Linux memory management topics 
should be addressed to linux-mm@kvack.org

Christophe