On Wed, Aug 07, 2024 at 07:39:54PM -0300, Thiago Jung Bauermann wrote:
Mark Brown broonie@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?