Files
msm-5.15/tools/testing/selftests/arm64/signal
Mark Brown 82046b6a84 kselftest/arm64: Fix validatation termination record after EXTRA_CONTEXT
[ Upstream commit 5c152c2f66f9368394b89ac90dc7483476ef7b88 ]

When arm64 signal context data overflows the base struct sigcontext it gets
placed in an extra buffer pointed to by a record of type EXTRA_CONTEXT in
the base struct sigcontext which is required to be the last record in the
base struct sigframe. The current validation code attempts to check this
by using GET_RESV_NEXT_HEAD() to step forward from the current record to
the next but that is a macro which assumes it is being provided with a
struct _aarch64_ctx and uses the size there to skip forward to the next
record. Instead validate_extra_context() passes it a struct extra_context
which has a separate size field. This compiles but results in us trying
to validate a termination record in completely the wrong place, at best
failing validation and at worst just segfaulting. Fix this by passing
the struct _aarch64_ctx we meant to into the macro.

Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220829160703.874492-4-broonie@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-26 12:35:44 +02:00
..

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