4 ms·

Key takeaway from this update: One final lesson that one might be tempted to take is that the kernel is running a terrible risk of malicious patches inserted b

by lacker 5y ago

Key takeaway from this update: One final lesson that one might be tempted to take is that the kernel is running a terrible risk of malicious patches inserted by actors with rather more skill and resources than the UMN researchers have shown. That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more.

chmaynard 5y ago
Instead of submitting patches with known bugs, the UMN researcher could have done a retrospective study of patches from other kernel developers containing bugs that were later found and fixed. Not only was he acting in bad faith, he was stupid.
- hangonhn 5y ago
  There was also a high degree of arrogance on his part. That he thought his needs and priorities outweigh those of the much, much bigger community and/or that he doesn't need permission from anyone in charge of the codebase is just astounding.
- izgzhen 5y ago
  That is not considered high impact by the research community ;)
- xucheng 5y ago
  Alternatively, I think the research could be done in an isolated experiment environment among consented participants. For example, they could ask maintainers to review some set of patches outside the context of Linux kernel. They would then ask maintainers opinions on the said patches using some form of questionnaires. If the participants are well informed the nature of the experiments, there would not be any ethic concerns. For incentive, the researchers could pay for any maintainers willing to participate the experiments.
- cpeterso 5y ago
  The researcher also could have coordinated with Linux and other Linux leads, so they know which patches will be "bad". They all want the Linux review process to produce high quality code and could have suggested other ways to test the process.
  - scarmig 5y ago
    This seems ideal, but Linus would probably have accurately pointed out that it's already well-known that it wouldn't be hard for a malicious actor to insert bad code, so there's nothing really to be learnt here, at the cost of wasting the time of reviewers who are already overwhelmed.
- mumblemumble 5y ago
  Only looking at patches that were later found and fixed would not be measuring the same thing as what they were doing. Not saying what they were doing was in any way ok, but I do doubt there's any way to measure what they were trying to measure without deliberately introducing bugs into some sort of review stream. Merely using observational data would produce results that are approximately as useful as those of every other observational design. (to wit: not very)
  - hinkley 5y ago
    If you're filing a patch with a pattern you think will get by the review process, why not look to see if that pattern already existed in the code? That would give you the same information and you're potentially uncovering zero days instead of creating them, assuming those issues haven't already been fixed.
david_allison 5y ago
> the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more. Dmitry Vyuko[0] estimated in 2019 that each kernel release contains >20,000 bugs. As an outsider looking in, it seems that the kernel needs a lot more boots on the ground focusing on maintenance. [0] https://www.youtube.com/watch?v=iAfrrNdl2f4 https://www.youtube.com/watch?v=iAfrrNdl2f4 ~0:00-3:30 for statement.
- cortesoft 5y ago
  20,000 NEW bugs?! Or is it the same 20,000 that keep being brought along every release?
- cratermoon 5y ago
  I don't know if 20,000 is a large or small number for a codebase the size of the linux kernel. How about bugs per line of code? In Code Complete, Steve McConnell writes "Industry Average: about 15 – 50 errors per 1000 lines of delivered code" As of 2020, there were 27.8 million lines in the kernel git repo. By McConnell's measure, the number of bugs in the kernel is rounding error.
  - deleted 5y ago
    [deleted]
- exmadscientist 5y ago
  > As an outsider looking in, it seems that the kernel needs a lot more boots on the ground focusing on maintenance. Following kernel development a decade ago, that was exactly my opinion as well. Maintenance of older, creakier stuff gets little attention. Adding shiny new buggy features was all the rage. Code and architecture review was spotty at best, and a lot of shiny new things caused damage to old things, but no one cared because the new things were shiny.
- hinkley 5y ago
  I feel like I've had this conversation at work at least a few times. It's the ratio between new code and maintenance. Can you solve this by adding more maintainers? Yes. Can you solve it by reallocating people to maintenance? Maybe (depends if they decide to quit instead). But you can also flip it and ask if this feature focus is really helping or hurting. The parts of the work that look like 'feature factory' work should be treated as suspect. On some projects that can be half of the new work. We get so consumed trying to figure out if we can do something that we don't stop to think if we should. In a volunteer organization, however, you have to create a certain amount of busy work in order to make sure that new volunteers have stepping stones to becoming bigger contributors. Did this need to be done? No, but we needed a way to get Tom from point A to point C, where we really need his help, and so we had him do B even though it's not really much of a priority.
dekhn 5y ago
I assume this is happening already; I would expect nation states to have already inserting a number of exploits so they are prepared in case of war, to exploit the enemy's servers.
- deleted 5y ago
  [deleted]
- SirYandi 5y ago
  This just made me think, I wonder if there is some sort of Trident nuclear warhead submarine equivalent in cyberspace. Software based mutually assured destruction.
tester756 5y ago
I said that on the first post but yea people kept screaming "ethics" "ethics" haha as if apt groups gave a single fuck about your ethics
- AnimalMuppet 5y ago
  If UMN is not an APT group, then it is reasonable to expect them to have some ethics. If UMN is an APT group, then it is reasonable to ban them.
  - tester756 5y ago
    they wanted to show / remind about a way which could allow apt to do some very bad stuff
    - bronson 5y ago
      They wanted to write a paper. APTs have been trying to put holes in the kernel for 20 years now… this is not news.
ampersandy 5y ago
Surely the hot take should be that the kernel is at risk of a malicious actor introducing bugs that can be exploited, not "Oh, we already write bugs so it's not a big deal." This seems like a rather lackadaisical take on the situation.
nelsonenzo 5y ago
To add to that, the key takeaway is that they conveniently just shrug such risk off, because the alternative is more work they don't have capacity for. I mean, it's not like dependency package injection have been proven to be a good way to hack back doors or anything. /S P.s.- as a non contributor, I know I'm being a bit dickish. The truth is these researchers proved thier point in spades and no one wants to admit it. I

by lacker 5y ago

chmaynard 5y ago

Instead of submitting patches with known bugs, the UMN researcher could have done a retrospective study of patches from other kernel developers containing bugs that were later found and fixed. Not only was he acting in bad faith, he was stupid.

hangonhn 5y ago
There was also a high degree of arrogance on his part. That he thought his needs and priorities outweigh those of the much, much bigger community and/or that he doesn't need permission from anyone in charge of the codebase is just astounding.
izgzhen 5y ago
That is not considered high impact by the research community ;)
xucheng 5y ago
Alternatively, I think the research could be done in an isolated experiment environment among consented participants. For example, they could ask maintainers to review some set of patches outside the context of Linux kernel. They would then ask maintainers opinions on the said patches using some form of questionnaires. If the participants are well informed the nature of the experiments, there would not be any ethic concerns. For incentive, the researchers could pay for any maintainers willing to participate the experiments.
cpeterso 5y ago
The researcher also could have coordinated with Linux and other Linux leads, so they know which patches will be "bad". They all want the Linux review process to produce high quality code and could have suggested other ways to test the process.
- scarmig 5y ago
  This seems ideal, but Linus would probably have accurately pointed out that it's already well-known that it wouldn't be hard for a malicious actor to insert bad code, so there's nothing really to be learnt here, at the cost of wasting the time of reviewers who are already overwhelmed.
mumblemumble 5y ago
Only looking at patches that were later found and fixed would not be measuring the same thing as what they were doing. Not saying what they were doing was in any way ok, but I do doubt there's any way to measure what they were trying to measure without deliberately introducing bugs into some sort of review stream. Merely using observational data would produce results that are approximately as useful as those of every other observational design. (to wit: not very)
- hinkley 5y ago
  If you're filing a patch with a pattern you think will get by the review process, why not look to see if that pattern already existed in the code? That would give you the same information and you're potentially uncovering zero days instead of creating them, assuming those issues haven't already been fixed.

david_allison 5y ago

> the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more. Dmitry Vyuko[0] estimated in 2019 that each kernel release contains >20,000 bugs. As an outsider looking in, it seems that the kernel needs a lot more boots on the ground focusing on maintenance. [0] https://www.youtube.com/watch?v=iAfrrNdl2f4 https://www.youtube.com/watch?v=iAfrrNdl2f4 ~0:00-3:30 for statement.

cortesoft 5y ago
20,000 NEW bugs?! Or is it the same 20,000 that keep being brought along every release?
cratermoon 5y ago
I don't know if 20,000 is a large or small number for a codebase the size of the linux kernel. How about bugs per line of code? In Code Complete, Steve McConnell writes "Industry Average: about 15 – 50 errors per 1000 lines of delivered code" As of 2020, there were 27.8 million lines in the kernel git repo. By McConnell's measure, the number of bugs in the kernel is rounding error.
- deleted 5y ago
  [deleted]
exmadscientist 5y ago
> As an outsider looking in, it seems that the kernel needs a lot more boots on the ground focusing on maintenance. Following kernel development a decade ago, that was exactly my opinion as well. Maintenance of older, creakier stuff gets little attention. Adding shiny new buggy features was all the rage. Code and architecture review was spotty at best, and a lot of shiny new things caused damage to old things, but no one cared because the new things were shiny.
hinkley 5y ago
I feel like I've had this conversation at work at least a few times. It's the ratio between new code and maintenance. Can you solve this by adding more maintainers? Yes. Can you solve it by reallocating people to maintenance? Maybe (depends if they decide to quit instead). But you can also flip it and ask if this feature focus is really helping or hurting. The parts of the work that look like 'feature factory' work should be treated as suspect. On some projects that can be half of the new work. We get so consumed trying to figure out if we can do something that we don't stop to think if we should. In a volunteer organization, however, you have to create a certain amount of busy work in order to make sure that new volunteers have stepping stones to becoming bigger contributors. Did this need to be done? No, but we needed a way to get Tom from point A to point C, where we really need his help, and so we had him do B even though it's not really much of a priority.

dekhn 5y ago

I assume this is happening already; I would expect nation states to have already inserting a number of exploits so they are prepared in case of war, to exploit the enemy's servers.

deleted 5y ago
[deleted]
SirYandi 5y ago
This just made me think, I wonder if there is some sort of Trident nuclear warhead submarine equivalent in cyberspace. Software based mutually assured destruction.

tester756 5y ago

I said that on the first post but yea people kept screaming "ethics" "ethics" haha as if apt groups gave a single fuck about your ethics

AnimalMuppet 5y ago
If UMN is not an APT group, then it is reasonable to expect them to have some ethics. If UMN is an APT group, then it is reasonable to ban them.
- tester756 5y ago
  they wanted to show / remind about a way which could allow apt to do some very bad stuff
  - bronson 5y ago
    They wanted to write a paper. APTs have been trying to put holes in the kernel for 20 years now… this is not news.

ampersandy 5y ago

Surely the hot take should be that the kernel is at risk of a malicious actor introducing bugs that can be exploited, not "Oh, we already write bugs so it's not a big deal." This seems like a rather lackadaisical take on the situation.

nelsonenzo 5y ago

To add to that, the key takeaway is that they conveniently just shrug such risk off, because the alternative is more work they don't have capacity for. I mean, it's not like dependency package injection have been proven to be a good way to hack back doors or anything. /S P.s.- as a non contributor, I know I'm being a bit dickish. The truth is these researchers proved thier point in spades and no one wants to admit it. I