lkml.org 
[lkml]   [2017]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK
On Thu, Aug 10, 2017 at 7:01 PM, Michal Hocko <mhocko@kernel.org> 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 would make /my/ code less complex (in
Kolmogorov terms) to be an madvise option. Here's what that would look
like in user space:

mmap()

#if MAP_INHERIT_ZERO
minherit() || pthread_atfork(workaround_fptr);
#elif MADVISE_WIPEONFORK
madvise() || pthread_atfork(workaround_fptr);
#else
pthread_atfork(workaround_fptr);
#endif

Vs:

#if MAP_WIPEONFORK
mmap( ... WIPEONFORK) || pthread_atfork(workaround_fptr);
#else
mmap()
#endif

#if MAP_INHERIT_ZERO
madvise() || pthread_atfork(workaround_fptr);
#endif

#if !defined(MAP_WIPEONFORK) && !defined(MAP_INHERIT_ZERO)
pthread_atfork(workaround_fptr);
#endif

The former is neater, and also a lot easier to stay structured if the
code is separated across different functional units. Allocation is
often handled in special functions.

For me, madvise() is the principle of least surprise, following
existing DONTDUMP semantics.

--
Colm

\
 
 \ /
  Last update: 2017-08-11 00:10    [W:0.602 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site