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  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 <>
To:     Mathieu Desnoyers <>
cc:     Will Deacon <>,
        Peter Zijlstra <>,
        Andi Kleen <>,
        "Paul E. McKenney" <>,
        Boqun Feng <>,
        Andy Lutomirski <>,
        Dave Watson <>,
        linux-kernel <>,
        linux-api <>,
        Paul Turner <>,
        Andrew Morton <>,
        Russell King <>,
        Ingo Molnar <>,
        "H. Peter Anvin" <>, Andrew Hunter <>,
        Chris Lameter <>, Ben Maurer <>,
        rostedt <>,
        Josh Triplett <>,
        Linus Torvalds <>,
        Catalin Marinas <>,
        Michael Kerrisk <>
Subject: Re: [RFC PATCH for 4.15 v12 00/22] Restartable sequences and CPU op

On Fri, 24 Nov 2017, Mathieu Desnoyers wrote:
> ----- On Nov 23, 2017, at 6:38 PM, Thomas Gleixner 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 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.



Powered by blists - more mailing lists