Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp800862pxy; Thu, 22 Apr 2021 13:51:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRRQyK0S7uKrPGF1fb6zkvYfjQehIVsRAStvE+r9/Xon62+A0gXWlbAp0tc3T7gBG+nS99 X-Received: by 2002:a05:6402:30a5:: with SMTP id df5mr462209edb.250.1619124714777; Thu, 22 Apr 2021 13:51:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619124714; cv=none; d=google.com; s=arc-20160816; b=UOiIqwPZFTbSINZVpzN5sc8RghuLVOJ7Dnylnje2YWGsHTjLuOkRI0RUTBlxau6WpU 6RI+e8A4yS+uOtHPUhzAlET8ifK5oh7Ae78732G1nJe9AltMyjec7DqF4TIWkpaIavKU r8mSZJV3K8ZLymOAFkwlAfYhFpWPvXkuEcdtxKUqWmfOwlrCnnAMf+HCWXBEsTCXrf1V n5uTt2WPRzwShZrzj5ZXd8H+MllOhDoeBVUEiwCRtWUp+1h/UFxkezqKo9zTjkRX8viB dS7rYItmt3Ms2maZn4tWNciA8RwUQetg6SnO28fWhJ3dIRV7lNQ8wW2foIv/pgYLba6N fpPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=43wx/e5F5pp0hIAFoDPL+Jzd7o/hr5R3TLmixYB8SLk=; b=HH8fnmgwWxKvWeuB5gzL8pWECCBkeIQ7tvQkNxdstOi1BnmgRUFAEwe2WnnvL5UUWY B5Y6/a3FA0CVvIeP1jtpMAJ1FdLMiI1VPct+FvUQ7nfW0x0zEVE8ETlzN/NahFvcdAN3 eQfqRV6QQv42y6tShJXBUZ6uiZHfepJfVfoq6AhCgnx8zN8yfxH5G6DusNXmkzpJOvJh RQjPbjBcHE0CP1mIEFA9NCq1lYl4/kOQxvjKKDyUxdSU+ccHlL8dXw9R8i17rXt1kLib 93D016rpoXQVQ0ohCSBYGb6O7wMu8cAPKnpnwWJJaLNEtFUavRpobJ5Lawo7fw7AAYmP KdMg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v12si3003576edc.495.2021.04.22.13.51.31; Thu, 22 Apr 2021 13:51:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236974AbhDVUvO (ORCPT + 99 others); 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