lkml.org 
[lkml]   [2021]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: 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

    \
     
     \ /
      Last update: 2021-06-15 21:32    [W:4.727 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site