Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
On Mon, Jun 21, 2021 at 4:23 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:How would it help e.g. oopsen on the way out of timer interrupts? IMO we simply shouldn't allow ptrace access if the tracee is in that kind of state, on any architecture...Yeah no, we can't do the "wait for ptrace" when the exit is due to an oops. Although honestly, we have other cases like that where do_exit() isn't 100% robust if you kill something in an interrupt. Like all the locks it leaves locked etc. So do_exit() from a timer interrupt is going to cause problems regardless. I agree it's probably a good idea to try to avoid causing even more with the odd ptrace thing, but I don't think ptrace_event is some really "fundamental" problem at that point - it's just one detail among many many. So I was more thinking of the debug patch for m68k to catch all the _regular_ cases, and all the other random cases of ptrace_event() or ptrace_notify(). Although maybe we've really caught them all. The exit case was clearly missing, and the thread fork case was scrogged. There are patches for the known problems. The patches I really don't like are the verification ones to find any unknown ones..
We still have nios2 which copied the m68k logic at some point. I think that is a processor that is still ``shipping'' and that people might still be using in new designs. I haven't looked closely enough to see what the other architectures with caller saved registers are doing. The challenging ones are /proc/pid/syscall and seccomp which want to see all of the system call arguments. I think every architecture always saves the system call arguments unconditionally, so those cases are probably not as interesting. But they certain look like they could be trouble. Eric
