f96bf43403
Add some arm64/signal specific boilerplate and utility code to help further testcases' development. Introduce also one simple testcase mangle_pstate_invalid_compat_toggle and some related helpers: it is a simple mangle testcase which messes with the ucontext_t from within the signal handler, trying to toggle PSTATE state bits to switch the system between 32bit/64bit execution state. Expects SIGSEGV on test PASS. Reviewed-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2.7 KiB
KSelfTest arm64/signal/
Signals Tests +++++++++++++
-
Tests are built around a common main compilation unit: such shared main enforces a standard sequence of operations needed to perform a single signal-test (setup/trigger/run/result/cleanup)
-
The above mentioned ops are configurable on a test-by-test basis: each test is described (and configured) using the descriptor signals.h::struct tdescr
-
Each signal testcase is compiled into its own executable: a separate executable is used for each test since many tests complete successfully by receiving some kind of fatal signal from the Kernel, so it's safer to run each test unit in its own standalone process, so as to start each test from a clean slate.
-
New tests can be simply defined in testcases/ dir providing a proper struct tdescr overriding all the defaults we wish to change (as of now providing a custom run method is mandatory though)
-
Signals' test-cases hereafter defined belong currently to two principal families:
-
'mangle_' tests: a real signal (SIGUSR1) is raised and used as a trigger and then the test case code modifies the signal frame from inside the signal handler itself.
-
'fake_sigreturn_' tests: a brand new custom artificial sigframe structure is placed on the stack and a sigreturn syscall is called to simulate a real signal return. This kind of tests does not use a trigger usually and they are just fired using some simple included assembly trampoline code.
-
-
Most of these tests are successfully passing if the process gets killed by some fatal signal: usually SIGSEGV or SIGBUS. Since while writing this kind of tests it is extremely easy in fact to end-up injecting other unrelated SEGV bugs in the testcases, it becomes extremely tricky to be really sure that the tests are really addressing what they are meant to address and they are not instead falling apart due to unplanned bugs in the test code. In order to alleviate the misery of the life of such test-developer, a few helpers are provided:
-
a couple of ASSERT_BAD/GOOD_CONTEXT() macros to easily parse a ucontext_t and verify if it is indeed GOOD or BAD (depending on what we were expecting), using the same logic/perspective as in the arm64 Kernel signals routines.
-
a sanity mechanism to be used in 'fake_sigreturn_'-alike tests: enabled by default it takes care to verify that the test-execution had at least successfully progressed up to the stage of triggering the fake sigreturn call.
-
In both cases test results are expected in terms of:
- some fatal signal sent by the Kernel to the test process or
- analyzing some final regs state