[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgNAkg8QJHfPfdfYXBU2-eW=_FWY99UYi_6hQejE=q5+66u1g@mail.gmail.com>
Date: Mon, 9 Oct 2017 21:06:30 +0200
From: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To: Rik van Riel <riel@...hat.com>
Cc: Colm MacCárthaigh <colm@...costs.net>,
linux-man <linux-man@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Linux API <linux-api@...r.kernel.org>, nilal@...hat.com,
Florian Weimer <fweimer@...hat.com>,
Mike Kravetz <mike.kravetz@...cle.com>
Subject: Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation
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@...hat.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/
Powered by blists - more mailing lists