4 ms·

Regardless of their methods, I think they just proved the kernel security review process is non-existent. Either in the form of static analysis or human review.

Regardless of their methods, I think they just proved the kernel security review process is non-existent. Either in the form of static analysis or human review. Whats being done to address those issues?

st_goliath 5y ago
> non-existent... static analysis .... Whats being done to address those issues? Static analysis is being done[1][2], in addition, there are also CI test farms[3][4], fuzzing farms[5], etc. Linux is a project that enough large companies have a stake in that there are some willing to throw resources like this at it. Human review is supposed to be done through the mailing list submission process. How well this works depends in my experience from ML to ML. [1] https://www.kernel.org/doc/html/v4.15/dev-tools/coccinelle.html https://www.kernel.org/doc/html/v4.15/dev-tools/coccinelle.h... [2] https://scan.coverity.com/projects/linux https://scan.coverity.com/projects/linux [3] https://cki-project.org/ https://cki-project.org/ [4] https://bottest.wiki.kernel.org/ https://bottest.wiki.kernel.org/ [5] https://syzkaller.appspot.com/upstream https://syzkaller.appspot.com/upstream
deleted 5y ago
[deleted]
viraptor 5y ago
Not sure why you think they proved that. Human review was done on the same day the patch was submitted and pointed out that it's wrong: https://lore.kernel.org/linux-nfs/20210407153458.GA28924@fieldses.org/ https://lore.kernel.org/linux-nfs/20210407153458.GA28924@fie...
- meitham 5y ago
  Human review was done after the patch was merged into stable, hence reverting was necessary. I’m confused why these patches don’t get treated as merge requests and get reviewed prior to merging!
  - rcxdude 5y ago
    This patch wasn't. Other patches from the university had made it into stable and are likely to be reversed, not because of known problems with the patches, but because of the ban.
arbitrage 5y ago
The bugs were found. Seems like it works to me.
foobar33333 5y ago
>Whats being done to address those issues? Moving to rust to limit the scope of possible bugs.
- metalliqaz 5y ago
  this is a dangerous understanding of Rust. Rust helps to avoid certain kinds of bugs in certain situations. Bugs are very much possible in Rust and the scope of bugs usually depends more on the system than the language used to write it.
  - virgilp 5y ago
    I get where you're coming from, but I disagree. They actually prey on seemingly small changes that have large "unintended"/non-obvious side-effects. I argue that finding such situations is much much harder in Rust than in C. Is it impossible? Probably not (especially not in unsafe code), but I do believe it limits the attack surface quite a lot. Rust is not a definitive solution, but it can be a (big) part of the solution.
    - metalliqaz 5y ago
      yes it definitely limits the attack surface. remember that in systems programming there are bugs that cause errors in computation, which Rust is pretty good at protecting; but there are also bugs which cause unintended behaviors, usually from incorrect or incomplete requirements, or implementation edge cases.
  - deleted 5y ago
    [deleted]

st_goliath 5y ago

> non-existent... static analysis .... Whats being done to address those issues? Static analysis is being done[1][2], in addition, there are also CI test farms[3][4], fuzzing farms[5], etc. Linux is a project that enough large companies have a stake in that there are some willing to throw resources like this at it. Human review is supposed to be done through the mailing list submission process. How well this works depends in my experience from ML to ML. [1] https://www.kernel.org/doc/html/v4.15/dev-tools/coccinelle.html https://www.kernel.org/doc/html/v4.15/dev-tools/coccinelle.h... [2] https://scan.coverity.com/projects/linux https://scan.coverity.com/projects/linux [3] https://cki-project.org/ https://cki-project.org/ [4] https://bottest.wiki.kernel.org/ https://bottest.wiki.kernel.org/ [5] https://syzkaller.appspot.com/upstream https://syzkaller.appspot.com/upstream

deleted 5y ago

[deleted]

viraptor 5y ago

Not sure why you think they proved that. Human review was done on the same day the patch was submitted and pointed out that it's wrong: https://lore.kernel.org/linux-nfs/20210407153458.GA28924@fieldses.org/ https://lore.kernel.org/linux-nfs/20210407153458.GA28924@fie...

meitham 5y ago
Human review was done after the patch was merged into stable, hence reverting was necessary. I’m confused why these patches don’t get treated as merge requests and get reviewed prior to merging!
- rcxdude 5y ago
  This patch wasn't. Other patches from the university had made it into stable and are likely to be reversed, not because of known problems with the patches, but because of the ban.

arbitrage 5y ago

The bugs were found. Seems like it works to me.

foobar33333 5y ago

>Whats being done to address those issues? Moving to rust to limit the scope of possible bugs.

metalliqaz 5y ago
this is a dangerous understanding of Rust. Rust helps to avoid certain kinds of bugs in certain situations. Bugs are very much possible in Rust and the scope of bugs usually depends more on the system than the language used to write it.
- virgilp 5y ago
  I get where you're coming from, but I disagree. They actually prey on seemingly small changes that have large "unintended"/non-obvious side-effects. I argue that finding such situations is much much harder in Rust than in C. Is it impossible? Probably not (especially not in unsafe code), but I do believe it limits the attack surface quite a lot. Rust is not a definitive solution, but it can be a (big) part of the solution.
  - metalliqaz 5y ago
    yes it definitely limits the attack surface. remember that in systems programming there are bugs that cause errors in computation, which Rust is pretty good at protecting; but there are also bugs which cause unintended behaviors, usually from incorrect or incomplete requirements, or implementation edge cases.
- deleted 5y ago
  [deleted]