From: ebiederm@xmission.com (Eric W. Biederman) To: <linux-arch@vger.kernel.org> Cc: Jens Axboe <axboe@kernel.dk>, Oleg Nesterov <oleg@redhat.com>, Al Viro <viro@ZenIV.linux.org.uk>, Linus Torvalds <torvalds@linux-foundation.org>, <linux-kernel@vger.kernel.org>, Richard Henderson <rth@twiddle.net>, Ivan Kokshaysky <ink@jurassic.park.msu.ru>, Matt Turner <mattst88@gmail.com>, linux-alpha@vger.kernel.org, Geert Uytterhoeven <geert@linux-m68k.org>, linux-m68k@lists.linux-m68k.org, Arnd Bergmann <arnd@kernel.org>, Ley Foon Tan <ley.foon.tan@intel.com>, Tejun Heo <tj@kernel.org>, Daniel Jacobowitz <drow@nevyn.them.org>, Kees Cook <keescook@chromium.org> Subject: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads Date: Thu, 10 Jun 2021 15:57:58 -0500 [thread overview] Message-ID: <87sg1p30a1.fsf@disp2133> (raw) Folks, Digging through the guts of exit I found something I am not quite certain what to do with. On some architectures such as alpha, m68k, and nios2 the kernel calls into system calls with a subset of the registers saved on the kernel stack, and the kernel calls into signal handling and a few other contexts with all of the registers saved on the kernel stack. The problem is sometimes we read all of the registers from a context where they are not all saved. When this was initially observed it looked just like a coredump problem and it could be solved by tweaking the coredump code. That change was 77f6ab8b7768 ("don't dump the threads that had been already exiting when zapped.") However I have looked farther and we have the location where get_signal is called from io_uring, and we have the ptrace_stop in PTRACE_EVENT_EXIT. In PTRACE_EVENT_EXIT we could be called from exit(2) which is a syscall and we definitely won't have everything saved on the kernel stack. I have not doubled checked create_io_thread but I don't think create_io_threads saves all of the registers on the kernel stack. I think at this point we need to say that the architectures that have a do this need to be fixed to at least call do_exit and the kernel function in create_io_thread with the deeper stack. Is that reasonable of me to ask? Is there some other way to deal with this issue that I am not seeing? Am I missing some critical detail that makes PTRACE_EVENT_EXIT in do_exit not a problem if someone reads the register with ptrace? Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman) To: linux-arch@vger.kernel.org Cc: Jens Axboe <axboe@kernel.dk>, Oleg Nesterov <oleg@redhat.com>, Al Viro <viro@ZenIV.linux.org.uk>, Linus Torvalds <torvalds@linux-foundation.org>, linux-kernel@vger.kernel.org, Richard Henderson <rth@twiddle.net>, Ivan Kokshaysky <ink@jurassic.park.msu.ru>, Matt Turner <mattst88@gmail.com>, linux-alpha@vger.kernel.org, Geert Uytterhoeven <geert@linux-m68k.org>, linux-m68k@lists.linux-m68k.org, Arnd Bergmann <arnd@kernel.org>, Ley Foon Tan <ley.foon.tan@intel.com>, Tejun Heo <tj@kernel.org>, Daniel Jacobowitz <drow@nevyn.them.org>, Kees Cook <keescook@chromium.org> Subject: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads Date: Thu, 10 Jun 2021 15:57:58 -0500 [thread overview] Message-ID: <87sg1p30a1.fsf@disp2133> (raw) Folks, Digging through the guts of exit I found something I am not quite certain what to do with. On some architectures such as alpha, m68k, and nios2 the kernel calls into system calls with a subset of the registers saved on the kernel stack, and the kernel calls into signal handling and a few other contexts with all of the registers saved on the kernel stack. The problem is sometimes we read all of the registers from a context where they are not all saved. When this was initially observed it looked just like a coredump problem and it could be solved by tweaking the coredump code. That change was 77f6ab8b7768 ("don't dump the threads that had been already exiting when zapped.") However I have looked farther and we have the location where get_signal is called from io_uring, and we have the ptrace_stop in PTRACE_EVENT_EXIT. In PTRACE_EVENT_EXIT we could be called from exit(2) which is a syscall and we definitely won't have everything saved on the kernel stack. I have not doubled checked create_io_thread but I don't think create_io_threads saves all of the registers on the kernel stack. I think at this point we need to say that the architectures that have a do this need to be fixed to at least call do_exit and the kernel function in create_io_thread with the deeper stack. Is that reasonable of me to ask? Is there some other way to deal with this issue that I am not seeing? Am I missing some critical detail that makes PTRACE_EVENT_EXIT in do_exit not a problem if someone reads the register with ptrace? Eric
next reply other threads:[~2021-06-10 20:58 UTC|newest] Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-10 20:57 Eric W. Biederman [this message] 2021-06-10 20:57 ` Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads Eric W. Biederman 2021-06-10 22:04 ` Linus Torvalds 2021-06-11 21:39 ` Eric W. Biederman 2021-06-11 23:26 ` Linus Torvalds 2021-06-13 21:54 ` Eric W. Biederman 2021-06-13 22:18 ` Linus Torvalds 2021-06-14 2:05 ` Michael Schmitz 2021-06-14 5:03 ` Michael Schmitz 2021-06-14 16:26 ` Eric W. Biederman 2021-06-14 22:26 ` Michael Schmitz 2021-06-15 19:30 ` Eric W. Biederman 2021-06-15 19:36 ` [PATCH] alpha: Add extra switch_stack frames in exit, exec, and kernel threads Eric W. Biederman 2021-06-15 22:02 ` Linus Torvalds 2021-06-16 16:32 ` Eric W. Biederman 2021-06-16 18:29 ` [PATCH 0/2] alpha/ptrace: Improved switch_stack handling Eric W. Biederman 2021-06-16 18:31 ` [PATCH 1/2] alpha/ptrace: Record and handle the absence of switch_stack Eric W. Biederman 2021-06-16 20:00 ` Linus Torvalds 2021-06-16 20:37 ` Linus Torvalds 2021-06-16 20:57 ` Eric W. Biederman 2021-06-16 21:02 ` Al Viro 2021-06-16 21:08 ` Linus Torvalds 2021-06-16 20:42 ` Eric W. Biederman 2021-06-16 20:17 ` Al Viro 2021-06-21 2:01 ` Michael Schmitz 2021-06-21 2:17 ` Linus Torvalds 2021-06-21 3:18 ` Michael Schmitz 2021-06-21 3:37 ` Linus Torvalds 2021-06-21 4:08 ` Michael Schmitz 2021-06-21 3:44 ` Al Viro 2021-06-21 5:31 ` Michael Schmitz 2021-06-21 2:27 ` Al Viro 2021-06-21 3:36 ` Michael Schmitz 2021-06-16 18:32 ` [PATCH 2/2] alpha/ptrace: Add missing switch_stack frames Eric W. Biederman 2021-06-16 20:25 ` Al Viro 2021-06-16 20:28 ` Al Viro 2021-06-16 20:49 ` Eric W. Biederman 2021-06-16 20:54 ` Al Viro 2021-06-16 20:47 ` Eric W. Biederman 2021-06-16 20:55 ` Al Viro 2021-06-16 20:50 ` [PATCH] alpha: Add extra switch_stack frames in exit, exec, and kernel threads Al Viro 2021-06-15 20:56 ` Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads Michael Schmitz 2021-06-16 0:23 ` Finn Thain 2021-06-15 21:58 ` Linus Torvalds 2021-06-16 15:06 ` Eric W. Biederman 2021-06-21 13:54 ` Al Viro 2021-06-21 14:16 ` Al Viro 2021-06-21 16:50 ` Eric W. Biederman 2021-06-21 23:05 ` Al Viro 2021-06-22 16:39 ` Eric W. Biederman 2021-06-21 15:38 ` Linus Torvalds 2021-06-21 18:59 ` Al Viro 2021-06-21 19:22 ` Linus Torvalds 2021-06-21 19:45 ` Al Viro 2021-06-21 23:14 ` Linus Torvalds 2021-06-21 23:23 ` Al Viro 2021-06-21 23:36 ` Linus Torvalds 2021-06-22 21:02 ` Eric W. Biederman 2021-06-22 21:48 ` Michael Schmitz 2021-06-23 5:26 ` Michael Schmitz 2021-06-23 14:36 ` Eric W. Biederman 2021-06-22 0:01 ` Michael Schmitz 2021-06-22 20:04 ` Michael Schmitz 2021-06-22 20:18 ` Al Viro 2021-06-22 21:57 ` Michael Schmitz 2021-06-21 20:03 ` Eric W. Biederman 2021-06-21 23:15 ` Linus Torvalds 2021-06-22 20:52 ` Eric W. Biederman 2021-06-23 0:41 ` Linus Torvalds 2021-06-23 14:33 ` Eric W. Biederman 2021-06-24 18:57 ` [PATCH 0/9] Refactoring exit Eric W. Biederman 2021-06-24 18:59 ` [PATCH 1/9] signal/sh: Use force_sig(SIGKILL) instead of do_group_exit(SIGKILL) Eric W. Biederman 2021-06-24 18:59 ` [PATCH 2/9] signal/seccomp: Refactor seccomp signal and coredump generation Eric W. Biederman 2021-06-26 3:17 ` Kees Cook 2021-06-28 19:21 ` Eric W. Biederman 2021-06-28 14:34 ` [signal/seccomp] 3fdd8c68c2: kernel-selftests.seccomp.seccomp_bpf.fail kernel test robot 2021-06-28 14:34 ` kernel test robot 2021-06-24 19:00 ` [PATCH 3/9] signal/seccomp: Dump core when there is only one live thread Eric W. Biederman 2021-06-26 3:20 ` Kees Cook 2021-06-24 19:01 ` [PATCH 4/9] signal: Factor start_group_exit out of complete_signal Eric W. Biederman 2021-06-24 20:04 ` Linus Torvalds 2021-06-25 8:47 ` kernel test robot 2021-06-25 8:47 ` kernel test robot 2021-06-26 3:24 ` Kees Cook 2021-06-24 19:01 ` [PATCH 5/9] signal/group_exit: Use start_group_exit in place of do_group_exit Eric W. Biederman 2021-06-26 3:35 ` Kees Cook 2021-06-24 19:02 ` [PATCH 6/9] signal: Fold do_group_exit into get_signal fixing io_uring threads Eric W. Biederman 2021-06-26 3:42 ` Kees Cook 2021-06-28 19:25 ` Eric W. Biederman 2021-06-24 19:02 ` [PATCH 7/9] signal: Make individual tasks exiting a first class concept Eric W. Biederman 2021-06-24 20:11 ` Linus Torvalds 2021-06-24 21:37 ` Eric W. Biederman 2021-06-24 19:03 ` [PATCH 8/9] signal/task_exit: Use start_task_exit in place of do_exit Eric W. Biederman 2021-06-26 5:56 ` Kees Cook 2021-06-24 19:03 ` [PATCH 9/9] signal: Move PTRACE_EVENT_EXIT into get_signal Eric W. Biederman 2021-06-24 22:45 ` [PATCH 0/9] Refactoring exit Al Viro 2021-06-27 22:13 ` Al Viro 2021-06-27 22:59 ` Michael Schmitz 2021-06-28 7:31 ` Geert Uytterhoeven 2021-06-28 16:20 ` Eric W. Biederman 2021-06-28 17:14 ` Michael Schmitz 2021-06-28 19:17 ` Geert Uytterhoeven 2021-06-28 20:13 ` Michael Schmitz 2021-06-28 21:18 ` Geert Uytterhoeven 2021-06-28 23:42 ` Michael Schmitz 2021-06-29 20:28 ` [CFT][PATCH] exit/bdflush: Remove the deprecated bdflush system call Eric W. Biederman 2021-06-29 20:28 ` Eric W. Biederman 2021-06-29 21:45 ` Michael Schmitz 2021-06-29 21:45 ` Michael Schmitz 2021-06-30 8:24 ` Geert Uytterhoeven 2021-06-30 8:37 ` Arnd Bergmann 2021-06-30 12:30 ` Cyril Hrubis 2021-06-28 19:02 ` [PATCH 0/9] Refactoring exit Eric W. Biederman 2021-06-21 19:24 ` Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads Al Viro 2021-06-21 23:24 ` Michael Schmitz 2021-06-16 7:38 ` Geert Uytterhoeven 2021-06-16 19:40 ` Michael Schmitz 2021-06-12 23:38 ` [PATCH v1] m68k: save extra registers on sys_exit and sys_exit_group syscall entry Michael Schmitz 2021-06-13 19:59 ` Linus Torvalds 2021-06-13 20:07 ` Michael Schmitz 2021-06-13 20:26 ` Linus Torvalds 2021-06-13 20:33 ` Linus Torvalds 2021-06-13 20:47 ` Linus Torvalds 2021-06-14 7:13 ` Michael Schmitz 2021-06-14 7:40 ` Andreas Schwab 2021-06-14 8:19 ` Michael Schmitz
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87sg1p30a1.fsf@disp2133 \ --to=ebiederm@xmission.com \ --cc=arnd@kernel.org \ --cc=axboe@kernel.dk \ --cc=drow@nevyn.them.org \ --cc=geert@linux-m68k.org \ --cc=ink@jurassic.park.msu.ru \ --cc=keescook@chromium.org \ --cc=ley.foon.tan@intel.com \ --cc=linux-alpha@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-m68k@lists.linux-m68k.org \ --cc=mattst88@gmail.com \ --cc=oleg@redhat.com \ --cc=rth@twiddle.net \ --cc=tj@kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=viro@ZenIV.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.