[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <B7A115CB-0C8C-4719-B97B-74D94231CD1E@amacapital.net>
Date: Mon, 27 Apr 2020 21:17:26 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Aleksa Sarai <cyphar@...har.com>,
Christian Brauner <christian.brauner@...ntu.com>,
Arnd Bergmann <arnd@...db.de>,
Hagen Paul Pfeifer <hagen@...u.net>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Jann Horn <jannh@...gle.com>,
kernel list <linux-kernel@...r.kernel.org>,
Florian Weimer <fweimer@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <christian@...uner.io>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, Brian Gerst <brgerst@...il.com>,
Sami Tolvanen <samitolvanen@...gle.com>,
David Howells <dhowells@...hat.com>,
Andy Lutomirski <luto@...nel.org>,
Oleg Nesterov <oleg@...hat.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Sargun Dhillon <sargun@...gun.me>,
Linux API <linux-api@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC v2] ptrace, pidfd: add pidfd_ptrace syscall
> On Apr 27, 2020, at 6:36 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> On Mon, Apr 27, 2020 at 5:46 PM Aleksa Sarai <cyphar@...har.com> 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.
Powered by blists - more mailing lists