Victor what is your interpretation of the results presented in the syzkaller slide deck?
Conversation
This Tweet was deleted by the Tweet author. Learn more
ok! so then would it be fair to say that you don't believe these bugs reflect any sort of shortcoming in the C language, but rather they all stem from ineptitude or a refusal to follow best practices?
1
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
That's really not true. The vast majority of the Linux kernel doesn't inherently involve unsafe operations. The lack of safe abstractions (which cannot be made in C) lead to having pervasive unsafe code. It already makes many of these abstractions. C just can't enforce safety.
1
Using a memory safe language for a kernel does not mean you cannot implement these unsafe operations. It means that you implement them in contained unsafe code that exposes safe APIs. It's really not hard to understand how that works. These abstractions already exist in Linux.
1
Linux kernel drivers are not doing things like directly copying userspace memory to the kernel. They're using abstractions, which in a memory safe language would be safe, but are unsafe due to C being unable to enforce memory safety. They do *try* to make safe abstractions.
1
However, fundamentally, they are unable to do that because memory safety remains and issue in the entirety of the code despite wrapping everything else and eliminating other safety issues. That's why nearly all the vulnerabilities are memory corruption.
1
You make it sound like they are open coding the same low-level unsafe things everywhere, which couldn't be further from the truth. These things get implemented once as reusable code. Rust would be enforcing that they're used correctly. Vast majority of code doesn't need 'unsafe'.
1
The core kernel also doesn't need to be large, with drivers and everything else inside it. Most of the things in the kernel do not really need to be written in a low-level language like C or Rust at all. It makes sense to do that for performance in many cases, but not always.