linux-kernel - Re: [PATCH v2 0/2] mm,fork,security: introduce MADV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0324df31-717d-32c1-95ef-351c5b23105f@oracle.com>
Date:   Tue, 8 Aug 2017 08:19:48 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Rik van Riel <riel@...hat.com>,
        Florian Weimer <fweimer@...hat.com>,
        linux-kernel@...r.kernel.org
Cc:     linux-mm@...ck.org, colm@...costs.net, akpm@...ux-foundation.org,
        keescook@...omium.org, luto@...capital.net, wad@...omium.org,
        mingo@...nel.org, kirill@...temov.name, dave.hansen@...el.com
Subject: 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?
>>
>> That's my preference as well.  If there is a use case for shared or
>> non-anonymous mappings, then we can implement MADV_DONTFORK with the
>> semantics for this use case.  If we pick some arbitrary semantics
>> now,
>> without any use case, we might end up with something that's not
>> actually
>> useful.
> 
> MADV_DONTFORK is existing semantics, and it is enforced
> on shared, non-anonymous mappings. It is frequently used
> for things like device mappings, which should not be
> inherited by a child process, because the device can only
> be used by one process at a time.
> 
> When someone requests MADV_DONTFORK on a shared VMA, they
> will get it. The later madvise request overrides the mmap
> flags that were used earlier.
> 
> The question is, should MADV_WIPEONFORK (introduced by
> this series) have not just different semantics, but also
> totally different behavior from MADV_DONTFORK?

Sorry for the confusion.  I accidentally used MADV_DONTFORK instead
of MADV_WIPEONFORK in my reply (which Florian commented on).

> Does the principle of least surprise dictate that the
> last request determines the policy on an area, or should
> later requests not be able to override policy that was
> set at mmap time?

That is the question.

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 fork?  Does it have any connection at all to the
file?  Or, do we drop all references to the file and essentially transform
it to a private (or shared?) anonymous mapping after fork.  What about
System V shared memory?  What about hugetlb?

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

-- 
Mike Kravetz