Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads

[Michael Schmitz]

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