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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BCA4DC04A68 for ; Wed, 27 Jul 2022 16:46:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240377AbiG0Qq5 (ORCPT ); Wed, 27 Jul 2022 12:46:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240427AbiG0QqR (ORCPT ); Wed, 27 Jul 2022 12:46:17 -0400 Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3CE75FAFF for ; Wed, 27 Jul 2022 09:31:36 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id 125so13932667iou.6 for ; Wed, 27 Jul 2022 09:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HLpauEQ5M+lWRIlS3PcwqsZWVTFiAvj2+32FpHGOhBk=; b=klS/6ZXoSeM0uv5HT7/w1pRROtMu2SFyiAGZpuVTlKfCMmZO+NVgryshOQKXZ3mRwO aCapBXgciK6e8ZLoA0VmgIdcFIShZvj3yTsNZAVCWrgAfnyA1QH0nmrIVsxq906pdmc0 hmwXJXpwp0IwAbDiWt5D++aDEST91D1pWaKsHwWFDLX494ZYqaluBT3sHd8k0UTlRBI2 jEfCfG3Cu4m+fuqo+JGBOr/N1asAZoHTfyfmGqch2N4qoAxdB4As1OnAQTKzEjYhm7vg 3XTBjSn/35ULRdJL1A6mahAfA9wsliZ8gk/LfZ5hmyy9h93oqA8sg161qx782ugJASrw dWtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HLpauEQ5M+lWRIlS3PcwqsZWVTFiAvj2+32FpHGOhBk=; b=BoDQEZfR4q3ktiR90+sEKbW5OAwaoN8ccUHOGafuYy0fmj8/bQ2NeI5Hl5oJEek6u+ zqutGClFzrJBhjCShlTUjqRiUGo9k2F1T+ql+aM1nyp/BcJb4OvHvVwvxhMlq1xlwmpk qfCuTFqRsNPx2lHIDhFCIek+fmkDbXjqTtv7/Up7+HZMVAucm9j5hTLjHrQYiAcj3ii9 jNxh0euyzBoo9+wpDxixgj+AUW7aunADIHzH+UuJCcOtrLOm+0tGhIhWDFaMQO23lRfL 5YbfoeR/l575FbCbIOXNUEKJNQPKEcm0642F+Fdr6DSgLOb30a3Yt8FkgGV9zZKw5NyD 6J+A== X-Gm-Message-State: AJIora/aFWxHJgoXYae7Qk328ic3oP/izTdR9+ecJfPJgocFfcFzoCRO C76yha2503LUjnGP5W88MpkW7dpF0zs0ujxpm1Nn9Q== X-Google-Smtp-Source: AGRyM1vzxJdX05n48cDiHKWT4UyZZ4xthB7HHUEb5MIzbitr5xn078iGRk5ZiOqwPRiIpO312Lx7K0+ksI9j1fyn3gg= X-Received: by 2002:a02:a68c:0:b0:33f:46d4:918e with SMTP id j12-20020a02a68c000000b0033f46d4918emr8580458jam.58.1658939495323; Wed, 27 Jul 2022 09:31:35 -0700 (PDT) MIME-Version: 1.0 References: <20210929185823.499268-1-alex.popov@linux.com> <20210929194924.GA880162@paulmck-ThinkPad-P17-Gen-1> <7c567acd-1cc1-a480-ca5a-d50a9c5a69ef@ispras.ru> In-Reply-To: <7c567acd-1cc1-a480-ca5a-d50a9c5a69ef@ispras.ru> From: Jann Horn Date: Wed, 27 Jul 2022 18:30:59 +0200 Message-ID: Subject: Re: [PATCH] Introduce the pkill_on_warn boot parameter To: Alexey Khoroshilov Cc: Linus Torvalds , Petr Mladek , "Paul E. McKenney" , Alexander Popov , 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 , Greg Kroah-Hartman , Mark Rutland , Andy Lutomirski , Dave Hansen , Steven Rostedt , Thomas Garnier , Will Deacon , Ard Biesheuvel , Laura Abbott , David S Miller , Borislav Petkov , Kernel Hardening , linux-hardening@vger.kernel.org, "open list:DOCUMENTATION" , Linux Kernel Mailing List , notify@kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 27, 2022 at 6:17 PM Alexey Khoroshilov wrote: > On 01.10.2021 22:59, Linus Torvalds wrote: > Coming back to the discussion of WARN_ON()/pr_warn("WARNING:") semantics. > > We see a number of cases where WARNING is used to inform userspace that > it is doing something wrong, e.g. > https://elixir.bootlin.com/linux/v5.19-rc8/source/net/can/j1939/socket.c#L181 > https://elixir.bootlin.com/linux/v5.19-rc8/source/drivers/video/fbdev/core/fbmem.c#L1023 > > It is definitely useful, but it does not make sense in case of fuzzing > when the userspace should do wrong things and check if kernel behaves > correctly. > > As a result we have warnings with two different intentions: > - warn that something wrong happens in kernel, but we are able to continue; > - warn userspace that it is doing something wrong. > > During fuzzing we would like to report the former and to ignore the > latter. Are any ideas how these intentions can be recognized automatically? https://elixir.bootlin.com/linux/v5.19-rc8/source/include/asm-generic/bug.h#L74 says: * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report * significant kernel issues that need prompt attention if they should ever * appear at runtime. * * Do not use these macros when checking for invalid external inputs * (e.g. invalid system call arguments, or invalid data coming from * network/devices), and on transient conditions like ENOMEM or EAGAIN. * These macros should be used for recoverable kernel issues only. * For invalid external inputs, transient conditions, etc use * pr_err[_once/_ratelimited]() followed by dump_stack(), if necessary. * Do not include "BUG"/"WARNING" in format strings manually to make these * conditions distinguishable from kernel issues. So if you see drivers intentionally using WARN() or printing "WARNING:" on codepaths that are reachable with bogus inputs from userspace, those codepaths should be fixed to log warnings in a different format.