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=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 63404C48BC2 for ; Mon, 21 Jun 2021 23:25:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 419CD60FE7 for ; Mon, 21 Jun 2021 23:25:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231788AbhFUX1Y (ORCPT ); Mon, 21 Jun 2021 19:27:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230130AbhFUX1X (ORCPT ); Mon, 21 Jun 2021 19:27:23 -0400 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9257C06175F for ; Mon, 21 Jun 2021 16:25:07 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id z3-20020a17090a3983b029016bc232e40bso993667pjb.4 for ; Mon, 21 Jun 2021 16:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=r0VwenRqskFTDoxa2BG069i4DjqqTYGW10YD8Bvo/q0=; b=F+xHU0Aq6hmH1YvvN8TsIaDZ+1YxE0TAC/D7AUDfDVD99ivp1J2/ZEe+x6H78uyvXj E3ihUPFI1h6CinFlQiMGG9N/FK57sYaQBEHYKmbxomJfPEevCH3VNE9VvZYCh2EFsghE f/HFVrKLPWMR/AoMFOGbraO2smRAYLfRB9g2p0gs6svzmnCwmD2LKKhlymdV7bvrAyiF bZ5H+34iH1uRaGrMDypbUXzPC99bK1vJS/SsOQ1yuMsrhStJouJdPbuOTjsC4KacgFq7 zNn+nXPzUDdD/SjHRFw34nmjK53kw1U/2GRYEOaSyDHA8Wp7EQ+lOYrEvt5YlvltZ1kq 7nPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=r0VwenRqskFTDoxa2BG069i4DjqqTYGW10YD8Bvo/q0=; b=EZo6RuJL0XGm7M1eLHl+Sy0PMVXrZl/f82dR3P3XrXaZPtQxthZC2UybZIVrqvufPX nhXEPsFJtBgY9ecHZZFJ7O62faqO2Xrdu2MmGfq6iaabgIoNHKReELM0F4zFsb39+jWN vjIqtkDXltMEk991Eq89bQI46uUUq9j7jyAFQP8pB5JLbGK0OICYGwP71dPFqTo3n/Q2 +kmTyXrvWSjMW4kNdFpsqrsvW4EGsgZGw7MCo3FuWfcH9BLjX1nBBIuZxFcX4U5jcoUI Sl2Nlv6jgr5ZLXWdjnAnWMbsG6wkvTd4ylrxw7eSGIdKnlLvk0lOPE2Ad0LDnDgu2nbC KkpA== X-Gm-Message-State: AOAM530v5IRbdWmxT/oZKCF6SMuLidl3GGiDvjz8SRmm8iY5Lnna/lA+ yJllfienUGe2DYEoBjn0w/0= X-Google-Smtp-Source: ABdhPJxZXn+aC1eJ8kEUSL89QiRwAcF2SYH1ok/wnVJVoR/0d2Q7ch0UBMjyXnIPBipspF93KtOPVg== X-Received: by 2002:a17:90a:1541:: with SMTP id y1mr701499pja.74.1624317907229; Mon, 21 Jun 2021 16:25:07 -0700 (PDT) Received: from ?IPv6:2001:df0:0:200c:2114:f868:6a99:ac19? ([2001:df0:0:200c:2114:f868:6a99:ac19]) by smtp.gmail.com with ESMTPSA id m4sm252608pjv.41.2021.06.21.16.25.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Jun 2021 16:25:06 -0700 (PDT) Subject: Re: Kernel stack read with PTRACE_EVENT_EXIT and io_uring threads To: Al Viro , Linus Torvalds Cc: "Eric W. Biederman" , linux-arch , Jens Axboe , Oleg Nesterov , Linux Kernel Mailing List , Richard Henderson , Ivan Kokshaysky , Matt Turner , alpha , Geert Uytterhoeven , linux-m68k , Arnd Bergmann , Ley Foon Tan , Tejun Heo , Kees Cook References: <87sg1lwhvm.fsf@disp2133> <6e47eff8-d0a4-8390-1222-e975bfbf3a65@gmail.com> <924ec53c-2fd9-2e1c-bbb1-3fda49809be4@gmail.com> <87eed4v2dc.fsf@disp2133> <5929e116-fa61-b211-342a-c706dcb834ca@gmail.com> <87fsxjorgs.fsf@disp2133> From: Michael Schmitz Message-ID: Date: Tue, 22 Jun 2021 11:24:57 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-m68k@vger.kernel.org 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