|
|
|
|
|
|
by ncann
1885 days ago
|
|
|
I have followed the situation somewhat closely as well and there seem to be a lot of misinformation being thrown around. As far as I can tell (correct me if I'm wrong), no actual malicious commit has been found to be deliberately introduced and merged into the tree, and most of the recent commits that triggered this whole mess were from a claimed custom static analyzers that resulted in wrong/useless patches but not necessarily malicious. I honestly think the situation is somewhat overblown, and some maintainers think so as well. To quote Jason Gunthorpe: > So, this revert is based on not trusting the authors to carry out their work in the manner they explained? From what I've reviewed, and general sentiment of other people's reviews I've read, I am concerned this giant revert will degrade kernel quality more than the experimenters did - especially if they followed their stated methodology. and Doug Ledford: > 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! https://lore.kernel.org/lkml/20210421180155.GA2287172@nvidia... https://lore.kernel.org/lkml/18edc472a95f1d4efe3ef40cc9b8d26... |
|
|
My understanding is that the malicious commits described in their paper were submitted under alias email addresses, and the authors have not identified those addresses or the commits. So at this point there is no way to confirm that these malicious commits were properly reverted besides taking the authors word for it. To quote Mike Dolan's letter: "While the U of MN researchers claimed to take steps to prevent inclusion of vulnerabilities in the final software, their failure to gain consent suggests a lack of care. There are also amplified consequences because Linux kernel changes are picked up by many other downstream projects that build off of the kernel codebase." And I think it's fair for maintainers to question the competence and want to be able to verify everything, especially considering the consequences if the authors made a mistake.
But yes, assuming they used fake accounts, none of those 190 or so patches selected are the malicious ones from the paper. None of them appear to introduce any vulnerabilities, and the same for the weird commits from Aditya.