• Mark Brown's avatar
    kselftest/arm64: Test that ptrace takes effect in the target process · c745b15c
    Mark Brown authored
    While we have test coverage for the ptrace interface in our selftests
    the current programs have a number of gaps. The testing is done per
    regset so does not cover interactions and at no point do any of the
    tests actually run the traced processes meaning that there is no
    validation that anything we read or write corresponds to register values
    the process actually sees. Let's add a new program which attempts to cover
    these gaps.
    
    Each test we do performs a single ptrace write. For each test we generate
    some random initial register data in memory and then fork() and trace a
    child. The child will load the generated data into the registers then
    trigger a breakpoint. The parent waits for the breakpoint then reads the
    entire child register state via ptrace, verifying that the values expected
    were actually loaded by the child. It then does the write being tested
    and resumes the child. Once resumed the child saves the register state
    it sees to memory and executes another breakpoint. The parent uses
    process_vm_readv() to get these values from the child and verifies that
    the values were as expected before cleaning up the child.
    
    We generate configurations with combinations of vector lengths and SVCR
    values and then try every ptrace write which will implement the
    transition we generated. In order to control execution time (especially
    in emulation) we only cover the minimum and maximum VL for each of SVE
    and SME, this will ensure we generate both increasing and decreasing
    changes in vector length. In order to provide a baseline test we also
    check the case where we resume the child without doing a ptrace write.
    
    In order to simplify the generation of the test count for kselftest we
    will report but skip a substantial number of tests that can't actually
    be expressed via a single ptrace write, several times more than we
    actually run. This is noisy and will add some overhead but is very much
    simpler so is probably worth the tradeoff.
    Signed-off-by: default avatarMark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20240122-arm64-test-ptrace-regs-v1-1-0897f822d73e@kernel.orgSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    c745b15c
fp-ptrace.c 35.1 KB