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: <134bbcf4-5717-7f53-0bf1-57158e948bbe@redhat.com>
Date:   Mon, 7 Aug 2017 16:19:18 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Michal Hocko <mhocko@...nel.org>, riel@...hat.com
Cc:     linux-kernel@...r.kernel.org, mike.kravetz@...cle.com,
        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,
        linux-api@...r.kernel.org
Subject: 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 up, of course, but I think it's possible to write a lock-free
algorithm to maintain the state even without strong guarantees of memory
ordering from fork.

In the DRBG uniqueness case, you don't care if you reinitialize because
it's the first use, or because a fork just happened.

In the API-mandated fork check, a detection false positive before a fork
is not acceptable (because it would prevent legitimate API use), but I
think you can deal with this case if you publish a pointer to a
pre-initialized, non-zero mapping.

Thanks,
Florian