Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

411–420 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#411

This is supremely fucked up and I’d say is borderline criminal. It’s really lucky asshole researchers like this haven’t caused a bug that cost billions of dollars, or killed someone, because eventually shit like this will... and holy shit will “it was just research” do nothing to save them.

[deleted]

Re: “They introduce kernel bugs on purpose”

#412

How does something like this get through IRB - I always felt IRB was over the top - and then they approve something like this? UMN looks pretty shoddy - the response from the researcher saying these were automated by a tool looks like a potential lie.

IRB is useless. They don't use much context, including if the speediness of IRB approval would save lives. You could make a reasonable argument that IRB has contributed to millions of preventable deaths at this point, with COV alone it's at least dozens of thousands if not far more.

I don't disagree.

Re: “They introduce kernel bugs on purpose”

#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 kernel. The three attempts did not even become Git commits.

Greg has all reasons to be unhappy since they were unknowingly experimented on and used as lab rats. However, the round of patches that triggered his anger *are very likely* to have nothing to do with the three intentionally incorrect patch attempts leading to the paper. Many people on HN do not seem to know this.

[1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....

Re: “They introduce kernel bugs on purpose”

#414

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.

Yup, it's basically stating the obvious: that any system based on an assumption of good faith is vulnerable to bad faith actors. The kernel devs are probably on the lookout for someone trying to introduce backdoors, but simply introducing a bug for the sake of introducing a bug (without knowing if it can be exploited), which is obviously much easier to do stealthily - why would anyone do that? Except for "academic research" of course...

Re: “They introduce kernel bugs on purpose”

#415

They should be reported to the authorities for attempting to introduce security vulnerabilities into software intentionally. This is not ok.

The fact that both of the researchers seem to be of Chinese origin should definitely raise some questions. Not the first time things like this have been tried.

Re: “They introduce kernel bugs on purpose”

#416

How does something like this get through IRB - I always felt IRB was over the top - and then they approve something like this? UMN looks pretty shoddy - the response from the researcher saying these were automated by a tool looks like a potential lie.

IRB is useless. They don't use much context, including if the speediness of IRB approval would save lives. You could make a reasonable argument that IRB has contributed to millions of preventable deaths at this point, with COV alone it's at least dozens of thousands if not far more.

This is the unfortunate attitude that leads to bad research and reduces trust in science. If you think IRB has contributed to deaths you should make a case, because right now you sound like a blowhard.

Re: “They introduce kernel bugs on purpose”

#417

Commenters have been reasonably accusing the researchers of bad practice, but I think there's another possible take here based on Hanlon's razor: "never attribute to malice that which is adequately explained by stupidity". If you look at the website of the PhD student involved [1], they seem to be writing mostly legitimate papers about, for example, using static analysis to find bugs. In this kind of research, having…

That looks like a different person from the name in the article.

Re: “They introduce kernel bugs on purpose”

#418

How does something like this get through IRB - I always felt IRB was over the top - and then they approve something like this? UMN looks pretty shoddy - the response from the researcher saying these were automated by a tool looks like a potential lie.

> the response from the researcher saying these were automated by a tool looks like a potential lie. To be clear, this is unethical research. But I read the paper, and these patches were probably automatically generated by a tool (or perhaps guided by a tool, and filled in concretely by a human): their analyses boil down to a very simple LLVM pass that just checks for pointer dereferences and inserts calls to functio…

Thanks for this, very helpful.

Could they have submitted patches to fix the problems based on same tooling or was that not possible (I am not close to kernel development flow)?

Re: “They introduce kernel bugs on purpose”

#419

This isn't friendly pen-testing in a community, this is an attack on critical infrastructure using a university as cover. The foundation should sue the responsible profs personally and seek criminal prosecution. I remember a bunch of U.S. contractors said they did the same thing to one of the openbsd vpn library projects about 15 years ago as well. What this professor is proving out is that open source and (likely, o…

> The foundation should sue the responsible profs personally and seek criminal prosecution.

This is overkill and uncalled for.

Post reply on HN