Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201119221132.1515696-1-walt@drummond.us> <20201128052317.GY3576660@ZenIV.linux.org.uk>
 <CADCN6nyGW0=QS=J+704n-mtAqTxgVrKZC=P8d01NZ_pjssptew@mail.gmail.com>
In-Reply-To: <CADCN6nyGW0=QS=J+704n-mtAqTxgVrKZC=P8d01NZ_pjssptew@mail.gmail.com>
From:   Walt Drummond <walt@drummond.us>
Date:   Sat, 28 Nov 2020 18:52:57 -0800
Message-ID: <CADCN6nzdJom0DazzvnRREDKAjRBoNAVhNiQrL3hAXvU-=i4mpg@mail.gmail.com>
Subject: Re: [PATCH] x86/signals: Fix save/restore signal stack to correctly
 support sigset_t
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org,
        hpa@zytor.com, brgerst@gmail.com, linux@dominikbrodowski.net,
        gustavoars@kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

(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@drummond.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 l=
ibc and kernel changes super tightly to pull this off), and any change in t=
he size of struct rt_sigframe would break backwards compatibility with olde=
r binaries, is that correct?
>
> Thanks, appreciate the help here.
> --Walt
>
>
> On Fri, Nov 27, 2020 at 9:23 PM Al Viro <viro@zeniv.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@zeniv.linux.org.uk>