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

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

[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