linux-kernel - Re: [PATCH 157/190] Revert "Input: ad7879 - add check for read errors in interrupt"

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YIhkZOWJiOlDJCYS@google.com>
Date:   Tue, 27 Apr 2021 12:22:12 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, Aditya Pakki <pakki001@....edu>
Subject: Re: [PATCH 157/190] Revert "Input: ad7879 - add check for read
 errors in interrupt"

On Tue, Apr 27, 2021 at 06:55:10PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 10:03:33AM -0700, Dmitry Torokhov wrote:
> > Hi Greg,
> > 
> > On Wed, Apr 21, 2021 at 03:00:32PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.
> > > 
> > > Commits from @umn.edu addresses have been found to be submitted in "bad
> > > faith" to try to test the kernel community's ability to review "known
> > > malicious" changes.  The result of these submissions can be found in a
> > > paper published at the 42nd IEEE Symposium on Security and Privacy
> > > entitled, "Open Source Insecurity: Stealthily Introducing
> > > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> > > of Minnesota) and Kangjie Lu (University of Minnesota).
> > > 
> > > Because of this, all submissions from this group must be reverted from
> > > the kernel tree and will need to be re-reviewed again to determine if
> > > they actually are a valid fix.  Until that work is complete, remove this
> > > change to ensure that no problems are being introduced into the
> > > codebase.
> > 
> > This one looks really OK to me and does not have to be reverted (unless
> > Aditya will come clean and show the error introduced?).
> 
> I'll drop this revert, but it isn't usually good to be calling printk()
> from an irq.

How else do you suggest we tell that something is wrong when
communicating with the device? For these types of devices the
communication is essentially unsolicited so we can't pass failure to a
caller to deal with it (i.e. unlike USB there is no URB posted that we
could fail and use as a mechanism to signal error to some other layer)
and while we could invent "something went wrong" input event so far
there was no interest in having anything like that.

I'd suggest sending KOBJ_ERROR uevent when a device driver detects
anomaly in the device it controls, but I wonder how systemd would react
given past experiences with KOBJ_BIND/KOBJ_UNBIND.

The message is ratelimited so it will not overfill the logs...

Thanks.

-- 
Dmitry