Received-SPF: pass (google.com: domain of linux-kernel+bounces-111785-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240315140433.1966543-1-hjl.tools@gmail.com> <5f0620c55a01d6a195154783a477ec295cbb4b1c.camel@intel.com>
 <CAMe9rOrgAtQvA=Tj0=T095JmdoRZ8pLuNOY3sT_RwwnznJN2Ow@mail.gmail.com>
 <7b341bef9c0cab324350873cab75b7e1313a5172.camel@intel.com>
 <CAMe9rOq9=7hS-Ohk+5kOnstp4tFFsAF11L=EKdTm+gUt97ugbg@mail.gmail.com>
 <95a27fd1e3b263d2b002c47751b1b42b3d639bae.camel@intel.com>
 <CAMe9rOpO7=KL5XuvtR=cCSVatEsT5eFn7nuknRnDDQk9PbCb9w@mail.gmail.com> <4df8ad26255726619202eef517e0080ab75762a1.camel@intel.com>
In-Reply-To: <4df8ad26255726619202eef517e0080ab75762a1.camel@intel.com>
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Fri, 22 Mar 2024 09:35:06 -0700
Message-ID: <CAMe9rOo1ZONFgBkuN_Ni3REBRsedNwj3gNnXj1oxB0bQzuNipA@mail.gmail.com>
Subject: Re: [PATCH] x86/shstk: Enable shadow stack for x32
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 22, 2024 at 9:21=E2=80=AFAM Edgecombe, Rick P
<rick.p.edgecombe@intel.com> wrote:
>
> On Fri, 2024-03-22 at 09:07 -0700, H.J. Lu wrote:
> > > I mean it will require kernel work in the future to maintain
> > > support.
> > > That we will have to think about x32 effects when making other
> > > shadow
> > > stack changes.
> >
> > It is way more than kernel SHSTK self tests.
> >
> > > I'll paste my other comment in this thread:
> > >
> > > The main usage of shadow stack is security, and comes with some
> > > overhead. IIUC the main usage of x32 is performance benchmarking
> > > type
> > > stuff. Why would someone want to use shadow stack and x32 together?
> >
> > Improve x32 security and user space IBT will add more improvement.
>
> Please elaborate on the users that will use x32 and shadow stack
> together. How many people are we talking about? They care enough about
> performance to use x32, but also don't mind overhead to increase
> security? Perhaps I'm missing something on what x32 is used for today.

SHSTK is enabled by -fcf-protection which is the default for some OSes
where x32 binaries are SHSTK enabled already.  Enable SHSTK should
have minimum performance overhead.

>
> [snip]
>
> > >
> > > The mapping above 4G was because Peterz raised the possibility that
> > > a
> > > 64 bit process could far call into a 32 bit segment and start doing
> > > signal stuff that would encounter undefined behavior. He wanted it
> > > cleanly blocked. So by keeping the shadow stack above 4GB, existing
> > > processes that turned on shadow stack would be preventing from
> > > transitioning to 32 bit and encountering the missing 32 bit signal
> > > support (because the CPU would #GP during the 32 bit transition if
> > > SSP
> > > is above 4GB).
> > >
> > > Probably there is some interplay between the x32 mmap logic and
> > > shadow
> > > stacks mapping, where it then becomes possible to get below 4GB.
> > > Since
> > > x32 needs the shadow stack to be below 4GB, it's incompatible with
> > > that
> > > solution. So this patch is not sufficient to enable x32 without
> > > side
> > > effects that were previously considered bad.
> >
> > Mapping shadow stack below 4GB on x32 still provides security
> > improvements
> > over no show stack.
>
> Agreed on this point. I don't think x32 shadow stack has to be perfect
> to improve security of the x32 apps.
>
> But Peterz's concern (I think it could probably be re-opened) was that
> the ia32 signal stuff should not be just declared unsupported with
> shadow stack, but blocked from being used somehow. So it was really
> about being able to not have to think about the implications of the
> undefined behavior. (was my understanding at least)
>
> This patch is just turning things on and finding that nothing crashes.
> It needs more analysis.
>

It is more than that.   There are 3 glibc tests to check if SHSTK triggers
show stack violation when there is an intentional show stack mismatch:

[hjl@gnu-tgl-1 build-x86_64-linux]$ ./elf/tst-shstk-legacy-1b
[hjl@gnu-tgl-1 build-x86_64-linux]$ ./elf/tst-shstk-legacy-1b --direct
Segmentation fault (core dumped)
[hjl@gnu-tgl-1 build-x86_64-linux]$
GLIBC_TUNABLES=3Dglibc.cpu.hwcaps=3D-SHSTK ./elf/tst-shstk-legacy-1b
--direct
[hjl@gnu-tgl-1 build-x86_64-linux]$

They pass on x32.

--=20
H.J.