From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Rik van Riel <riel@redhat.com>
Cc: "Colm MacCárthaigh" <colm@allcosts.net>,
linux-man <linux-man@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"Linux API" <linux-api@vger.kernel.org>,
nilal@redhat.com, "Florian Weimer" <fweimer@redhat.com>,
"Mike Kravetz" <mike.kravetz@oracle.com>
Subject: Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation
Date: Mon, 9 Oct 2017 21:06:30 +0200 [thread overview]
Message-ID: <CAKgNAkg8QJHfPfdfYXBU2-eW=_FWY99UYi_6hQejE=q5+66u1g@mail.gmail.com> (raw)
In-Reply-To: <1505848907.5486.9.camel@redhat.com>
Hi Rik,
I have a follow-up question re wipe-on-fork. What are the semantics
for this setting with respect to fork() and exec()? That is, in the
child of a fork(), does the flag remain set for the specified address
range? (My quick read of the source suggests yes, but I have not
tested.) And, when we do an exec(), my assumption is that the flag is
cleared for the address range, but it would be good to have
confirmation.
Thanks,
Michael
On 19 September 2017 at 21:21, Rik van Riel <riel@redhat.com> wrote:
> On Tue, 2017-09-19 at 21:07 +0200, Michael Kerrisk (man-pages) wrote:
>
>> Thanks. I applied this, and tweaked the madvise.2 text a little, to
>> read as follows (please let me know if I messed anything up):
>>
>> MADV_WIPEONFORK (since Linux 4.14)
>> Present the child process with zero-filled
>> memory in this
>> range after a fork(2). This is useful in forking
>> servers
>> in order to ensure that sensitive per-
>> process data (for
>> example, PRNG seeds, cryptographic secrets, and so
>> on) is
>> not handed to child processes.
>>
>> The MADV_WIPEONFORK operation can be applied
>> only to pri‐
>> vate anonymous pages (see mmap(2)).
>
> That looks great. Thank you, Michael!
>
> --
> All rights reversed
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-10-09 19:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-14 17:00 [patch] " Rik van Riel
2017-09-14 17:09 ` Colm MacCárthaigh
2017-09-14 19:05 ` [patch v2] " Rik van Riel
2017-09-14 19:10 ` Colm MacCárthaigh
2017-09-19 19:07 ` Michael Kerrisk (man-pages)
2017-09-19 19:21 ` Rik van Riel
2017-10-09 19:06 ` Michael Kerrisk (man-pages) [this message]
2017-10-09 19:08 ` Rik van Riel
2017-10-09 19:11 ` Michael Kerrisk (man-pages)
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='CAKgNAkg8QJHfPfdfYXBU2-eW=_FWY99UYi_6hQejE=q5+66u1g@mail.gmail.com' \
--to=mtk.manpages@gmail.com \
--cc=colm@allcosts.net \
--cc=fweimer@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=nilal@redhat.com \
--cc=riel@redhat.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