Comment by seanieb

4 years ago

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?

11 comments

seanieb

Reply
st_goliath  4 years 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.h...

[2] https://scan.coverity.com/projects/linux

[3] https://cki-project.org/

[4] https://bottest.wiki.kernel.org/

[5] https://syzkaller.appspot.com/upstream

viraptor  4 years 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@fie...

  • meitham  4 years 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  4 years 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.

foobar33333  4 years ago

>Whats being done to address those issues?

Moving to rust to limit the scope of possible bugs.

  • metalliqaz  4 years 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  4 years 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.

      1 reply →