[PATCH v10 38/40] kselftest/arm64: Add a GCS stress test

[Mark Brown]

On Wed, Aug 07, 2024 at 07:39:54PM -0300, Thiago Jung Bauermann wrote:
> Mark Brown <broonie at kernel.org> writes:

> > Add a stress test which runs one more process than we have CPUs spinning
> > through a very recursive function with frequent syscalls immediately prior

> Unfortunately, gcs-stress still fails on my FVP setup. I tested on an
> arm64 defconfig with and without THP enabled with, the same results:

Can you please try to investigate why this is happening on your system?
I am unable to reproduce this, for example the actual branch that was
posted gave this:

# selftests: arm64: gcs-stress
# TAP version 13
# 1..9
# # 8 CPUs, 9 GCS threads
# # Will run for 10s
# # Started Thread-8350
# # Started Thread-8351
# # Started Thread-8352
# # Started Thread-8353
# # Started Thread-8354
# # Started Thread-8355
# # Started Thread-8356
# # Started Thread-8357
# # Started Thread-8358
# # Thread-8350: Running

...

# # Sending signals, timeout remaining: 100ms
# # Finishing up...
# # Thread-8351: Terminated by signal 15, no error
# # Thread-8352: Terminated by signal 15, no error
# # Thread-8353: Terminated by signal 15, no error
# # Thread-8354: Terminated by signal 15, no error
# # Thread-8355: Terminated by signal 15, no error
# # Thread-8357: Terminated by signal 15, no error
# # Thread-8358: Terminated by signal 15, no error
# ok 1 Thread-8350
# ok 2 Thread-8351
# ok 3 Thread-8352
# ok 4 Thread-8353
# ok 5 Thread-8354
# ok 6 Thread-8355
# ok 7 Thread-8356
# ok 8 Thread-8357
# ok 9 Thread-8358
# # Thread-8356: Terminated by signal 15, no error
# # Thread-8350: Terminated by signal 15, no error
# # Totals: pass:9 fail:0 xfail:0 xpass:0 skip:0 error:0

and Anders also ran the selftests successfully, including with THP
enabled (as noted in the changelog those issues should now be resolved).
THP issues should not have been relevant for this test as it doesn't
fork with GCS enabled.

> # # Thread-4870: Failed to enable GCS

which is printed if a basic PR_SET_SHADOW_STACK_STATUS fails immediately
the program starts executing:

function _start
        // Run with GCS
        mov     x0, PR_SET_SHADOW_STACK_STATUS
        mov     x1, PR_SHADOW_STACK_ENABLE
        mov     x2, xzr
        mov     x3, xzr
        mov     x4, xzr
        mov     x5, xzr
        mov     x8, #__NR_prctl
        svc     #0
        cbz     x0, 1f
        puts    "Failed to enable GCS\n"
        b       abort

the defines for which all seem up to date (and unlikely to fail in
system or config specific fashions).  What happens if you try to execute
the gcs-stress-thread binary directly, does strace show anything
interesting?  If you instrument arch_set_shadow_stack_status() in the
kernel does it show anything?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240808/8ec8fdcc/attachment.sig>