linux-kernel - Re: [RFC PATCH 02/15] rseq: Remove broken uapi field layout on 32-bit little endian

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: <87fspa92xk.fsf@mid.deneb.enyo.de>
Date:   Wed, 26 Jan 2022 12:00:55 +0100
From:   Florian Weimer <fw@...eb.enyo.de>
To:     Christian Brauner <brauner@...nel.org>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        paulmck <paulmck@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
        "H. Peter Anvin" <hpa@...or.com>, Paul Turner <pjt@...gle.com>,
        linux-api <linux-api@...r.kernel.org>, shuah <shuah@...nel.org>,
        linux-kselftest <linux-kselftest@...r.kernel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Dave Watson <davejwatson@...com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Russell King <linux@....linux.org.uk>,
        Andi Kleen <andi@...stfloor.org>,
        Christian Brauner <christian.brauner@...ntu.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>,
        Will Deacon <will.deacon@....com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Joel Fernandes <joelaf@...gle.com>
Subject: Re: [RFC PATCH 02/15] rseq: Remove broken uapi field layout on
 32-bit little endian

* Christian Brauner:

> On Tue, Jan 25, 2022 at 02:00:48PM -0500, Mathieu Desnoyers wrote:
>> So users of the uapi rseq.h (as an API) can still use
>> rseq_abi->rseq_cs before and after the change.
>> 
>> Based on this, I am inclined to remove the union, and just make the
>> rseq_cs field a __u64.
>> 
>> Any objections ?
>
> I do like it fwiw. But since I haven't been heavily involved in the
> userspace usage of this I can't speak confidently to the regression
> potential of a change like this. But I would think that we should risk
> it instead of dragging a pointless union around forever.

I don't think glibc needs changes for this, it will keep building just
fine.  We'll need to adjust the included kernel header fragment that
could be used by applications in some corner cases, but that's it.