From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation Date: Mon, 09 Oct 2017 15:08:44 -0400 Message-ID: <1507576124.21121.168.camel@redhat.com> References: <20170914130040.6faabb18@cuia.usersys.redhat.com> <20170914150546.74ad3a9a@cuia.usersys.redhat.com> <1505848907.5486.9.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Cc: Colm =?ISO-8859-1?Q?MacC=E1rthaigh?= , linux-man , lkml , "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org" , Linux API , nilal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Florian Weimer , Mike Kravetz List-Id: linux-api@vger.kernel.org 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(). 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. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f72.google.com (mail-it0-f72.google.com [209.85.214.72]) by kanga.kvack.org (Postfix) with ESMTP id 6A0486B0033 for ; Mon, 9 Oct 2017 15:08:47 -0400 (EDT) Received: by mail-it0-f72.google.com with SMTP id i63so17117339itc.18 for ; Mon, 09 Oct 2017 12:08:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id 32si5229169qtf.422.2017.10.09.12.08.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 12:08:46 -0700 (PDT) Message-ID: <1507576124.21121.168.camel@redhat.com> Subject: Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation From: Rik van Riel Date: Mon, 09 Oct 2017 15:08:44 -0400 In-Reply-To: References: <20170914130040.6faabb18@cuia.usersys.redhat.com> <20170914150546.74ad3a9a@cuia.usersys.redhat.com> <1505848907.5486.9.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: mtk.manpages@gmail.com Cc: Colm =?ISO-8859-1?Q?MacC=E1rthaigh?= , linux-man , lkml , "linux-mm@kvack.org" , Linux API , nilal@redhat.com, Florian Weimer , Mike Kravetz 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(). 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. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754380AbdJITIs (ORCPT ); Mon, 9 Oct 2017 15:08:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49182 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751184AbdJITIq (ORCPT ); Mon, 9 Oct 2017 15:08:46 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0186B820ED Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=riel@redhat.com Message-ID: <1507576124.21121.168.camel@redhat.com> Subject: Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation From: Rik van Riel To: mtk.manpages@gmail.com Cc: Colm =?ISO-8859-1?Q?MacC=E1rthaigh?= , linux-man , lkml , "linux-mm@kvack.org" , Linux API , nilal@redhat.com, Florian Weimer , Mike Kravetz Date: Mon, 09 Oct 2017 15:08:44 -0400 In-Reply-To: References: <20170914130040.6faabb18@cuia.usersys.redhat.com> <20170914150546.74ad3a9a@cuia.usersys.redhat.com> <1505848907.5486.9.camel@redhat.com> Organization: Red Hat, Inc Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 09 Oct 2017 19:08:46 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(). 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.