Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Fri 11-08-17 17:24:29, Florian Weimer wrote: > On 08/11/2017 04:24 PM, Michal Hocko wrote: > > On Fri 11-08-17 16:11:44, Florian Weimer wrote: > >> On 08/11/2017 04:06 PM, Michal Hocko wrote: > >> > >>> I am sorry to look too insisting here (I have still hard time to reconcile > >>> myself with

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Fri 11-08-17 17:24:29, Florian Weimer wrote: > On 08/11/2017 04:24 PM, Michal Hocko wrote: > > On Fri 11-08-17 16:11:44, Florian Weimer wrote: > >> On 08/11/2017 04:06 PM, Michal Hocko wrote: > >> > >>> I am sorry to look too insisting here (I have still hard time to reconcile > >>> myself with

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/11/2017 04:24 PM, Michal Hocko wrote: > On Fri 11-08-17 16:11:44, Florian Weimer wrote: >> On 08/11/2017 04:06 PM, Michal Hocko wrote: >> >>> I am sorry to look too insisting here (I have still hard time to reconcile >>> myself with the madvise (ab)use) but if we in fact want minherit like

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/11/2017 04:24 PM, Michal Hocko wrote: > On Fri 11-08-17 16:11:44, Florian Weimer wrote: >> On 08/11/2017 04:06 PM, Michal Hocko wrote: >> >>> I am sorry to look too insisting here (I have still hard time to reconcile >>> myself with the madvise (ab)use) but if we in fact want minherit like

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Fri 11-08-17 16:11:44, Florian Weimer wrote: > On 08/11/2017 04:06 PM, Michal Hocko wrote: > > > I am sorry to look too insisting here (I have still hard time to reconcile > > myself with the madvise (ab)use) but if we in fact want minherit like > > interface why don't we simply add minherit

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Fri 11-08-17 16:11:44, Florian Weimer wrote: > On 08/11/2017 04:06 PM, Michal Hocko wrote: > > > I am sorry to look too insisting here (I have still hard time to reconcile > > myself with the madvise (ab)use) but if we in fact want minherit like > > interface why don't we simply add minherit

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/11/2017 04:06 PM, Michal Hocko wrote: > I am sorry to look too insisting here (I have still hard time to reconcile > myself with the madvise (ab)use) but if we in fact want minherit like > interface why don't we simply add minherit and make the code which wants > to use that interface

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/11/2017 04:06 PM, Michal Hocko wrote: > I am sorry to look too insisting here (I have still hard time to reconcile > myself with the madvise (ab)use) but if we in fact want minherit like > interface why don't we simply add minherit and make the code which wants > to use that interface

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Fri 11-08-17 00:09:57, Colm MacCárthaigh wrote: > On Thu, Aug 10, 2017 at 7:01 PM, Michal Hocko wrote: > > Does anybody actually do that using the minherit BSD interface? > > I can't find any OSS examples. I just thought of it in response to > your question, but now that I

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Fri 11-08-17 00:09:57, Colm MacCárthaigh wrote: > On Thu, Aug 10, 2017 at 7:01 PM, Michal Hocko wrote: > > Does anybody actually do that using the minherit BSD interface? > > I can't find any OSS examples. I just thought of it in response to > your question, but now that I have, I do want to

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Thu, Aug 10, 2017 at 7:01 PM, Michal Hocko wrote: > Does anybody actually do that using the minherit BSD interface? I can't find any OSS examples. I just thought of it in response to your question, but now that I have, I do want to use it that way in privsep code. As a

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Thu, Aug 10, 2017 at 7:01 PM, Michal Hocko wrote: > Does anybody actually do that using the minherit BSD interface? I can't find any OSS examples. I just thought of it in response to your question, but now that I have, I do want to use it that way in privsep code. As a mere user, fwiw it

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Thu 10-08-17 16:17:18, Colm MacCárthaigh wrote: > On Déar 10 Lún 2017 at 17:36 Michal Hocko wrote: > > > On Thu 10-08-17 15:23:05, Colm MacCįrthaigh wrote: > > > On Thu, Aug 10, 2017 at 3:05 PM, Michal Hocko wrote: > > > >> Too late for that. VM_DONTFORK

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Thu 10-08-17 16:17:18, Colm MacCárthaigh wrote: > On Déar 10 Lún 2017 at 17:36 Michal Hocko wrote: > > > On Thu 10-08-17 15:23:05, Colm MacCįrthaigh wrote: > > > On Thu, Aug 10, 2017 at 3:05 PM, Michal Hocko wrote: > > > >> Too late for that. VM_DONTFORK is already implemented > > > >>

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Thu 10-08-17 15:23:05, Colm MacCárthaigh wrote: > On Thu, Aug 10, 2017 at 3:05 PM, Michal Hocko wrote: > >> Too late for that. VM_DONTFORK is already implemented > >> through MADV_DONTFORK & MADV_DOFORK, in a way that is > >> very similar to the MADV_WIPEONFORK from these

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Thu 10-08-17 15:23:05, Colm MacCárthaigh wrote: > On Thu, Aug 10, 2017 at 3:05 PM, Michal Hocko wrote: > >> Too late for that. VM_DONTFORK is already implemented > >> through MADV_DONTFORK & MADV_DOFORK, in a way that is > >> very similar to the MADV_WIPEONFORK from these patches. > > > >

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue 08-08-17 14:45:14, Rik van Riel wrote: > On Tue, 2017-08-08 at 09:52 -0700, Matthew Wilcox wrote: > > On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > > > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > > > If the use case is fairly specific, then perhaps it makes

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue 08-08-17 14:45:14, Rik van Riel wrote: > On Tue, 2017-08-08 at 09:52 -0700, Matthew Wilcox wrote: > > On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > > > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > > > If the use case is fairly specific, then perhaps it makes

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Thu 10-08-17 15:21:10, Michal Hocko wrote: [...] > Thanks, these references are really useful to build a picture. I would > probably use an unlinked fd with O_CLOEXEC to dect this but I can see > how this is not the greatest option for a library. Blee, brainfart on my end. For some reason I

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Thu 10-08-17 15:21:10, Michal Hocko wrote: [...] > Thanks, these references are really useful to build a picture. I would > probably use an unlinked fd with O_CLOEXEC to dect this but I can see > how this is not the greatest option for a library. Blee, brainfart on my end. For some reason I

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Thu, Aug 10, 2017 at 3:05 PM, Michal Hocko wrote: >> Too late for that. VM_DONTFORK is already implemented >> through MADV_DONTFORK & MADV_DOFORK, in a way that is >> very similar to the MADV_WIPEONFORK from these patches. > > Yeah, those two seem to be breaking the "madvise

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Thu, Aug 10, 2017 at 3:05 PM, Michal Hocko wrote: >> Too late for that. VM_DONTFORK is already implemented >> through MADV_DONTFORK & MADV_DOFORK, in a way that is >> very similar to the MADV_WIPEONFORK from these patches. > > Yeah, those two seem to be breaking the "madvise as an advise"

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon 07-08-17 17:55:45, Colm MacCárthaigh wrote: > On Mon, Aug 7, 2017 at 3:46 PM, Michal Hocko wrote: > > > > > > > The use case is libraries that store or cache information, and > > > > want to know that they need to regenerate it in the child process > > > > after fork. >

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon 07-08-17 17:55:45, Colm MacCárthaigh wrote: > On Mon, Aug 7, 2017 at 3:46 PM, Michal Hocko wrote: > > > > > > > The use case is libraries that store or cache information, and > > > > want to know that they need to regenerate it in the child process > > > > after fork. > > > > How do they

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon 07-08-17 16:19:18, Florian Weimer wrote: > On 08/07/2017 03:46 PM, Michal Hocko wrote: > > How do they know that they need to regenerate if they do not get SEGV? > > Are they going to assume that a read of zeros is a "must init again"? Isn't > > that too fragile? > > Why would it be

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon 07-08-17 16:19:18, Florian Weimer wrote: > On 08/07/2017 03:46 PM, Michal Hocko wrote: > > How do they know that they need to regenerate if they do not get SEGV? > > Are they going to assume that a read of zeros is a "must init again"? Isn't > > that too fragile? > > Why would it be

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon 07-08-17 10:59:51, Rik van Riel wrote: > On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > > This is an user visible API so make sure you CC linux-api (added) > > > > > > On Sun 06-08-17 10:04:23, Rik van Riel wrote: > > > > > > >

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon 07-08-17 10:59:51, Rik van Riel wrote: > On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > > This is an user visible API so make sure you CC linux-api (added) > > > > > > On Sun 06-08-17 10:04:23, Rik van Riel wrote: > > > > > > >

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/09/2017 11:59 AM, Kirill A. Shutemov wrote: > It's not obvious to me what would break if kernel would ignore > MADV_DONTFORK or MADV_DONTDUMP. Ignoring MADV_DONTDUMP could cause secrets to be written to disk, contrary to the expected security policy of the system. Thanks, Florian

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/09/2017 11:59 AM, Kirill A. Shutemov wrote: > It's not obvious to me what would break if kernel would ignore > MADV_DONTFORK or MADV_DONTDUMP. Ignoring MADV_DONTDUMP could cause secrets to be written to disk, contrary to the expected security policy of the system. Thanks, Florian

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Wed, 2017-08-09 at 12:59 +0300, Kirill A. Shutemov wrote: > On Mon, Aug 07, 2017 at 10:59:51AM -0400, Rik van Riel wrote: > > On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > > > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > > > This is an user visible API so make sure you CC

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Wed, 2017-08-09 at 12:59 +0300, Kirill A. Shutemov wrote: > On Mon, Aug 07, 2017 at 10:59:51AM -0400, Rik van Riel wrote: > > On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > > > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > > > This is an user visible API so make sure you CC

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon, Aug 07, 2017 at 10:59:51AM -0400, Rik van Riel wrote: > On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > > This is an user visible API so make sure you CC linux-api (added) > > > > > > On Sun 06-08-17 10:04:23, Rik van Riel

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon, Aug 07, 2017 at 10:59:51AM -0400, Rik van Riel wrote: > On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > > This is an user visible API so make sure you CC linux-api (added) > > > > > > On Sun 06-08-17 10:04:23, Rik van Riel

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 09:52 -0700, Matthew Wilcox wrote: > On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > > If the use case is fairly specific, then perhaps it makes sense > > > to > > > make MADV_WIPEONFORK not

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 09:52 -0700, Matthew Wilcox wrote: > On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > > If the use case is fairly specific, then perhaps it makes sense > > > to > > > make MADV_WIPEONFORK not

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > If the use case is fairly specific, then perhaps it makes sense to > > make MADV_WIPEONFORK not applicable (EINVAL) for mappings where the > > result is 'questionable'. > >

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > If the use case is fairly specific, then perhaps it makes sense to > > make MADV_WIPEONFORK not applicable (EINVAL) for mappings where the > > result is 'questionable'. > >

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, Aug 8, 2017 at 5:46 PM, Rik van Riel wrote: >> If the use case is fairly specific, then perhaps it makes sense to >> make MADV_WIPEONFORK not applicable (EINVAL) for mappings where the >> result is 'questionable'. > > That would be a question for Florian and Colm. > > If

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, Aug 8, 2017 at 5:46 PM, Rik van Riel wrote: >> If the use case is fairly specific, then perhaps it makes sense to >> make MADV_WIPEONFORK not applicable (EINVAL) for mappings where the >> result is 'questionable'. > > That would be a question for Florian and Colm. > > If they are OK with

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > The other question I was trying to bring up is "What does > MADV_WIPEONFORK > mean for various types of mappings?"  For example, if we allow > MADV_WIPEONFORK on a file backed mapping what does that mapping look > like in the child after

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > The other question I was trying to bring up is "What does > MADV_WIPEONFORK > mean for various types of mappings?"  For example, if we allow > MADV_WIPEONFORK on a file backed mapping what does that mapping look > like in the child after

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/08/2017 05:19 PM, Mike Kravetz wrote: > On 08/08/2017 06:15 AM, Rik van Riel wrote: >> On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: >>> On 08/07/2017 08:23 PM, Mike Kravetz wrote: If my thoughts above are correct, what about returning EINVAL if one attempts to set

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/08/2017 05:19 PM, Mike Kravetz wrote: > On 08/08/2017 06:15 AM, Rik van Riel wrote: >> On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: >>> On 08/07/2017 08:23 PM, Mike Kravetz wrote: If my thoughts above are correct, what about returning EINVAL if one attempts to set

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/08/2017 06:15 AM, Rik van Riel wrote: > On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: >> On 08/07/2017 08:23 PM, Mike Kravetz wrote: >>> If my thoughts above are correct, what about returning EINVAL if >>> one >>> attempts to set MADV_DONTFORK on mappings set up for sharing? >> >>

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/08/2017 06:15 AM, Rik van Riel wrote: > On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: >> On 08/07/2017 08:23 PM, Mike Kravetz wrote: >>> If my thoughts above are correct, what about returning EINVAL if >>> one >>> attempts to set MADV_DONTFORK on mappings set up for sharing? >> >>

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: > On 08/07/2017 08:23 PM, Mike Kravetz wrote: > > If my thoughts above are correct, what about returning EINVAL if > > one > > attempts to set MADV_DONTFORK on mappings set up for sharing? > > That's my preference as well.  If there is a

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: > On 08/07/2017 08:23 PM, Mike Kravetz wrote: > > If my thoughts above are correct, what about returning EINVAL if > > one > > attempts to set MADV_DONTFORK on mappings set up for sharing? > > That's my preference as well.  If there is a

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/07/2017 08:23 PM, Mike Kravetz wrote: > If my thoughts above are correct, what about returning EINVAL if one > attempts to set MADV_DONTFORK on mappings set up for sharing? That's my preference as well. If there is a use case for shared or non-anonymous mappings, then we can implement

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/07/2017 08:23 PM, Mike Kravetz wrote: > If my thoughts above are correct, what about returning EINVAL if one > attempts to set MADV_DONTFORK on mappings set up for sharing? That's my preference as well. If there is a use case for shared or non-anonymous mappings, then we can implement

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/06/2017 07:04 AM, r...@redhat.com wrote: > v2: fix MAP_SHARED case and kbuild warnings > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > empty in the child process after fork. This differs from MADV_DONTFORK > in one important way. It seems that the target use case

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/06/2017 07:04 AM, r...@redhat.com wrote: > v2: fix MAP_SHARED case and kbuild warnings > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > empty in the child process after fork. This differs from MADV_DONTFORK > in one important way. It seems that the target use case

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

[ Resent as text/plain, after sacrificing an offering to the RFC822 gods] On Mon, Aug 7, 2017 at 3:46 PM, Michal Hocko wrote: > > > > > The use case is libraries that store or cache information, and > > > want to know that they need to regenerate it in the child process > > >

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

[ Resent as text/plain, after sacrificing an offering to the RFC822 gods] On Mon, Aug 7, 2017 at 3:46 PM, Michal Hocko wrote: > > > > > The use case is libraries that store or cache information, and > > > want to know that they need to regenerate it in the child process > > > after fork. > > How

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > This is an user visible API so make sure you CC linux-api (added) > > > > On Sun 06-08-17 10:04:23, Rik van Riel wrote: > > > > > > A further complication is the proliferation of clone

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > This is an user visible API so make sure you CC linux-api (added) > > > > On Sun 06-08-17 10:04:23, Rik van Riel wrote: > > > > > > A further complication is the proliferation of clone

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/07/2017 03:46 PM, Michal Hocko wrote: > How do they know that they need to regenerate if they do not get SEGV? > Are they going to assume that a read of zeros is a "must init again"? Isn't > that too fragile? Why would it be fragile? Some level of synchronization is needed to set things

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On 08/07/2017 03:46 PM, Michal Hocko wrote: > How do they know that they need to regenerate if they do not get SEGV? > Are they going to assume that a read of zeros is a "must init again"? Isn't > that too fragile? Why would it be fragile? Some level of synchronization is needed to set things

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon 07-08-17 15:22:57, Michal Hocko wrote: > This is an user visible API so make sure you CC linux-api (added) > > On Sun 06-08-17 10:04:23, Rik van Riel wrote: > > v2: fix MAP_SHARED case and kbuild warnings > > > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > > empty

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon 07-08-17 15:22:57, Michal Hocko wrote: > This is an user visible API so make sure you CC linux-api (added) > > On Sun 06-08-17 10:04:23, Rik van Riel wrote: > > v2: fix MAP_SHARED case and kbuild warnings > > > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > > empty

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

This is an user visible API so make sure you CC linux-api (added) On Sun 06-08-17 10:04:23, Rik van Riel wrote: > v2: fix MAP_SHARED case and kbuild warnings > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > empty in the child process after fork. This differs from

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

This is an user visible API so make sure you CC linux-api (added) On Sun 06-08-17 10:04:23, Rik van Riel wrote: > v2: fix MAP_SHARED case and kbuild warnings > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > empty in the child process after fork. This differs from

[PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

v2: fix MAP_SHARED case and kbuild warnings Introduce MADV_WIPEONFORK semantics, which result in a VMA being empty in the child process after fork. This differs from MADV_DONTFORK in one important way. If a child process accesses memory that was MADV_WIPEONFORK, it will get zeroes. The address

[PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

v2: fix MAP_SHARED case and kbuild warnings Introduce MADV_WIPEONFORK semantics, which result in a VMA being empty in the child process after fork. This differs from MADV_DONTFORK in one important way. If a child process accesses memory that was MADV_WIPEONFORK, it will get zeroes. The address