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: <20200715135554.4q6aamx4iqd4mnqh@wittgenstein>
Date:   Wed, 15 Jul 2020 15:55:54 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Florian Weimer <fweimer@...hat.com>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        carlos <carlos@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        paulmck <paulmck@...ux.ibm.com>,
        Boqun Feng <boqun.feng@...il.com>,
        "H. Peter Anvin" <hpa@...or.com>, Paul Turner <pjt@...gle.com>,
        linux-api <linux-api@...r.kernel.org>
Subject: Re: [RFC PATCH 2/4] rseq: Allow extending struct rseq

On Wed, Jul 15, 2020 at 03:42:11PM +0200, Florian Weimer wrote:
> * Mathieu Desnoyers:
> 
> > So indeed it could be done today without upgrading the toolchains by
> > writing custom assembler for each architecture to get the thread's
> > struct rseq. AFAIU the ABI to access the thread pointer is fixed for
> > each architecture, right ?
> 
> Yes, determining the thread pointer and access initial-exec TLS
> variables is baked into the ABI.
> 
> > How would this allow early-rseq-adopter libraries to interact with
> > glibc ?
> 
> Under all extension proposals I've seen so far, early adopters are
> essentially incompatible with glibc rseq registration.  I don't think
> you can have it both ways.

Who are the early adopters? And if we aren't being compatible with them
under the extensible schemes proposed we should be able to achieve
compatibility with non-early adopters, right? Which I guess is more
important. (I still struggle to make sense what qualifies as an early
adopter/what the difference to a non-early adopter is.)

Christian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ