Messages in this thread | | | From | (Eric W. Biederman) | Date | Tue, 15 Jun 2021 14:30:59 -0500 | Subject | Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads |
| |
Michael Schmitz <schmitzmic@gmail.com> writes:
> Hi Eric, > > On 15/06/21 4:26 am, Eric W. Biederman wrote: >> Michael Schmitz <schmitzmic@gmail.com> writes: >> >>> On second thought, I'm not certain what adding another empty stack frame would >>> achieve here. >>> >>> On m68k, 'frame' already is a new stack frame, for running the new thread >>> in. This new frame does not have any user context at all, and it's explicitly >>> wiped anyway. >>> >>> Unless we save all user context on the stack, then push that context to a new >>> save frame, and somehow point get_signal to look there for IO threads >>> (essentially what Eric suggested), I don't see how this could work? >>> >>> I must be missing something. >> It is only designed to work well enough so that ptrace will access >> something well defined when ptrace accesses io_uring tasks. >> >> 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.
>> 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?
Eric
| |