Thread (21 messages) 21 messages, 6 authors, 2021-06-22

Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads

From: Al Viro <viro@zeniv.linux.org.uk>
Date: 2021-06-21 19:45:56
Also in: linux-alpha, linux-m68k, lkml

Possibly related (same subject, not in this thread)

On Mon, Jun 21, 2021 at 12:22:06PM -0700, Linus Torvalds wrote:
On Mon, Jun 21, 2021 at 11:59 AM Al Viro [off-list ref] wrote:
quoted
        There's a large mess around do_exit() - we have a bunch of
callers all over arch/*; if nothing else, I very much doubt that really
want to let tracer play with a thread in the middle of die_if_kernel()
or similar.
Right you are.

I'm really beginning to hate ptrace_{event,notify}() and those
PTRACE_EVENT_xyz things.

I don't even know what uses them, honestly. How very annoying.

I guess it's easy enough (famous last words) to move the
ptrace_event() call out of do_exit() and into the actual
exit/exit_group system calls, and the signal handling path. The paths
that actually have proper pt_regs.

Looks like sys_exit() and do_group_exit() would be the two places to
do it (do_group_exit() would handle the signal case and
sys_group_exit()).
Maybe...  I'm digging through that pile right now, will follow up when
I get a reasonably complete picture.  In the meanwhile, do kernel/kthread.c
uses look even remotely sane?  Intentional - sure, but it really looks
wrong to use thread exit code as communication channel there...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help