linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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:11:24 +0200	[thread overview]
Message-ID: <CAKgNAkjGX5BanVCB=fauy9tYt+eAOb990LDOd73dvUp-bm03KA@mail.gmail.com> (raw)
In-Reply-To: <1507576124.21121.168.camel@redhat.com>

Hi Rik,

Thanks for the blazingly fast response :-)

On 9 October 2017 at 21:08, Rik van Riel <riel@redhat.com> wrote:
> On Mon, 2017-10-09 at 21:06 +0200, Michael Kerrisk (man-pages) wrote:
>> 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.
>
> Indeed, on exec() the flag is cleared, because all
> memory regions get replaced on exec().

Thanks.

> The flag remains across a fork(), so if a child task
> were to fork, the memory would be empty of contents
> again in its child. This seems to most closely match
> the use case of discarding things like cryptographic
> secrets at fork time.

Thanks!

I'll add this info to the madvise(2) page.

Cheers,

Michael



-- 
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>

      reply	other threads:[~2017-10-09 19:11 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)
2017-10-09 19:08           ` Rik van Riel
2017-10-09 19:11             ` Michael Kerrisk (man-pages) [this message]

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='CAKgNAkjGX5BanVCB=fauy9tYt+eAOb990LDOd73dvUp-bm03KA@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