linux-kernel - Re: Rough notes from sys_membarrier() lightning BoF

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]

Date:   Wed, 20 Sep 2017 19:57:04 +0000 (UTC)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Will Deacon <will.deacon@....com>,
        Alan Stern <stern@...land.harvard.edu>,
        Michael Ellerman <mpe@...erman.id.au>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Dave Watson <davejwatson@...com>,
        maged michael <maged.michael@...il.com>
Subject: Re: Rough notes from sys_membarrier() lightning BoF

----- On Sep 20, 2017, at 2:18 PM, Andy Lutomirski luto@...nel.org wrote:

> On Wed, Sep 20, 2017 at 11:13 AM, Mathieu Desnoyers
> <mathieu.desnoyers@...icios.com> wrote:
>>
>> ----- On Sep 20, 2017, at 12:02 PM, Andy Lutomirski luto@...nel.org wrote:
>>
>> > On Sun, Sep 17, 2017 at 3:36 PM, Paul E. McKenney
>> > <paulmck@...ux.vnet.ibm.com> wrote:
>> >> Hello!
>> >>
>> >> Rough notes from our discussion last Thursday.  Please reply to the
>> >> group with any needed elaborations or corrections.
>> >>
>> >> Adding Andy and Michael on CC since this most closely affects their
>> >> architectures.  Also adding Dave Watson and Maged Michael because
>> >> the preferred approach requires that processes wanting to use the
>> >> lightweight sys_membarrier() do a registration step.
>> >
>> > Not to be too much of a curmudgeon, but I think that there should be a
>> > real implementation of the isync membarrier before this get merged.
>> > This series purports to solve two problems, ppc barriers and x86
>> > exit-without-isync, but it's very hard to evaluate whether it actually
>> > solves the latter problem given the complete lack of x86 or isync code
>> > in the current RFC.
>> >
>> > It still seems to me that you won't get any particular advantage for
>> > using this registration mechanism on x86 even when you implement
>> > isync.  Unless I've misunderstood, the only real issue on x86 is that
>> > you need a helper like arch_force_isync_before_usermode(), and that
>> > helper doesn't presently exist.  That means that this whole patchset
>> > is standing on very dangerous ground: you'll end up with an efficient
>> > implementation that works just fine without even requesting
>> > registration on every architecture except ppc.  That way lies
>> > userspace bugs.
>>
>> My proposed RFC for private expedited membarrier enforces that all
>> architectures perform the registration step. Using the "PRIVATE_EXPEDITED"
>> command without prior process registration returns an error on all
>> architectures. The goal here is to make all architectures behave in the
>> same way, and it allows us to rely on process registration to deal
>> with future arch-specific optimizations.
> 
> Fair enough.
> 
> That being said, on same architectures (which may well be all but
> PPC), it might be nice if the registration call literally just sets a
> flag in the mm saying that it happened so that the registration
> enforcement can be done.

My RFC patch does exactly that. :-)

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com