Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes:
On Mon, Jun 21, 2021 at 11:50:56AM -0500, Eric W. Biederman wrote:
Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes:
On Mon, Jun 21, 2021 at 01:54:56PM +0000, Al Viro wrote:
On Tue, Jun 15, 2021 at 02:58:12PM -0700, Linus Torvalds wrote:
And I think our horrible "kernel threads return to user space when
done" is absolutely horrifically nasty. Maybe of the clever sort, but
mostly of the historical horror sort.
How would you prefer to handle that, then? Separate magical path from
kernel_execve() to switch to userland? We used to have something of
that sort, and that had been a real horror...
As it is, it's "kernel thread is spawned at the point similar to
ret_from_fork(), runs the payload (which almost never returns) and
then proceeds out to userland, same way fork(2) would've done."
That way kernel_execve() doesn't have to do anything magical.
Al, digging through the old notes and current call graph...
FWIW, the major assumption back then had been that get_signal(),
signal_delivered() and all associated machinery (including coredumps)
runs *only* from SIGPENDING/NOTIFY_SIGNAL handling.
And "has complete registers on stack" is only a part of that;
there was other fun stuff in the area ;-/ Do we want coredumps for
those, and if we do, will the de_thread stuff work there?
Do we want coredumps from processes that use io_uring? yes
Exactly what we want from io_uring threads is less clear. We can't
really give much that is meaningful beyond the thread ids of the
io_uring threads.
What problems do are you seeing beyond the missing registers on the
stack for kernel threads?
I don't immediately see the connection between coredumps and de_thread.
The function de_thread arranges for the fatal_signal_pending to be true,
and that should work just fine for io_uring threads. The io_uring
threads process the fatal_signal with get_signal and then proceed to
exit eventually calling do_exit.
I would like to see the testing in cases when the io-uring thread is
the one getting hit by initial signal and when it's the normal one
with associated io-uring ones. The thread-collecting logics at least
used to depend upon fairly subtle assumptions, and "kernel threads
obviously can't show up as candidates" used to narrow the analysis
down...
In any case, WTF would we allow reads or writes to *any* registers of
such threads? It's not as simple as "just return zeroes", BTW - the
values allowed in special registers might have non-trivial constraints
on them. The same goes for coredump - we don't _have_ registers to
dump for those, period.
Looks like the first things to do would be
* prohibit ptrace accessing any regsets of worker threads
* make coredump skip all register notes for those
Skipping register notes is fine. Prohibiting ptrace access to any
regsets of worker threads is interesting. I think that was tried and
shown to confuse gdb. So the conclusion was just to provide a fake set
of registers.
Which has appears to work up to the point of dealing with architectures
that have their magic caller-saved optimization (like alpha and m68k),
and no check that all of the registers were saved when accessed. Adding
a dummy switch stack frame for the kernel threads on those architectures
looks like a good/cheap solution at first glance.
Note, BTW, that kernel_thread() and kernel_execve() do *NOT* step into
ptrace_notify() - explicit CLONE_UNTRACED for the former and zero
current->ptrace in the caller of the latter. So fork and exec side
has ptrace_event() crap limited to real syscalls.
That is where I thought we were. Thanks for confirming that.
It's seccomp[1] and exit-related stuff that are messy...
[1] "never trust somebody who introduces himself as Honest Joe and keeps
carping on that all the time"; c.f. __secure_computing(), CONFIG_INTEGRITY,
etc.
