linux-kernel - Re: [RFC PATCH for 4.15 v12 00/22] Restartable sequences and CPU op vector

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] [day] [month] [year] [list]

Date:   Fri, 24 Nov 2017 15:47:20 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
cc:     Will Deacon <will.deacon@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andi Kleen <andi@...stfloor.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Andy Lutomirski <luto@...capital.net>,
        Dave Watson <davejwatson@...com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-api <linux-api@...r.kernel.org>,
        Paul Turner <pjt@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Russell King <linux@....linux.org.uk>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Andrew Hunter <ahh@...gle.com>,
        Chris Lameter <cl@...ux.com>, Ben Maurer <bmaurer@...com>,
        rostedt <rostedt@...dmis.org>,
        Josh Triplett <josh@...htriplett.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [RFC PATCH for 4.15 v12 00/22] Restartable sequences and CPU op
 vector

On Fri, 24 Nov 2017, Mathieu Desnoyers wrote:
> ----- On Nov 23, 2017, at 6:38 PM, Thomas Gleixner tglx@...utronix.de wrote:
> > You have to test for sys_rseq somewhere in the init code. So you can test
> > for the other two being fully functional as well.
> > 
> > If one of them is missing then you can avoid that rseq fastpath either
> > completely or because you never registered that rseq muck your rseq will
> > just contain stale init data which kicks you into some slowpath fallback
> > code.
> 
> That would work if we could have more than one rseq TLS entry per thread.
> If it would be the case, then e.g. lttng-ust could own its own rseq
> TLS and do just as you explain above.
> 
> It's not the case with the current proposal. This means multiple user
> libraries will have to share the same cpu_id and cpu_id_start fields,
> which breaks your proposed new-app/old-kernel backward compatibility
> check proposal.
> 
> For instance, if glibc librseq.so happily registers rseq (and does not
> care about testing for cpu_opv or membarrier availability), then
> lttng-ust cannot leave stale rseq init data which kicks in its slowpath
> fallback.

You have to make sure that _ALL_ prerequisites are there before you start
using it whether you have a shared rseq or not. If a setup has rseq working
and sysops are blocked by a stupid mistake in a security filter, then your
assumption of testing rseq alone is broken already and stuff will explode
in hard to debug ways.

You CANNOT make such assumptions ever. Robustness is the first thing to
look at and after that you can optimize the hell out of it, without
violating robustness while doing that.

Thanks,

	tglx