linux-kernel - Re: [PATCH] x86/signals: Fix save/restore signal stack to correctly support sigset

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

Message-ID: <CADCN6nzdJom0DazzvnRREDKAjRBoNAVhNiQrL3hAXvU-=i4mpg@mail.gmail.com>
Date:   Sat, 28 Nov 2020 18:52:57 -0800
From:   Walt Drummond <walt@...mmond.us>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, x86@...nel.org,
        hpa@...or.com, brgerst@...il.com, linux@...inikbrodowski.net,
        gustavoars@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/signals: Fix save/restore signal stack to correctly
 support sigset_t

(Sorry, resending as Gmail decided to ignore "Plaintext mode")

Thanks Al.  I want to understand the nuance, so please bear with me as
I reason this out.   The cast in stone nature of this is due to both
the need to keep userspace and kernel space in sync (ie, you'd have to
coordinate libc and kernel changes super tightly to pull this off),
and any change in the size of struct rt_sigframe would break backwards
compatibility with older binaries, is that correct?

Thanks, appreciate the help here.
--Walt


On Sat, Nov 28, 2020 at 6:19 PM Walt Drummond <walt@...mmond.us> wrote:
>
> Thanks Al.  I want to understand the nuance, so please bear with me as I reason this out.   The cast in stone nature of this is due to both the need to keep userspace and kernel space in sync (ie, you'd have to coordinate libc and kernel changes super tightly to pull this off), and any change in the size of struct rt_sigframe would break backwards compatibility with older binaries, is that correct?
>
> Thanks, appreciate the help here.
> --Walt
>
>
> On Fri, Nov 27, 2020 at 9:23 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>>
>> On Thu, Nov 19, 2020 at 02:11:33PM -0800, Walt Drummond wrote:
>> > The macro unsafe_put_sigmask() only handles the first 64 bits of the
>> > sigmask_t, which works today.  However, if the definition of the
>> > sigset_t structure ever changed,
>>
>> ... existing userland would get fucked over, since sigset_t is
>> present in user-visible data structures.  Including the ones
>> we are using that thing for - struct rt_sigframe, for starters.
>>
>> Layout of those suckers is very much cast in stone.  We *can't*
>> change it, no matter what we do kernel-side.
>>
>> NAKed-by: Al Viro <viro@...iv.linux.org.uk>