Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Al,

On 22/06/21 7:24 am, Al Viro wrote:

	There's a large mess around do_exit() - we have a bunch of
callers all over arch/*; if nothing else, I very much doubt that really
want to let tracer play with a thread in the middle of die_if_kernel()
or similar.

We sure as hell do not want to arrange for anything on the kernel
stack in such situations, no matter what's done in exit(2)...
FWIW, on alpha it's die_if_kernel(), do_entUna() and do_page_fault(),
all in not-from-userland cases.  On m68k - die_if_kernel(), do_page_fault()
(both for non-from-userland cases) and something really odd - fpsp040_die().
Exception handling for floating point stuff on 68040?  Looks like it has
Exception handling for emulated floating point instructions, really - exceptions happening when excecuting FPU instructions on hardware will do the normal exception processing.
an open-coded copy_to_user()/copy_from_user(), with faults doing hard
do_exit(SIGSEGV) instead of raising a signal and trying to do something
sane...

Yes, that's what it does. Not pretty ... though all that using m68k copy_to_user()/copy_from_user() would change is returning how many bytes could not copied. In contrast to the ifpsp060 code, we could not pass on that return status to callers of copyin/copyout in fpsp040, so I don't see what sane thing could be done if a fault happens.

(I'd expect the MMU would have raised a bus error and resolved the problem by a page fault if possible, before we ever get to this point?)

I really don't want to try and figure out how painful would it be to
teach that code how to deal with faults - _testing_ anything in that
area sure as hell will be.  IIRC, details of recovery from FPU exceptions
on 68040 in the manual left impression of a minefield...

This is only about faults when moving data from/to user space. FPU exceptions are handled elsewhere in the code. So we at least don't have to deal with that particular minefield.

Teaching the fpsp040 code to deal with access faults looks horrible indeed... let's not go there.

Cheers,

    Michael





[Index of Archives]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux