From: Vlastimil Babka <vbabka@suse.cz>
To: Theodore Ts'o <tytso@mit.edu>, Willy Tarreau <w@1wt.eu>
Cc: York Jasper Niebuhr <yjnworkstation@gmail.com>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, linux-security-module@vger.kernel.org,
torvalds@linux-foundation.org
Subject: Re: [PATCH] exitz syscall
Date: Mon, 13 Nov 2023 08:37:04 +0100 [thread overview]
Message-ID: <87fa3d2e-6822-0f24-daec-772dbe717b63@suse.cz> (raw)
In-Reply-To: <20231112045217.GA39417@mit.edu>
On 11/12/23 05:52, Theodore Ts'o wrote:
> On Sat, Nov 11, 2023 at 02:24:31PM +0100, Willy Tarreau wrote:
>> Hello,
>>
>> On Sat, Nov 11, 2023 at 01:51:26PM +0100, York Jasper Niebuhr wrote:
>> > Adds a system call to flag a process' resources to be cleared on
>> > exit (or, in the case of memory, on free). Currently, only zeroing
>> > memory is implemented.
>> (...)
>>
>> IMHO it does not make sense to add a syscall for this, please have a
>> look at prctl(2) instead, which is already used for similar settings.
>
> Another reason to use prctl() is there are other cases when you'd want
> to zero a process's memory. For example, if the process gets killed
> to some kind of signal, or when it gets OOM killed (where there is no
> system call which forces the process to exit). Also, if you want to
> zero memory when the process exits, you'd want to zero the process
> memory on an exec(2).
Probably also munmap() and maybe a number of other ways where the process
can give up its memory voluntarily. Then there are also involuntary ways
where the a copy of the data can end up leaking elsewhere than the pages the
process has mapped - e.g. swapout/swapin of pages, page migration...
So I'm not sure it's feasible to attempt making a whole process "sensitive"
and close all the holes. Instead what we have is to mark specific areas as
sensitive - things like mlock(), madvise(MADV_DONTDUMP / MADV_DONTFORK) and
ultimately memfd_secret().
> Cheers,
>
> - Ted
>
next prev parent reply other threads:[~2023-11-13 7:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-11 12:51 [PATCH] exitz syscall York Jasper Niebuhr
2023-11-11 13:24 ` Willy Tarreau
2023-11-12 1:24 ` Linus Torvalds
2023-11-13 0:08 ` Andy Lutomirski
2023-11-12 4:52 ` Theodore Ts'o
2023-11-13 7:37 ` Vlastimil Babka [this message]
2023-11-19 14:54 ` Jasper Niebuhr
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=87fa3d2e-6822-0f24-daec-772dbe717b63@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=w@1wt.eu \
--cc=yjnworkstation@gmail.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).