Centos-kernel-stream-9/tools/testing/selftests/livepatch/test-syscall.sh

57 lines
1.7 KiB
Bash
Raw Normal View History

selftests: livepatch: Test livepatching a heavily called syscall JIRA: https://issues.redhat.com/browse/RHEL-61781 Conflicts: - Moved (test_klp-call_getpid.c, test_klp_syscall.c) to /lib/livepatch/ from /tools/testing/selftests/livepatch/ - Edited lib/livepatch/Makefile to compile the new files: (test_klp-call_getpid.c, test_klp_syscall.c) The test proves that a syscall can be livepatched. It is interesting because syscalls are called a tricky way. Also the process gets livepatched either when sleeping in the userspace or when entering or leaving the kernel space. The livepatch is a bit tricky: 1. The syscall function name is architecture specific. Also ARCH_HAS_SYSCALL_WRAPPER must be taken in account. 2. The syscall must stay working the same way for other processes on the system. It is solved by decrementing a counter only for PIDs of the test processes. It means that the test processes has to call the livepatched syscall at least once. The test creates one userspace process per online cpu. The processes are calling getpid in a busy loop. The intention is to create random locations when the livepatch gets enabled. Nothing is guarantted. The magic is in the randomness. Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> (cherry picked from commit 6a71770442b5b7cf8f880ca1c0a72456c918c757) Signed-off-by: Ryan Sullivan <rysulliv@redhat.com>
2024-10-10 20:58:25 +00:00
#!/bin/bash
# SPDX-License-Identifier: GPL-2.0
# Copyright (C) 2023 SUSE
# Author: Marcos Paulo de Souza <mpdesouza@suse.com>
. $(dirname $0)/functions.sh
MOD_SYSCALL=test_klp_syscall
setup_config
# - Start _NRPROC processes calling getpid and load a livepatch to patch the
# getpid syscall. Check if all the processes transitioned to the livepatched
# state.
start_test "patch getpid syscall while being heavily hammered"
NPROC=$(getconf _NPROCESSORS_ONLN)
MAXPROC=128
for i in $(seq 1 $(($NPROC < $MAXPROC ? $NPROC : $MAXPROC))); do
selftests: livepatch: Test livepatching a heavily called syscall JIRA: https://issues.redhat.com/browse/RHEL-61781 Conflicts: - Moved (test_klp-call_getpid.c, test_klp_syscall.c) to /lib/livepatch/ from /tools/testing/selftests/livepatch/ - Edited lib/livepatch/Makefile to compile the new files: (test_klp-call_getpid.c, test_klp_syscall.c) The test proves that a syscall can be livepatched. It is interesting because syscalls are called a tricky way. Also the process gets livepatched either when sleeping in the userspace or when entering or leaving the kernel space. The livepatch is a bit tricky: 1. The syscall function name is architecture specific. Also ARCH_HAS_SYSCALL_WRAPPER must be taken in account. 2. The syscall must stay working the same way for other processes on the system. It is solved by decrementing a counter only for PIDs of the test processes. It means that the test processes has to call the livepatched syscall at least once. The test creates one userspace process per online cpu. The processes are calling getpid in a busy loop. The intention is to create random locations when the livepatch gets enabled. Nothing is guarantted. The magic is in the randomness. Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> (cherry picked from commit 6a71770442b5b7cf8f880ca1c0a72456c918c757) Signed-off-by: Ryan Sullivan <rysulliv@redhat.com>
2024-10-10 20:58:25 +00:00
./test_klp-call_getpid &
pids[$i]="$!"
done
pid_list=$(echo ${pids[@]} | tr ' ' ',')
load_lp $MOD_SYSCALL klp_pids=$pid_list
# wait for all tasks to transition to patched state
loop_until 'grep -q '^0$' $SYSFS_KERNEL_DIR/$MOD_SYSCALL/npids'
selftests: livepatch: Test livepatching a heavily called syscall JIRA: https://issues.redhat.com/browse/RHEL-61781 Conflicts: - Moved (test_klp-call_getpid.c, test_klp_syscall.c) to /lib/livepatch/ from /tools/testing/selftests/livepatch/ - Edited lib/livepatch/Makefile to compile the new files: (test_klp-call_getpid.c, test_klp_syscall.c) The test proves that a syscall can be livepatched. It is interesting because syscalls are called a tricky way. Also the process gets livepatched either when sleeping in the userspace or when entering or leaving the kernel space. The livepatch is a bit tricky: 1. The syscall function name is architecture specific. Also ARCH_HAS_SYSCALL_WRAPPER must be taken in account. 2. The syscall must stay working the same way for other processes on the system. It is solved by decrementing a counter only for PIDs of the test processes. It means that the test processes has to call the livepatched syscall at least once. The test creates one userspace process per online cpu. The processes are calling getpid in a busy loop. The intention is to create random locations when the livepatch gets enabled. Nothing is guarantted. The magic is in the randomness. Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> (cherry picked from commit 6a71770442b5b7cf8f880ca1c0a72456c918c757) Signed-off-by: Ryan Sullivan <rysulliv@redhat.com>
2024-10-10 20:58:25 +00:00
pending_pids=$(cat $SYSFS_KERNEL_DIR/$MOD_SYSCALL/npids)
selftests: livepatch: Test livepatching a heavily called syscall JIRA: https://issues.redhat.com/browse/RHEL-61781 Conflicts: - Moved (test_klp-call_getpid.c, test_klp_syscall.c) to /lib/livepatch/ from /tools/testing/selftests/livepatch/ - Edited lib/livepatch/Makefile to compile the new files: (test_klp-call_getpid.c, test_klp_syscall.c) The test proves that a syscall can be livepatched. It is interesting because syscalls are called a tricky way. Also the process gets livepatched either when sleeping in the userspace or when entering or leaving the kernel space. The livepatch is a bit tricky: 1. The syscall function name is architecture specific. Also ARCH_HAS_SYSCALL_WRAPPER must be taken in account. 2. The syscall must stay working the same way for other processes on the system. It is solved by decrementing a counter only for PIDs of the test processes. It means that the test processes has to call the livepatched syscall at least once. The test creates one userspace process per online cpu. The processes are calling getpid in a busy loop. The intention is to create random locations when the livepatch gets enabled. Nothing is guarantted. The magic is in the randomness. Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> (cherry picked from commit 6a71770442b5b7cf8f880ca1c0a72456c918c757) Signed-off-by: Ryan Sullivan <rysulliv@redhat.com>
2024-10-10 20:58:25 +00:00
log "$MOD_SYSCALL: Remaining not livepatched processes: $pending_pids"
for pid in ${pids[@]}; do
kill $pid || true
done
disable_lp $MOD_SYSCALL
unload_lp $MOD_SYSCALL
check_result "% modprobe $MOD_SYSCALL klp_pids=$pid_list
selftests: livepatch: Test livepatching a heavily called syscall JIRA: https://issues.redhat.com/browse/RHEL-61781 Conflicts: - Moved (test_klp-call_getpid.c, test_klp_syscall.c) to /lib/livepatch/ from /tools/testing/selftests/livepatch/ - Edited lib/livepatch/Makefile to compile the new files: (test_klp-call_getpid.c, test_klp_syscall.c) The test proves that a syscall can be livepatched. It is interesting because syscalls are called a tricky way. Also the process gets livepatched either when sleeping in the userspace or when entering or leaving the kernel space. The livepatch is a bit tricky: 1. The syscall function name is architecture specific. Also ARCH_HAS_SYSCALL_WRAPPER must be taken in account. 2. The syscall must stay working the same way for other processes on the system. It is solved by decrementing a counter only for PIDs of the test processes. It means that the test processes has to call the livepatched syscall at least once. The test creates one userspace process per online cpu. The processes are calling getpid in a busy loop. The intention is to create random locations when the livepatch gets enabled. Nothing is guarantted. The magic is in the randomness. Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> (cherry picked from commit 6a71770442b5b7cf8f880ca1c0a72456c918c757) Signed-off-by: Ryan Sullivan <rysulliv@redhat.com>
2024-10-10 20:58:25 +00:00
livepatch: enabling patch '$MOD_SYSCALL'
livepatch: '$MOD_SYSCALL': initializing patching transition
livepatch: '$MOD_SYSCALL': starting patching transition
livepatch: '$MOD_SYSCALL': completing patching transition
livepatch: '$MOD_SYSCALL': patching complete
$MOD_SYSCALL: Remaining not livepatched processes: 0
% echo 0 > $SYSFS_KLP_DIR/$MOD_SYSCALL/enabled
selftests: livepatch: Test livepatching a heavily called syscall JIRA: https://issues.redhat.com/browse/RHEL-61781 Conflicts: - Moved (test_klp-call_getpid.c, test_klp_syscall.c) to /lib/livepatch/ from /tools/testing/selftests/livepatch/ - Edited lib/livepatch/Makefile to compile the new files: (test_klp-call_getpid.c, test_klp_syscall.c) The test proves that a syscall can be livepatched. It is interesting because syscalls are called a tricky way. Also the process gets livepatched either when sleeping in the userspace or when entering or leaving the kernel space. The livepatch is a bit tricky: 1. The syscall function name is architecture specific. Also ARCH_HAS_SYSCALL_WRAPPER must be taken in account. 2. The syscall must stay working the same way for other processes on the system. It is solved by decrementing a counter only for PIDs of the test processes. It means that the test processes has to call the livepatched syscall at least once. The test creates one userspace process per online cpu. The processes are calling getpid in a busy loop. The intention is to create random locations when the livepatch gets enabled. Nothing is guarantted. The magic is in the randomness. Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> (cherry picked from commit 6a71770442b5b7cf8f880ca1c0a72456c918c757) Signed-off-by: Ryan Sullivan <rysulliv@redhat.com>
2024-10-10 20:58:25 +00:00
livepatch: '$MOD_SYSCALL': initializing unpatching transition
livepatch: '$MOD_SYSCALL': starting unpatching transition
livepatch: '$MOD_SYSCALL': completing unpatching transition
livepatch: '$MOD_SYSCALL': unpatching complete
% rmmod $MOD_SYSCALL"
exit 0