From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Schmitz Subject: Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads Date: Wed, 23 Jun 2021 09:48:40 +1200 Message-ID: <20c787ec-4a3c-061c-c649-5bc3e7ef0464@gmail.com> References: <924ec53c-2fd9-2e1c-bbb1-3fda49809be4@gmail.com> <87eed4v2dc.fsf@disp2133> <5929e116-fa61-b211-342a-c706dcb834ca@gmail.com> <87fsxjorgs.fsf@disp2133> <87h7hpbojt.fsf@disp2133> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/a89jzJmhEpzXyHwVhCcKZ9uKv9DiUWiMoXSo4IAqPE=; b=Fj7WoX0NrdmFtDXSPbtKbFgnFmECG0CoEZ4apdWVK9HbJGRvJ+ZBhc5XMlidFXofUP RWjfmZvk+mM6RhZumcg0dSaV1oUyKYulB5H/nEg0lJ3cvPqePy77b0IcPVxSDSISJnIJ dcpLcgeGt3kO1NwuKcgE8BzaK4Y1D7n4IalQxNKpU5rzjl/3eO9988IoJHBxOWH99sio dlNfD9HjdJ+dm7+L/b4tD3GXwtXFTQ3R6hStNTzps39P1kALUFKhlDTgPPlxApk+m7OQ VpgUUKRGveGFPy/XEon+N+/Hos5/Mvs0VE2YkMq1h73qmm76/kJqcqRlEt8oA52XTgfJ 01bA== In-Reply-To: <87h7hpbojt.fsf@disp2133> Content-Language: en-US List-ID: Content-Type: text/plain; charset="utf-8"; format="flowed" To: "Eric W. Biederman" , Linus Torvalds Cc: Al Viro , linux-arch , Jens Axboe , Oleg Nesterov , Linux Kernel Mailing List , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , Geert Uytterhoeven , linux-m68k , Arnd Bergmann , Tejun Heo , Kees Cook , Tetsuo Handa , John Paul Adrian Glaubitz Hi Eric, On 23/06/21 9:02 am, Eric W. Biederman wrote: > Linus Torvalds writes: > > 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. Seccomp hasn't yet been implemented on m68k, though I'm working on that with Adrian. The sole secure_computing() call will happen in syscall_trace_enter(), so all system call arguments have been saved on the stack. Haven't looked at /proc/pid/syscall yet ... Cheers,     Michael > Eric >