Re: [PATCH RFT v4 5/5] kselftest/clone3: Test shadow stack support

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Tue, 2023-12-05 at 15:05 +0000, Mark Brown wrote:
> > But I wonder if the clone3 test should get its shadow stack enabled
> > the
> > conventional elf bit way. So if it's all there (HW, kernel, glibc)
> > then
> > the test will run with shadow stack. Otherwise the test will run
> > without shadow stack.
> 
> This creates bootstrapping issues if we do it for arm64 where nothing
> is
> merged yet except for the model and EL3 support - in order to get any
> test coverage you need to be using an OS with the libc and toolchain
> support available and that's not going to be something we can rely on
> for a while (and even when things are merged a lot of the CI systems
> use
> Debian).  There is a small risk that the toolchain will generate
> incompatible code if it doesn't know it's specifically targetting
> shadow
> stacks but the toolchain people didn't seem concerned about that risk
> and we've not been running into problems.
> 
> It looks x86 is in better shape here with the userspace having run
> ahead
> of the kernel support though I'm not 100% clear if everything is
> fully
> lined up?  -mshstk -fcf-protection appears to build fine with gcc 8
> but
> I'm a bit less clear on glibc and any ABI variations.

Right, you would need a shadow stack enabled compiler too. The
check_cc.sh piece in the Makefile will detect that.

Hmm, I didn't realize you were planning to have the kernel support
upstream before the libc support was in testable shape.


> 
> > The other reason is that the shadow stack test in the x86 selftest
> > manual enabling is designed to work without a shadow stack enabled
> > glibc and has to be specially crafted to work around the missing
> > support. I'm not sure the more generic selftests should have to
> > know
> > how to do this. So what about something like this instead:
> 
> What's the issue with working around the missing support?  My
> understanding was that there should be no ill effects from repeated
> attempts to enable.  We could add a check for things already being
> enabled

Normally the loader enables shadow stack and glibc then knows to do
things in special ways when it is successful. If it instead manually
enables in the app:
 - The app can't return from main() without disabling shadow stack 
   beforehand. Luckily this test directly calls exit()
 - The app can't do longjmp()
 - The app can't do ucontext stuff
 - The enabling code needs to be carefully crafted (the inline problem 
   you hit)

I guess it's not a huge list, and mostly tests will run ok. But it
doesn't seem right to add somewhat hacky shadow stack crud into generic
tests.

So you were planning to enable GCS in this test manually as well? How
many tests were you planning to add it like this?