Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

661–670 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#661
post #413

Some clarifications since they are unclear in the original report. - Aditya Pakki (the author who sent the new round of seemingly bogus patches) is not involved in the S&P 2021 research. This means Aditya is likely to have nothing to do with the prior round of patching attempts that led to the S&P 2021 paper. - According to the authors' clarification [1], the S&P 2021 paper did not introduce any bugs into Linux kerne…

> S&P 2021 paper did not introduce any bugs into Linux kernel.

I used to work as an auditor. We were expected to conduct our audits to neither expect nor not expect instances of impropriety to exist. However, once we had grounds to suspect malfeasance, we were "on alert", and conduct tests accordingly.

This is a good principle that could be applied here. We could bat backwards and forwards about whether the other submissions were bogus, but the presumption must now be one of guilt rather than innocence.

Personally, I would have been furious and said, in no uncertain terms, that the university keep a low profile and STFU lest I be sufficiently provoked to taking actions that lead to someone's balls being handed to me on a plate.

Re: “They introduce kernel bugs on purpose”

#663
post #342

> I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts. Maybe not being nice is part of the immune system of open source.

Absolutely. The derision that people like Linus get for being “mean” to big corpos trying to submit shitty patches is totally misplaced.

Re: “They introduce kernel bugs on purpose”

#664
post #267

The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…

Thanks for the support. I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point in time: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...

Putting the ethical question of the researcher aside, the fact you want to "properly review them at a later point in time" seems to suggest a lack of confidence in the kernel review process.

Since this researcher is apparently not an established figure in the kernel community, my expectation is the patches have gone through the most rigorous review process. If you think the risk of malicious patches from this person have got in is high, it means that an unknown attacker deliberately concerting complex kernel loop hole would have a even higher chance got patches in.

While I think the researcher's actions are out of line for sure. This "I will ban you and revert all your stuff" retaliation seems emotional overaction.

Re: “They introduce kernel bugs on purpose”

#666

This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. It's not that they're doing this, I'm sure they're not the first to think of this (for research or malicious reasons), but having the gall to brag about it is a new low.

> having the gall to brag about it is a new low Even worse: They bragged about it, then sent a new wave of buggy patches to see if the "test subjects" fall for it once again, and then tried to push the blame on the kernel maintainers for being "intimidating to newbies". This is thinly veiled and potentially dangerous bullying.

I'm gonna go against the grain here and say I don't think this is a continuation of the original research. It'd be a strange change in methodology. The first paper used temporary email addresses, why switch to a single real one? The first paper alerted maintainers as soon as patches were approved, why switch to allowing them to make it through to stable? The first paper focused on a few subtle changes, why switch to random scattershot patches? Sure, this person's advisor is listed as a co-author of the first paper, but that really doesn't imply the level of coordination that people are assuming here.

Re: “They introduce kernel bugs on purpose”

#667
I have to question the true motivations behind this. Just a "mere" research paper? Or is it there an ulterior motive, such as undermining Linux kernel development, taking advantage of the perceived hostility of the LKML to make a big show of it; castigate and denounce those elitist Linux kernel devs?

So I hear tinfoil is on sale, mayhaps I should stock up.

Re: “They introduce kernel bugs on purpose”

#669

This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. It's not that they're doing this, I'm sure they're not the first to think of this (for research or malicious reasons), but having the gall to brag about it is a new low.

Technically analogous to pen testing except that it wasn’t done at the behest of the target, as legal pen testing is done. Hence it is indistinguishable from and must be considered, a malicious attack.

Re: “They introduce kernel bugs on purpose”

#670
post #413

Some clarifications since they are unclear in the original report. - Aditya Pakki (the author who sent the new round of seemingly bogus patches) is not involved in the S&P 2021 research. This means Aditya is likely to have nothing to do with the prior round of patching attempts that led to the S&P 2021 paper. - According to the authors' clarification [1], the S&P 2021 paper did not introduce any bugs into Linux kerne…

> According to the authors' clarification [1], the S&P 2021 paper did not introduce any bugs into Linux kernel. The three attempts did not even become Git commits.

Except that at least one of those three, did [0]. The author is incorrect that none of their attempts became git commits. Whatever process that they used to "check different versions of Linux and further confirmed that none of the incorrect patches was adopted" was insufficient.

[0] https://lore.kernel.org/patchwork/patch/1062098/

Post reply on HN