From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads Date: Wed, 23 Jun 2021 09:33:50 -0500 Message-ID: <87zgvgabw1.fsf@disp2133> References: <87sg1lwhvm.fsf@disp2133> <6e47eff8-d0a4-8390-1222-e975bfbf3a65@gmail.com> <924ec53c-2fd9-2e1c-bbb1-3fda49809be4@gmail.com> <87eed4v2dc.fsf@disp2133> <5929e116-fa61-b211-342a-c706dcb834ca@gmail.com> <87fsxjorgs.fsf@disp2133> <87a6njf0ia.fsf@disp2133> <87tulpbp19.fsf@disp2133> Mime-Version: 1.0 Return-path: In-Reply-To: (Linus Torvalds's message of "Tue, 22 Jun 2021 17:41:51 -0700") List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Linus Torvalds Cc: Al Viro , Michael Schmitz , linux-arch , Jens Axboe , Oleg Nesterov , Linux Kernel Mailing List , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , Geert Uytterhoeven , linux-m68k , Arnd Bergmann , Ley Foon Tan , Tejun Heo , Kees Cook Linus Torvalds writes: > On Tue, Jun 22, 2021 at 1:53 PM Eric W. Biederman wrote: >> >> Playing with it some more I think I have everything working working >> except for PTRACE_EVENT_SECCOMP (which can stay ptrace_event) and >> group_exit(2). >> >> Basically in exit sending yourself a signal and then calling do_exit >> from the signal handler is not unreasonable, as exit is an ordinary >> system call. > > Ok, this is a bit odd, but I do like the concept of just making > ptrace_event just post a signal, and have all ptrace things always be > handled at signal time (or the special system call entry/exit, which > is fine too). > >> For purposes of discussion this is my current draft implementation. > > I didn't check what is so different about exit_group() that you left > that as an exercise for the reader, but if that ends up then removing > the whole "wait synchromously for ptrace" cases for good I don't > _hate_ this. It's a bit odd, but it would be really nice to limit > where ptrace picks up data. I am still figuring out exit_group. I am hoping for sometime today. My intuition tells me I can do it, and I have a sense of what threads I need to pull to get there. I just don't know what the code is going to look like yet. Basically solving exit_group means moving ptrace_event out of do_exit. > We do end up doing that stuff in "get_signal()", and that means that > we have the interaction with io_uring calling it directly, but it's at > least not a new thing. The ugliest bit is having to repeat the wait_for_vfork_done both in fork and in get_signal. Eric