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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E44AAC433DF for ; Mon, 25 May 2020 09:08:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CA0862068D for ; Mon, 25 May 2020 09:08:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389334AbgEYJH4 (ORCPT ); Mon, 25 May 2020 05:07:56 -0400 Received: from mga14.intel.com ([192.55.52.115]:18280 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389329AbgEYJH4 (ORCPT ); Mon, 25 May 2020 05:07:56 -0400 IronPort-SDR: TwTGpNA9I0nt35eU9+sFcIXDiLghL9hQ99AStf5mZH78yEhh8ApDE3dRF017AnoOcYXNUk5wqX wVDIK0gmBEfQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 May 2020 02:07:55 -0700 IronPort-SDR: 2hLbY16UNixp9uKwA+HoIovAgK51uxmidktw1TbuKfD5n9hRLrdAJfizedCATlB4/xfOf6J+bL +7VHvJIgi+Cg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,432,1583222400"; d="scan'208";a="301770713" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga008.jf.intel.com with ESMTP; 25 May 2020 02:07:47 -0700 Received: from andy by smile with local (Exim 4.93) (envelope-from ) id 1jd95J-008ktF-4y; Mon, 25 May 2020 12:07:49 +0300 Date: Mon, 25 May 2020 12:07:49 +0300 From: Andy Shevchenko To: Steve deRosier Cc: Luis Chamberlain , Johannes Berg , Jakub Kicinski , Ben Greear , jeyu@kernel.org, akpm@linux-foundation.org, arnd@arndb.de, rostedt@goodmis.org, mingo@redhat.com, aquini@redhat.com, cai@lca.pw, dyoung@redhat.com, bhe@redhat.com, peterz@infradead.org, tglx@linutronix.de, gpiccoli@canonical.com, pmladek@suse.com, Takashi Iwai , schlad@suse.de, Kees Cook , Daniel Vetter , will@kernel.org, mchehab+samsung@kernel.org, Kalle Valo , "David S. Miller" , Network Development , LKML , linux-wireless , ath10k@lists.infradead.org, jiri@resnulli.us, briannorris@chromium.org Subject: Re: [RFC 1/2] devlink: add simple fw crash helpers Message-ID: <20200525090749.GJ1634618@smile.fi.intel.com> References: <20200519010530.GS11244@42.do-not-panic.com> <20200519211531.3702593-1-kuba@kernel.org> <20200522052046.GY11244@42.do-not-panic.com> <20200522101738.1495f4cc@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <2e5199edb433c217c7974ef7408ff8c7253145b6.camel@sipsolutions.net> <20200522215145.GC11244@42.do-not-panic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Fri, May 22, 2020 at 04:23:55PM -0700, Steve deRosier wrote: > On Fri, May 22, 2020 at 2:51 PM Luis Chamberlain wrote: > I had to go RTFM re: kernel taints because it has been a very long > time since I looked at them. It had always seemed to me that most were > caused by "kernel-unfriendly" user actions. The most famous of course > is loading proprietary modules, out-of-tree modules, forced module > loads, etc... Honestly, I had forgotten the large variety of uses of > the taint flags. For anyone who hasn't looked at taints recently, I > recommend: https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html > > In light of this I don't object to setting a taint on this anymore. > I'm a little uneasy, but I've softened on it now, and now I feel it > depends on implementation. > > Specifically, I don't think we should set a taint flag when a driver > easily handles a routine firmware crash and is confident that things > have come up just fine again. In other words, triggering the taint in > every driver module where it spits out a log comment that it had a > firmware crash and had to recover seems too much. Sure, firmware > shouldn't crash, sure it should be open source so we can fix it, > whatever... While it may sound idealistic the firmware for the end-user, and even for mere kernel developer like me, is a complete blackbox which has more access than root user in the kernel. We have tons of firmwares and each of them potentially dangerous beast. As a user I really care about my data and privacy (hacker can oops a firmware in order to set a specific vector attack). So, tainting kernel is _a least_ we can do there, the strict rules would be to reboot immediately. > those sort of wishful comments simply ignore reality and > our ability to affect effective change. We can encourage users not to buy cheap crap for the starter. > A lot of WiFi firmware crashes > and for well-known cases the drivers handle them well. And in some > cases, not so well and that should be a place the driver should detect > and thus raise a red flag. If a WiFi firmware crash can bring down > the kernel, there's either a major driver bug or some very funky > hardware crap going on. That sort of thing we should be able to > detect, mark with a taint (or something), and fix if within our sphere > of influence. I guess what it comes down to me is how aggressive we > are about setting the flag. -- With Best Regards, Andy Shevchenko