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: <a0d79f77-f916-d3d6-1d61-a052581dbd4a@oracle.com>
Date:   Mon, 7 Aug 2017 11:23:50 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     riel@...hat.com, linux-kernel@...r.kernel.org
Cc:     linux-mm@...ck.org, fweimer@...hat.com, 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/06/2017 07:04 AM, riel@...hat.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 might be private anonymous mappings.
If a shared or file backed mapping exists, one would assume that it
was created with the intention of sharing, even across fork.  So,
setting MADV_DONTFORK on such a mapping seems to change the meaning
and conflict with the original intention of the mapping.

If my thoughts above are correct, what about returning EINVAL if one
attempts to set MADV_DONTFORK on mappings set up for sharing?

If not, and you really want this to be applicable to all mappings, then
you should be more specific about what happens at fork time.  Do they
all get turned into anonymous mappings?  What happens to file references?
What about the really ugly case of hugetlb mappings?  Do they get
'transformed' to non-hugetlb mappings?  Or, do you create a separate
hugetlb mapping for the child?

-- 
Mike Kravetz