Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads

Michael Schmitz
2021-06-15T20:56:47Z

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
>