Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp681298pxb; Thu, 30 Sep 2021 14:56:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyfJqDLdV4woY9KeQyNwYO+EbsZ5L02eShRhl3bx3Kd6p+fH1vV2NQAbO0NxTMAqlP9FJZw X-Received: by 2002:a62:6d07:0:b0:446:c141:7d2d with SMTP id i7-20020a626d07000000b00446c1417d2dmr6455719pfc.28.1633038975046; Thu, 30 Sep 2021 14:56:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633038975; cv=none; d=google.com; s=arc-20160816; b=kDPGN4lCeawz/aIjX2e9ftYKIwB1Yf4g48fqmGy83S2ZfLT6VtIsa78Kw7eLsQW+f8 M8EzTc1sby68ziZpPEyOoJ1d/NqaHq5iYzWq4X3h40VRr3w8lYxgWmS95SS5+p67zub3 6IvLz0usRyxpBklwD7Zz42vX0keiTXDg5rTpL7iDG66NVf6ryoCBpjBUKeUUnGgyjuYu u+rlrYNDiptuSlxCnnQI3zdATAiU/QudUdPKjQbaV/1d+4msBYU+pSK535zT77bpc1IT ZzkdPbURRQUL+oV3rq5AK6ZIToe6C5Yl9Jj/VuJst2T0/vuM6KyWLAUwPgA0m0XVBWKv GG8Q== 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=kXiXFZ9ry/i2aqEPHzEKtrxgwY/jrLKAjIEmqjjgomU=; b=UjCO5Si18HubMYv4LfuuL5pgC97Gjp9feagDeCVAkpQC1INO9mohYTFss/lzSPabOY N43Ev9p+IFpGKpUS80/heZgldKV9Yiqvph+bTk3EJKV/ShtL3M7+TRXZhqewe5TKcHVC jw0iwPGSXGMqA47oP6J4cvCdvRCLw0m4vUiKU/OIdxKY9nBo9zbWQQjFtopnKtKTuY75 oq7X/N5Wi21Kd3qbI1pWQDfVJPWiWkAbFQp6lcO3qiDJnAf7XhUWL3Pq3G2YtMy6jA/H 6A4je+IxiCtQkP3tgP6Ackq7IJ5JCwkVN5c8vyGeqFVuD3NT5vA5rnCAZ47f+Z1c0/Op ZTMw== 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 n4si4927254pfj.4.2021.09.30.14.56.01; Thu, 30 Sep 2021 14:56:15 -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 S229529AbhI3S3k (ORCPT + 99 others); Thu, 30 Sep 2021 14:29:40 -0400 Received: from mail-ed1-f44.google.com ([209.85.208.44]:42614 "EHLO mail-ed1-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229490AbhI3S3h (ORCPT ); Thu, 30 Sep 2021 14:29:37 -0400 Received: by mail-ed1-f44.google.com with SMTP id bd28so25526714edb.9; Thu, 30 Sep 2021 11:27:52 -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=kXiXFZ9ry/i2aqEPHzEKtrxgwY/jrLKAjIEmqjjgomU=; b=7z5F9cV97IUm38G4CvY9RdKvKN21qOnviYplEnZvjn4CkAxDYV6MPmvYnq+dw/UB2m L9+sLy0h1jIaHb8P9C5fnm5uDgppIewwZOmH2g8AZLMEGZl6VL7S9Nkz0CiGwgngEw0A djOBSWbWR33wLQ9Hj/kzOHjZi06GDD1ng4MdP0EeTWKDTjsD6KrHA/9shkkvA6xoyNoF Bh9QlmRQwZetdJocZaunWWyY2NkGWAeQQFFcxV3m/Xgp9z0+bIoz1I2ClaboP+LDWweB EJo6RIivo8OWLRNsNYs35hpVe14QxyqIIqGoZ3djyCcS3uD10Ehelsgd90Ig2xpU2TFG LbjQ== X-Gm-Message-State: AOAM533Uz0KUuNNFDjoI3SJdTzxUU5znaNoYIrD93wqP0O62tWXqLpqi rqA93joqkArUoGAHxwYRTCg= X-Received: by 2002:a17:906:c4a:: with SMTP id t10mr771534ejf.371.1633026470564; Thu, 30 Sep 2021 11:27:50 -0700 (PDT) Received: from [10.9.0.26] ([46.166.133.199]) by smtp.gmail.com with ESMTPSA id ca4sm1838189ejb.1.2021.09.30.11.27.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Sep 2021 11:27:50 -0700 (PDT) Reply-To: alex.popov@linux.com Subject: Re: [PATCH] Introduce the pkill_on_warn boot parameter To: Andrew Morton Cc: Jonathan Corbet , Paul McKenney , Thomas Gleixner , Peter Zijlstra , Joerg Roedel , Maciej Rozycki , Muchun Song , Viresh Kumar , Robin Murphy , Randy Dunlap , Lu Baolu , Petr Mladek , 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@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> <20210929163143.aa8b70ac9d5cf0b628823370@linux-foundation.org> From: Alexander Popov Message-ID: Date: Thu, 30 Sep 2021 21:27:43 +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: <20210929163143.aa8b70ac9d5cf0b628823370@linux-foundation.org> 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 30.09.2021 02:31, Andrew Morton wrote: > On Wed, 29 Sep 2021 22:01:33 +0300 Alexander Popov wrote: > >> On 29.09.2021 21:58, Alexander Popov wrote: >>> Currently, the Linux kernel provides two types of reaction to kernel >>> warnings: >>> 1. Do nothing (by default), >>> 2. Call panic() if panic_on_warn is set. That's a very strong reaction, >>> so panic_on_warn is usually disabled on production systems. >>> >>> From a safety point of view, the Linux kernel misses a middle way of >>> handling kernel warnings: >>> - The kernel should stop the activity that provokes a warning, >>> - But the kernel should avoid complete denial of service. >>> >>> From a security point of view, kernel warning messages provide a lot of >>> useful information for attackers. Many GNU/Linux distributions allow >>> unprivileged users to read the kernel log, so attackers use kernel >>> warning infoleak in vulnerability exploits. See the examples: >>> https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html >>> https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html >>> >>> Let's introduce the pkill_on_warn boot parameter. >>> If this parameter is set, the kernel kills all threads in a process >>> that provoked a kernel warning. This behavior is reasonable from a safety >>> point of view described above. It is also useful for kernel security >>> hardening because the system kills an exploit process that hits a >>> kernel warning. >>> >>> Signed-off-by: Alexander Popov >> >> This patch was tested using CONFIG_LKDTM. >> The kernel kills a process that performs this: >> echo WARNING > /sys/kernel/debug/provoke-crash/DIRECT >> >> If you are fine with this approach, I will prepare a patch adding the >> pkill_on_warn sysctl. > > Why do we need a boot parameter? Isn't a sysctl all we need for this > feature? I would say we need both sysctl and boot parameter for pkill_on_warn. That would be consistent with panic_on_warn, ftrace_dump_on_oops and oops/panic_on_oops. > Also, > > if (pkill_on_warn && system_state >= SYSTEM_RUNNING) > do_group_exit(SIGKILL); > > - why do we care about system_state? An explanatory code comment > seems appropriate. > > - do we really want to do this in states > SYSTEM_RUNNING? If so, why? A kernel warning may occur at any moment. I don't have a deep understanding of possible side effects on early boot stages. So I decided that at least it's safer to avoid interfering before SYSTEM_RUNNING. Best regards, Alexander