> On Apr 27, 2020, at 6:36 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Apr 27, 2020 at 5:46 PM Aleksa Sarai <cyphar@xxxxxxxxxx> wrote: >> >> I agree. It would be a shame to add a new ptrace syscall and not take >> the opportunity to fix the multitude of problems with the existing API. >> But that's a Pandora's box which we shouldn't open unless we want to >> wait a long time to get an API everyone is okay with -- a pretty high >> price to just get pidfds support in ptrace. > > We should really be very very careful with some "smarter ptrace". > We've had _so_ many security issues with ptrace that it's not even > funny. > > And that's ignoring all the practical issues we've had. > > I would definitely not want to have anything that looks like ptrace AT > ALL using pidfd. If we have a file descriptor to specify the target > process, then we should probably take advantage of that file > descriptor to actually make it more of a asynchronous interface that > doesn't cause the kinds of deadlocks that we've had with ptrace. > > The synchronous nature of ptrace() means that not only do we have > those nasty deadlocks, it's also very very expensive to use. It also > has some other fundamental problems, like the whole "take over parent" > and the SIGCHLD behavior. > > It also is hard to ptrace a ptracer. Which is annoying when you're > debugging gdb or strace or whatever. > > So I think the thing to do is ask the gdb (and strace) people if they > have any _very_ particular painpoints that we could perhaps help with. > > And then very carefully think things through and not repeat all the > mistakes ptrace did. > > I'm not very optimistic. I hate to say this, but I’m not convinced that asking the gdb folks is the right approach. GDB has an ancient architecture and is *incredibly* buggy. I’m sure ptrace is somewhere on the pain point list, but I suspect it’s utterly dwarfed by everything else. Maybe the LLDB people would have a better perspective? The rr folks would be a good bet, too. Or, and I know this is sacrilege, the VSCode people? I think one requirement for a better ptrace is that it should work if you try to debug, simultaneously, a debugger and its debugee. Maybe not perfectly, but it should work. And you should be able to debug init. Another major pain point I’ve seen is compat. A 64-bit debugger should be able to debug a program that switches back and forth between 32-bit and 64-bit. A debugger that is entirely unaware of a set of registers should be able to debug a process using those registers.
