As a side note to all of the discussion here, it would be really nice if we could find ways to take all of the incredible linux infrastructure, and repurpose it for SeL4. It is pretty scary that we've got ~30M lines of code in the kernel and the primary process we have to catch major security bugs is to rely on the experienced eyes of Greg KH or similar. They're awesome, but they're also human. It would be much better to rely on capabilities and process isolation.
“They introduce kernel bugs on purpose”
511–520 of 1001 posts
Re: “They introduce kernel bugs on purpose”
#512Sure. And we are well past the time in which we need to develop real legal action and/or policy -- with consequences against this sort of thing.
We have an established legal framework to do this. It's called "tort law," and we need to learn how to point it at people who negligently or maliciously create and or mess with software.
What makes it difficult, of course, is that not only should it be pointed at jerk researchers, but anyone who works on software, provably knows the harm their actions can or do cause, and does it anyway. This describes "black hat hackers," but also quite a few "establishment" sources of software production.
Re: “They introduce kernel bugs on purpose”
#513Presumably the next step is an attempt to cancel the kernel maintainers on account of some politically powerful - oops, I mean, some politically protected characteristics of the researchers.
Re: “They introduce kernel bugs on purpose”
#514How 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.
By COV do you mean Covid? It sounds like you're alluding to the argument that if they'd only let us test potential vaccines on humans right away then we would have had a vaccine faster. I disagree that that's a foregone conclusion, and you certainly need a strong argument or evidence to make such a claim.
Re: “They introduce kernel bugs on purpose”
#515This 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.
At this point how do you even make the difference between their genuine behavior and the behavior that is part of the research?
Re: “They introduce kernel bugs on purpose”
#516I did my Ph.D in cognitive neuroscience, where I conducted experiments on human subjects. Running these kinds of experiments required approval from an ethics committee, which for all their faults (and there are many), are quite good at catching this kind of shenanigans. Is there not some sort of equivalent in this field?
It seems they lied to the ethics committee. But I'm not holding my breath for the University to sanction them or withdraw/EoC their papers, because Universities prefer to have these things swept under the carpet.
>they lied to the ethics committee
That'll be a fraud, no?
Re: “They introduce kernel bugs on purpose”
#517Some 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…
This is Aditya Pakki's webiste:
https://adityapakki.github.io/
In this "About" page:
https://adityapakki.github.io/about/
he claims "Hi there! My name is Aditya and I’m a second year Ph.D student in Computer Science & Engineering at the University of Minnesota. My research interests are in the areas of computer security, operating systems, and machine learning. I’m fortunate to be advised by Prof. Kangjie Lu."
so he in no uncertain terms is claiming that he is being advised in his research by Kangjie Lu. So it's incorrect to say his patches have nothing to do with the paper.
Re: “They introduce kernel bugs on purpose”
#518Research without ethics is research without value. Unbelievable that this could have passed ethics review, so I'd bet it was never reviewed. Big black eye for University of Minnesota. Imagine if you are another doctoral student is CS/EE and this tool has ruined your ability to participate in Linux.
I'm a total neophyte when it comes to the Linux kernel development process, but couldn't they just, y'know, use a Gmail address or something? Couldn't the original researchers have done the same?
Re: “They introduce kernel bugs on purpose”
#519This is the kind of study (unusual for CS) that requires IRB approval. I wonder if they thought to seek approval, and if they received it?
Re: “They introduce kernel bugs on purpose”
#520Think of potential downstream effects of a vulnerable patch being introduced into Linux kernel. Buggy software in mobile devices, servers, street lights... this is like someone introducing a bug into university grading system.
Someone should look into who sponsored this research. Was there a state agent?