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=-3.8 required=3.0 tests=BAYES_00, 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 E7BC4C433B4 for ; Thu, 22 Apr 2021 20:50:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A34C7613E1 for ; Thu, 22 Apr 2021 20:50:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239296AbhDVUvO (ORCPT ); Thu, 22 Apr 2021 16:51:14 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:50192 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S236851AbhDVUvN (ORCPT ); Thu, 22 Apr 2021 16:51:13 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 13MKm4pR001839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Apr 2021 16:48:04 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 3C1D015C3B0D; Thu, 22 Apr 2021 16:48:04 -0400 (EDT) Date: Thu, 22 Apr 2021 16:48:04 -0400 From: "Theodore Ts'o" To: Doug Ledford Cc: Jason Gunthorpe , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Linus Torvalds , Aditya Pakki , Kangjie Lu , Qiushi Wu , x86@kernel.org, Bjorn Helgaas , "Rafael J. Wysocki" , Arnd Bergmann , David Airlie , Michael Turquette , Bjorn Andersson , Linus Walleij , Bartosz Golaszewski , Daniel Vetter , Jean Delvare , Guenter Roeck , Jiri Kosina , Will Deacon , Laurent Pinchart , Jakub Kicinski , "David S. Miller" , Johan Hovold , Jiri Slaby , Pablo Neira Ayuso , Johannes Berg , Takashi Iwai Subject: Re: [PATCH 000/190] Revertion of all of the umn.edu commits Message-ID: References: <20210421130105.1226686-1-gregkh@linuxfoundation.org> <20210421180155.GA2287172@nvidia.com> <18edc472a95f1d4efe3ef40cc9b8d2611d4ab990.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18edc472a95f1d4efe3ef40cc9b8d2611d4ab990.camel@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 22, 2021 at 02:53:12PM -0400, Doug Ledford wrote: > I have to agree with Jason. This seems like trying to push a thumbtack > into a bulletin board using a pyle driver. Unless the researchers are > lying (which I've not seen a clear indication of), the 190 patches you > have selected here are nothing more than collateral damage while you are > completely missing the supposed patch submission addresses from which > the malicious patches were sent! The 190 reverts are going through the standard review process. Quite a few of those patches are getting a "this looks good, please don't revert". And these reverts aren't going to be going in for 5.12, but rather for the next merge window. So we have plenty of time to review them and either (a) drop the revert, or (b) if it does get reverted, we can always re-apply it after it gets proper review. Given that some of the 190 patches have been found to contain bugs, regardless of whether they were submitted in good faith or not, it may be that some of these buggy patches may point out opportunities for us to improve our patch review processes. So as a random sampling of "trivial" (or maybe not-so-trivial) patches sent from a university since 2018, doing a more careful patch review is precisely a way to, as you put it: > harden the maintenance process against these sorts of things. > This all really sounds like a knee-jerk reaction to thier posting. I > have to say, I think it's the wrong reaction to have. Remember, these > guys are the ones explaining how things can be done and exposing the > tricks. That puts them in the white-hat hacker camp, not the black-hat > hacker camp. The idea of turning some students loose on trying to get evil patches past some kernel maintainers that had worried me didn't appear to be doing adequate review is something that had crossed my mind over 10 or 15 years ago. I just didn't do it because, (a) the obvious ethics concerns, and (b) it wouldn't actually tell us anything new. Also, even the assistant department head of the UMN CS department has admitted that this was clearly an IRB failure, and that what they did was clearly Human Subject Research that should have been stopped cold at the "get permission from the IRB" stage. So that puts them in the gray-hat category at best. > You shouldn't be banning them, you should be listening to > them and seeing if they found any constructive ways to improve and > harden the maintenance process against these sorts of things. Well, the paper is available. Aside from the obvious, "be more careful with code reviews", they had the advice of adding to our Code of Conduct, "don't do this unethical thing we just did". Which might or might not work in terms of preventing academics who submitted patches in bad faith, but I very much would prevent someone working for the Ministry of State Security. So you could consider doing an in-depth review of the patches sent from umn.edu to be a step towards doing more careful review. Let's see what we learn from that analysis. - Ted