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 09:02:15 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Will Deacon <will.deacon@....com>,
        Alan Stern <stern@...land.harvard.edu>,
        Andrew Lutomirski <luto@...nel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        "linux-kernel@...r.kernel.org" <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 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.

Also, can you elaborate on the PPC issue?  PPC appears to track
mm_cpumask more or less just like x86.  Is the issue just that this
tracking has no implied barriers?  If so, how does TLB flush on ppc
work?  It really does seem impressive to me that an architecture can
efficiently support munmap() but not an expedited private membarrier.

--Andy