Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp549562pxb; Thu, 30 Sep 2021 11:35:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpIbASLOfTa+wzdy36YN32xpnou1tEQ99/peEltbrt3eqyzqB7cUKah74w0+1fUlrmQzNu X-Received: by 2002:a05:6a00:14d2:b0:44c:b33:984b with SMTP id w18-20020a056a0014d200b0044c0b33984bmr1424795pfu.23.1633026914255; Thu, 30 Sep 2021 11:35:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633026914; cv=none; d=google.com; s=arc-20160816; b=khDGBwwmlAHuW7fGAJKkajoBit1rQjYphKiui9t3agajSEEj6AnGcGPAw0QFyPbqu4 mlFjnJvCxoy+KJlwWE3DZ3mSeb1Q2q4pfAtSInLjGbDOQbIw+5glAiq/syR2DVF5jNbE dcihhHCEeJjY9HKgFbh7J44Wv4i+/1p9sEHzRjo1uBikE2UuDaFSDy6hC7sZ0otwIBAq ghJKyENUHlXqyAOtjnrdnL/mRzObYOtx2OTjJTdmg04cmcb8gex/b2tWLGV9MS9wlMdU wUiaN2IvdUkoY7wYrlBkE/2+7p5fInrnQuG2N+g6TrpVPrVZxwQLkU+1L/6WZQLtThVh voXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:reply-to; bh=XIBvChFKd70IQU/OaMjJCINVW+wyQl1HNkbZBhbOPoI=; b=AHJsJEsqhkM2LAK35IdrADItE4YwoeochlZMaN4HpYH2pyjK/QIw5x3eN+Q1UxNx01 pPk3w4u5HzxzjR4uvTMobYBVmVjG6IM2CGK4D9ZeRdhGp7xze8Dc2Xh5hgBMka1qwqRs Q3arz2/1CTzIMQP0J7Xj6u05IuXllMiwFAMbLnmQ9y5a1i0e6uSyDWuAfoxMNq8eMEJ5 p8Vxl1JaEzYlJ63aRu0dXrCJsUyyH9OOVpVy7VuH3y2xDP/W0uyJJvmdsVNdQedQGLpy PWpQ7yZ0VBM1dRNP0UZS+/hmqeDK+P1eEK9gzu+6os+bQzjr4fY6RwOeERkruh/B6bdX FXjQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x184si4127903pfd.79.2021.09.30.11.35.00; Thu, 30 Sep 2021 11:35:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351552AbhI3N5b (ORCPT + 99 others); Thu, 30 Sep 2021 09:57:31 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:38496 "EHLO mail-wr1-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351510AbhI3N50 (ORCPT ); Thu, 30 Sep 2021 09:57:26 -0400 Received: by mail-wr1-f54.google.com with SMTP id u18so10233884wrg.5; Thu, 30 Sep 2021 06:55:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=XIBvChFKd70IQU/OaMjJCINVW+wyQl1HNkbZBhbOPoI=; b=8CfbARVXFzf7MFBoctitWkTl1kPbsxP1NaDzyzQr5w/U/szRkMB+SjHzCmbA88cYJ4 xVMkeqnD5WO6QxYteYELVw2N1cDACd41B10puoNWA6xSmJmEBSJFCPj+6bfJGYgznwAU e+tOrNlcFMp06UUyfXEe33QdPp2uR973I/HrqxQMGcjj0eSFvF8/obmvdhSRw8btTfo/ 3bEBxxy0fEht85a6jf4Qw7QTSYO+81fTgJ237g7UTd9Gy6qbNsKEx5ghwmXJhmVuDJtk +jb11NmXy7rZuhn/JfEYNuoKRejfmeB36ULLi9R7crt4a9GB3/ctb9YV37IIJfTZeO8K hkrg== X-Gm-Message-State: AOAM533OR057nFfXUzhOu4BvayMpnIa2KpEFNDSrptaqB/ebL8o/1njj 8GMrrMqZIUnBYx9NuGBeM80= X-Received: by 2002:a5d:64a3:: with SMTP id m3mr6461208wrp.157.1633010142527; Thu, 30 Sep 2021 06:55:42 -0700 (PDT) Received: from [10.9.0.26] ([46.166.133.199]) by smtp.gmail.com with ESMTPSA id i92sm3028618wri.28.2021.09.30.06.55.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Sep 2021 06:55:42 -0700 (PDT) Reply-To: alex.popov@linux.com Subject: Re: [PATCH] Introduce the pkill_on_warn boot parameter To: Kees Cook , Dave Hansen , Peter Zijlstra Cc: Jonathan Corbet , Paul McKenney , Andrew Morton , Thomas Gleixner , Joerg Roedel , Maciej Rozycki , Muchun Song , Viresh Kumar , Robin Murphy , Randy Dunlap , Lu Baolu , Petr Mladek , 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@lists.openwall.com, linux-hardening@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, notify@kernel.org References: <20210929185823.499268-1-alex.popov@linux.com> <323d0784-249d-7fef-6c60-e8426d35b083@intel.com> <202109291229.C64A1D9D@keescook> From: Alexander Popov Message-ID: Date: Thu, 30 Sep 2021 16:55:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <202109291229.C64A1D9D@keescook> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29.09.2021 23:06, Kees Cook wrote: > On Wed, Sep 29, 2021 at 12:03:36PM -0700, Dave Hansen wrote: >> On 9/29/21 11:58 AM, Alexander Popov wrote: >>> --- a/kernel/panic.c >>> +++ b/kernel/panic.c >>> @@ -53,6 +53,7 @@ static int pause_on_oops_flag; >>> static DEFINE_SPINLOCK(pause_on_oops_lock); >>> bool crash_kexec_post_notifiers; >>> int panic_on_warn __read_mostly; >>> +int pkill_on_warn __read_mostly; > > I like this idea. I can't tell if Linus would tolerate it, though. But I > really have wanted a middle ground like BUG(). Having only WARN() and > panic() is not very friendly. :( Ok, let's see. Kees, could you also share your thoughts on the good questions by Petr Mladek in this thread? >>> unsigned long panic_on_taint; >>> bool panic_on_taint_nousertaint = false; >>> >>> @@ -610,6 +611,9 @@ void __warn(const char *file, int line, void *caller, unsigned taint, >>> >>> print_oops_end_marker(); >>> >>> + if (pkill_on_warn && system_state >= SYSTEM_RUNNING) >>> + do_group_exit(SIGKILL); >>> + >>> /* Just a warning, don't kill lockdep. */ >>> add_taint(taint, LOCKDEP_STILL_OK); >>> } >> >> Doesn't this tie into the warning *printing* code? That's better than >> nothing, for sure. But, if we're doing this for hardening, I think we >> would want to kill anyone provoking a warning, not just the first one >> that triggered *printing* the warning. > > Right, this needs to be moved into the callers of __warn() (i.e. > report_bug(), and warn_slowpath_fmt()), likely with some small > refactoring in report_bug(). Yes, I see now. Thanks, Dave, Peter and Kees. The kernel can hit warning and omit calling __warn() that prints the message. But pkill_on_warn action should be taken each time. As I can understand now, include/asm-generic/bug.h defines three warning implementations: 1. CONFIG_BUG=y and the arch provides __WARN_FLAGS. In that case pkill_on_warn should be checked in report_bug() that you mention. 2. CONFIG_BUG=y and the arch doesn't have __WARN_FLAGS. In that case pkill_on_warn should be checked in warn_slowpath_fmt(). 3. CONFIG_BUG is not set. In that case pkill_on_warn should not be considered. Please, correct me if needed. Best regards, Alexander