linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Danill Klimuk <daniil.klimuk@3mdeb.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	linux-modules@vger.kernel.org,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Question: a module for wiping userspace RAM before shutdown/reboot/halt
Date: Mon, 19 May 2025 09:26:36 +0200	[thread overview]
Message-ID: <e71bd62c-5ba7-4363-9af1-d9c9de394a54@3mdeb.com> (raw)
In-Reply-To: <e55bd90e-8bbf-4eb2-95e2-cc636725a0ae@csgroup.eu>

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.



  reply	other threads:[~2025-05-19  7:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bfe72929-ba4c-4732-9f80-25cc7b95a0c8@3mdeb.com>
2025-05-17 17:25 ` Christophe Leroy
2025-05-19  7:26   ` Danill Klimuk [this message]
2025-05-19  7:43     ` David Hildenbrand
     [not found] ` <eb88e58f-1515-4f51-8102-79cd3c20fea5@3mdeb.com>
2025-09-04  7:14   ` Christophe Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e71bd62c-5ba7-4363-9af1-d9c9de394a54@3mdeb.com \
    --to=daniil.klimuk@3mdeb.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=linux-mm@kvack.org \
    --cc=linux-modules@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox