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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B339C433EF for ; Tue, 5 Oct 2021 19:49:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 201A661371 for ; Tue, 5 Oct 2021 19:49:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235710AbhJETv1 (ORCPT ); Tue, 5 Oct 2021 15:51:27 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:55402 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230333AbhJETvY (ORCPT ); Tue, 5 Oct 2021 15:51:24 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]:54136) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mXqRI-00BOhD-Fk; Tue, 05 Oct 2021 13:49:24 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:41390 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 1mXqRH-008ayT-2v; Tue, 05 Oct 2021 13:49:24 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Alexander Popov Cc: Linus Torvalds , Petr Mladek , "Paul E. McKenney" , Jonathan Corbet , Andrew Morton , Thomas Gleixner , Peter Zijlstra , Joerg Roedel , Maciej Rozycki , Muchun Song , Viresh Kumar , Robin Murphy , Randy Dunlap , Lu Baolu , Kees Cook , Luis Chamberlain , Wei Liu , John Ogness , Andy Shevchenko , Alexey Kardashevskiy , Christophe Leroy , Jann Horn , Greg Kroah-Hartman , Mark Rutland , Andy Lutomirski , Dave Hansen , Steven Rostedt , Will Deacon , David S Miller , Borislav Petkov , Kernel Hardening , linux-hardening@vger.kernel.org, "open list\:DOCUMENTATION" , Linux Kernel Mailing List , notify@kernel.org References: <20210929185823.499268-1-alex.popov@linux.com> <20210929194924.GA880162@paulmck-ThinkPad-P17-Gen-1> <0e847d7f-7bf0-cdd4-ba6e-a742ce877a38@linux.com> Date: Tue, 05 Oct 2021 14:48:47 -0500 In-Reply-To: <0e847d7f-7bf0-cdd4-ba6e-a742ce877a38@linux.com> (Alexander Popov's message of "Sun, 3 Oct 2021 00:05:56 +0300") Message-ID: <87zgrnqmlc.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1mXqRH-008ayT-2v;;;mid=<87zgrnqmlc.fsf@disp2133>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19LbUxC2F3Wifzbmkmxv5sYTECcq8ioZjc= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] Introduce the pkill_on_warn boot parameter 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 Alexander Popov writes: > On 02.10.2021 19:52, Linus Torvalds wrote: >> On Sat, Oct 2, 2021 at 4:41 AM Alexander Popov wrote: >>> >>> And what do you think about the proposed pkill_on_warn? >> >> Honestly, I don't see the point. >> >> If you can reliably trigger the WARN_ON some way, you can probably >> cause more problems by fooling some other process to trigger it. >> >> And if it's unintentional, then what does the signal help? >> >> So rather than a "rationale" that makes little sense, I'd like to hear >> of an actual _use_ case. That's different. That's somebody actually >> _using_ that pkill to good effect for some particular load. > > I was thinking about a use case for you and got an insight. > > Bugs usually don't come alone. Killing the process that got WARN_ON() prevents > possible bad effects **after** the warning. For example, in my exploit for > CVE-2019-18683, the kernel warning happens **before** the memory corruption > (use-after-free in the V4L2 subsystem). > https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html > > So pkill_on_warn allows the kernel to stop the process when the first signs of > wrong behavior are detected. In other words, proceeding with the code execution > from the wrong state can bring more disasters later. > >> That said, I don't much care in the end. But it sounds like a >> pointless option to just introduce yet another behavior to something >> that should never happen anyway, and where the actual >> honest-to-goodness reason for WARN_ON() existing is already being >> fulfilled (ie syzbot has been very effective at flushing things like >> that out). > > Yes, we slowly get rid of kernel warnings. > However, the syzbot dashboard still shows a lot of them. > Even my small syzkaller setup finds plenty of new warnings. > I believe fixing all of them will take some time. > And during that time, pkill_on_warn may be a better reaction to WARN_ON() than > ignoring and proceeding with the execution. > > Is that reasonable? I won't comment on the sanity of the feature but I will say that calling it oops_on_warn (rather than pkill_on_warn), and using the usual oops facilities rather than rolling oops by hand sounds like a better implementation. Especially as calling do_group_exit(SIGKILL) from a random location is not a clean way to kill a process. Strictly speaking it is not even killing the process. Partly this is just me seeing the introduction of a do_group_exit(SIGKILL) call and not likely the maintenance that will be needed. I am still sorting out the problems with other randomly placed calls to do_group_exit(SIGKILL) and interactions with ptrace and PTRACE_EVENT_EXIT in particular. Which is a long winded way of saying if I can predictably trigger a warning that calls do_group_exit(SIGKILL), on some architectures I can use ptrace and can convert that warning into a way to manipulate the kernel stack to have the contents of my choice. If anyone goes forward with this please use the existing oops infrastructure so the ptrace interactions and anything else that comes up only needs to be fixed once. Eric