On 3/4/20 10:56 PM, Bernd Edlinger wrote:
This fixes a deadlock in the tracer when tracing a multi-threaded
application that calls execve while more than one thread are running.
I observed that when running strace on the gcc test suite, it always
blocks after a while, when expect calls execve, because other threads
have to be terminated. They send ptrace events, but the strace is no
longer able to respond, since it is blocked in vm_access.
The deadlock is always happening when strace needs to access the
tracees process mmap, while another thread in the tracee starts to
execve a child process, but that cannot continue until the
PTRACE_EVENT_EXIT is handled and the WIFEXITED event is received:
strace D 0 30614 30584 0x00000000
Call Trace:
__schedule+0x3ce/0x6e0
schedule+0x5c/0xd0
schedule_preempt_disabled+0x15/0x20
__mutex_lock.isra.13+0x1ec/0x520
__mutex_lock_killable_slowpath+0x13/0x20
mutex_lock_killable+0x28/0x30
mm_access+0x27/0xa0
process_vm_rw_core.isra.3+0xff/0x550
process_vm_rw+0xdd/0xf0
__x64_sys_process_vm_readv+0x31/0x40
do_syscall_64+0x64/0x220
entry_SYSCALL_64_after_hwframe+0x44/0xa9
expect D 0 31933 30876 0x80004003
Call Trace:
__schedule+0x3ce/0x6e0
schedule+0x5c/0xd0
flush_old_exec+0xc4/0x770
load_elf_binary+0x35a/0x16c0
search_binary_handler+0x97/0x1d0
__do_execve_file.isra.40+0x5d4/0x8a0
__x64_sys_execve+0x49/0x60
do_syscall_64+0x64/0x220
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The proposed solution is to detect if a sibling thread
exists that is traced and in this case to make PTRACE_ACCESS
fail with -EAGAIN instead of dead-lock.
But other functions like vm_access are allowed to complete normally.
This changes the lifetime of the cred_guard_mutex lock to be
from flush_old_exec() through install_exec_creds().
Before, cred_guard_mutex was held from prepare_bprm_creds() through
install_exec_creds().
Additionally a new mutex exec_guard_mutex is introduced that is used
for PTRACE_ACCESS and SECCOMP_FILTER_FLAG_TSYNC.
Signed-off-by: Bernd Edlinger <redacted>
---
Documentation/security/credentials.rst | 29 ++++++++---
fs/exec.c | 58 ++++++++++++++++++---
include/linux/binfmts.h | 15 +++++-
include/linux/sched/signal.h | 10 ++--
init/init_task.c | 1 +
kernel/cred.c | 4 +-
kernel/fork.c | 1 +
kernel/ptrace.c | 20 ++++++--
kernel/seccomp.c | 15 +++---
mm/process_vm_access.c | 2 +-
tools/testing/selftests/ptrace/Makefile | 4 +-
tools/testing/selftests/ptrace/vmaccess.c | 85 +++++++++++++++++++++++++++++++
12 files changed, 210 insertions(+), 34 deletions(-)
create mode 100644 tools/testing/selftests/ptrace/vmaccess.c
Okay, I think there is consensus about the next steps to be as follows:
- post the Documentation/security/credentials.rst changes as an independent patch.
- post a infrastructure patch which only introduces two new mutexes,
one exec_guard_mutex, and one the "cred_change_mutex" (I am unhappy with that name,
because credentials can change without the cred_guard_mutex, this appears more
to guarantee that the credentials of the process and the process memory map are
consistent, so I think I need to think of a better name first...)
This keeps cred_guard_mutex as is, just deprecates it, and adds a note that it will
go away.
- post one patch that fixes the mm_access code path
- post one patch that fixes the PTRACE_ATTACH code path
- post one patch that introduces the new test cases
Thanks
Bernd.