From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74924C48BE5 for ; Fri, 11 Jun 2021 21:40:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5A4A6613CC for ; Fri, 11 Jun 2021 21:40:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230507AbhFKVmD (ORCPT ); Fri, 11 Jun 2021 17:42:03 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:41284 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230385AbhFKVmB (ORCPT ); Fri, 11 Jun 2021 17:42:01 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lrosf-008XOJ-U8; Fri, 11 Jun 2021 15:39:58 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=email.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lrose-004obf-NP; Fri, 11 Jun 2021 15:39:57 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: linux-arch , Jens Axboe , Oleg Nesterov , Al Viro , Linux Kernel Mailing List , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , Geert Uytterhoeven , linux-m68k , Arnd Bergmann , Ley Foon Tan , Tejun Heo , Daniel Jacobowitz , Kees Cook In-Reply-To: (Linus Torvalds's message of "Thu, 10 Jun 2021 15:04:33 -0700") References: <87sg1p30a1.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Date: Fri, 11 Jun 2021 16:39:44 -0500 Message-ID: <87pmwsytb3.fsf@disp2133> MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1lrose-004obf-NP;;;mid=<87pmwsytb3.fsf@disp2133>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+IuZawwTz1YFyhvc3cnGga/n99E1fmVx0= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds writes: > On Thu, Jun 10, 2021 at 1:58 PM Eric W. Biederman wrote: >> >> The problem is sometimes we read all of the registers from >> a context where they are not all saved. > > Ouch. Yes. And this is really painful because none of the *normal* > architectures do this, so it gets absolutely no coverage. > >> 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. > > Yeah. We traditionally have that requirement for fork() and friends > too (vfork/clone), so adding exit and io_uring to do so seems like the > most straightforward thing. Interesting. I am starting with Al's analysis and reading the code to see if I can understand what is going on. So I am still glossing over a few details as I dig into this. Kernel threads not having all of their registers saved is one of those details. Looking at copy_thread it looks like at least on alpha we are dealing with a structure that defines all of the registers in copy_thread. So perhaps all of the registers are there in kernel_threads already. I don't read alpha assembly very well and fork is a bit subtle. I don't know which piece of code is calling ret_from_fork/ret_from_kernel_thread. I really suspect that all of those registers are popped so at least for IO_THREADS we need to push them again, in a way that signal_pt_regs() can find them. It looks like we just need something like this to cover the userspace side of exit. diff --git a/arch/alpha/kernel/entry.S b/arch/alpha/kernel/entry.S index e227f3a29a43..ab0dcb545bd1 100644 --- a/arch/alpha/kernel/entry.S +++ b/arch/alpha/kernel/entry.S @@ -812,6 +812,22 @@ fork_like fork fork_like vfork fork_like clone +.macro exit_like name + .align 4 + .globl alpha_\name + .ent alpha_\name +alpha_\name: + .prologue 0 + DO_SWITCH_STACK + jsr $26, sys_\name + UNDO_SWITCH_STACK + ret +.end alpha_\name +.endm + +exit_like exit +exit_like exit_group + .macro sigreturn_like name .align 4 .globl sys_\name diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl index 3000a2e8ee21..b9d6449d6caa 100644 --- a/arch/alpha/kernel/syscalls/syscall.tbl +++ b/arch/alpha/kernel/syscalls/syscall.tbl @@ -8,7 +8,7 @@ # The is always "common" for this file # 0 common osf_syscall alpha_syscall_zero -1 common exit sys_exit +1 common exit alpha_exit 2 common fork alpha_fork 3 common read sys_read 4 common write sys_write @@ -333,7 +333,7 @@ 400 common io_getevents sys_io_getevents 401 common io_submit sys_io_submit 402 common io_cancel sys_io_cancel -405 common exit_group sys_exit_group +405 common exit_group alpha_exit_group 406 common lookup_dcookie sys_lookup_dcookie 407 common epoll_create sys_epoll_create 408 common epoll_ctl sys_epoll_ctl > But I really wish we had some way to test and trigger this so that we > wouldn't get caught on this before. Something in task_pt_regs() that > catches "this doesn't actually work" and does a WARN_ON_ONCE() on the > affected architectures? I think that would require pushing an extra magic value in SWITCH_STACK and not just popping it but deliberately changing that value in UNDO_SWITCH_STACK. Basically stack canaries. I don't see how we could do it in an arch independent way though. Which means it will require auditing all of the architectures to get there. Volunteers? This is looking straight forward enough that I can probably pull something together, just don't count on me to have it done in anything resembling a timely manner. Eric