lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 25 May 2020 12:07:49 +0300 From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com> To: Steve deRosier <derosier@...il.com> Cc: Luis Chamberlain <mcgrof@...nel.org>, Johannes Berg <johannes@...solutions.net>, Jakub Kicinski <kuba@...nel.org>, Ben Greear <greearb@...delatech.com>, jeyu@...nel.org, akpm@...ux-foundation.org, arnd@...db.de, rostedt@...dmis.org, mingo@...hat.com, aquini@...hat.com, cai@....pw, dyoung@...hat.com, bhe@...hat.com, peterz@...radead.org, tglx@...utronix.de, gpiccoli@...onical.com, pmladek@...e.com, Takashi Iwai <tiwai@...e.de>, schlad@...e.de, Kees Cook <keescook@...omium.org>, Daniel Vetter <daniel.vetter@...ll.ch>, will@...nel.org, mchehab+samsung@...nel.org, Kalle Valo <kvalo@...eaurora.org>, "David S. Miller" <davem@...emloft.net>, Network Development <netdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, linux-wireless <linux-wireless@...r.kernel.org>, ath10k@...ts.infradead.org, jiri@...nulli.us, briannorris@...omium.org Subject: Re: [RFC 1/2] devlink: add simple fw crash helpers On Fri, May 22, 2020 at 04:23:55PM -0700, Steve deRosier wrote: > On Fri, May 22, 2020 at 2:51 PM Luis Chamberlain <mcgrof@...nel.org> 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
Powered by blists - more mailing lists