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 93B32C4332F for ; Sat, 2 Oct 2021 16:33:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 78B4961B00 for ; Sat, 2 Oct 2021 16:33:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233631AbhJBQfL (ORCPT ); Sat, 2 Oct 2021 12:35:11 -0400 Received: from mail-wm1-f53.google.com ([209.85.128.53]:46892 "EHLO mail-wm1-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233444AbhJBQfK (ORCPT ); Sat, 2 Oct 2021 12:35:10 -0400 Received: by mail-wm1-f53.google.com with SMTP id o4-20020a05600c510400b0030d55d6449fso2348996wms.5; Sat, 02 Oct 2021 09:33:24 -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=XPPGkU56zJhC1We9hrBWJnpYMVu8F2L8QKrG+oAgNZA=; b=GiQyFy2Nwz42KBqTETpKBTHxTSNtgOnkLCANiRsyoQGMTJtY4L3O4vZyDoVmdIgDuS 4VNJQNI1H4RBL3WY1JyAgHh+GY50rH8+zoBCMbotHGpLHKuKs+rlN+zvFhh9vWRw1cRC eIBMcAkSaJJjEa5BhlgdxpITdWjhVDxqApes3EluqCcC/mCRn/e0LzaKXj3ZarhIAkyk aqgaUM7UbK4Kyz3zX/C6wHfjis70tnrNPp7Fv9bVUkOJLtDfaUEZ4g4hFPuku4leZEFK BP5K3LRz43whMy3UdnPaJx0DVCZGl6NYY4efGr4Xtdg5Eg9bL4XQzoES3qvcljtfbHE/ Pkwg== X-Gm-Message-State: AOAM532iRdTiZ7WBzs9hos4vSvZTMyBbF8Og81+4ILfTCjnIVDzhvYcp vJEFCfJuUjNTOU0RDKS9Sr0= X-Google-Smtp-Source: ABdhPJxnblRp0iST3pjMz+7tehqv68lMCKl8gTtuCPWUtdqmj3LGMvYGXoO4MgsXUEEqgbn3pAhWlA== X-Received: by 2002:a05:600c:1907:: with SMTP id j7mr10013673wmq.184.1633192403799; Sat, 02 Oct 2021 09:33:23 -0700 (PDT) Received: from [10.9.0.26] ([46.166.133.199]) by smtp.gmail.com with ESMTPSA id q126sm10973918wma.10.2021.10.02.09.33.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Oct 2021 09:33:23 -0700 (PDT) Reply-To: alex.popov@linux.com Subject: Re: [PATCH] Introduce the pkill_on_warn boot parameter To: Steven Rostedt 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 , 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> <20211002081359.5de4e2b1@oasis.local.home> From: Alexander Popov Message-ID: <62cd30d5-0982-5074-969b-a4ae1ee188c3@linux.com> Date: Sat, 2 Oct 2021 19:33:17 +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: <20211002081359.5de4e2b1@oasis.local.home> 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 02.10.2021 15:13, Steven Rostedt wrote: > On Sat, 2 Oct 2021 14:41:34 +0300 > 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 (for various reasons), so attackers use kernel warning >> infoleak in vulnerability exploits. See the examples: >> https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html >> https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html >> https://googleprojectzero.blogspot.com/2018/09/a-cache-invalidation-bug-in-linux.html >> >> Let's introduce the pkill_on_warn 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. > > How does this help? It only kills the process that caused the warning, > it doesn't kill the process that spawned it. This is trivial to get > around. Just fork a process, trigger the warning (it gets killed) and > then read the kernel log. > > If this is your rationale, then I'm not convinced this helps at all. Steven, as I understand, here you ask about the security implications of pkill_on_warn (not about the safety implications that I mentioned). Killing the exploit process that hit a warning is MUCH better than ignoring and proceeding with execution. That may influence the stability of the exploits that hit WARN_ON() or rely on WARN_ON() infoleak. Exploit development is the constant struggle for attack stability. Exploiting a heap memory corruption is especially painful when the kernel works with the attacked slab caches in parallel with your exploit. So when the kernel kills the exploit process, some of the WARN_ON() infoleak data becomes obsolete; the attacker loses the execution in that particular kernel task on that particular CPU. Moreover, restarting the exploit process would bring a lot of noise to the system. That may decrease the attack stability even more. So killing the exploit process is the best option that we have here to distress the attacker who uses the WARN_ON() infoleak technique. I.e. that is probabilistic attack mitigation, which is reasonable for kernel safety as well. I hope I managed to show this from the attacker's side. Best regards, Alexander