[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7277aa4b-5d3f-6bb3-379a-470df4addd15@gmail.com>
Date: Wed, 16 Jun 2021 08:56:35 +1200
From: Michael Schmitz <schmitzmic@...il.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-arch <linux-arch@...r.kernel.org>,
Jens Axboe <axboe@...nel.dk>, Oleg Nesterov <oleg@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Richard Henderson <rth@...ddle.net>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>,
alpha <linux-alpha@...r.kernel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
linux-m68k <linux-m68k@...ts.linux-m68k.org>,
Arnd Bergmann <arnd@...nel.org>,
Ley Foon Tan <ley.foon.tan@...el.com>,
Tejun Heo <tj@...nel.org>, Kees Cook <keescook@...omium.org>,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Subject: Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads
Hi Eric,
On 16/06/21 7:30 am, Eric W. Biederman wrote:
>
>>> The io_uring tasks are special in that they are user process
>>> threads that never run in userspace. So as long as everything
>>> ptrace can read is accessible on that process all is well.
>> OK, I'm testing a patch that would save extra context in sys_io_uring_setup,
>> which ought to ensure that for m68k.
> I had to update ret_from_kernel_thread to pop that state to get Linus's
> change to boot. Apparently kernel_threads exiting needs to be handled.
Hadn't yet got to that stage, sorry. Still stress testing stage 1 of my
fix (push complete context). I would have thought that this should be
sufficient (gives us a complete stack frame for ptrace code to work on)?
But it makes sense that when you push an extra stack frame, you'd need
to pop that on exit.
>
>>> Having stared a bit longer at the code I think the short term
>>> fix for both of PTRACE_EVENT_EXIT and io_uring is to guard
>>> them both with CONFIG_HAVE_ARCH_TRACEHOOK.
> Which does not work because nios2 which looks susceptible
> sets CONFIG_HAVE_ARCH_TRACEHOOK.
>
> A further look shows that there is also PTRACE_EVENT_EXEC that
> needs to be handled so execve and execveat need to be wrapped
> as well.
>
> Do you happen to know if there is userspace that will run
> in qemu-system-m68k that can be used for testing?
I surmise so. I don't use qemu myself - either ARAnyM, or actual
hardware. Hardware is limited to 14 MB RAM, which has prevented me from
using more than simple regression testing. In particular, I can't test
sys_io_uring_setup there.
Adrian uses qemu a lot, and has supplied disk images to work from on
occasion. Maybe he's got something recent enough to support
sys_io_uring_setup ... I've CC:ed him in, as I'd love to do some more
testing as well.
Cheers,
Michael
>
> Eric
>
Powered by blists - more mailing lists