No, that's not what he means. He's saying that an external file system should have a sandboxed filesystem driver, so that exploiting a bug inside it doesn't immediately grant complete control over the entire system and at least requires privesc to escape (likely via the kernel).
Conversation
Try reading the overview in events.linuxfoundation.org/wp-content/upl. Finding a Linux kernel vulnerability is not hard. Literally hundreds of bugs are found by syszkiller every month and many are not fixed. Most are memory corruption. There are simply too many to even fix all discovered bugs.
2
5
yes, we don't need to debate the question "can people write memory safe code in C" the answer is overwhelmingly obvious to almost all of us
3
1
18
This Tweet was deleted by the Tweet author. Learn more
Victor what is your interpretation of the results presented in the syzkaller slide deck?
1
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
Separately from using a memory safe language for most of the code, device drivers usually do not need to run in a privileged context. They can be run in an isolated process with the IOMMU containing the hardware. Exploiting a network driver shouldn't compromise a whole system.
1
1
A kernel designed with security and robustness in mind isn't going to make the same architecture and tooling decisions as the Linux kernel. It's the equivalent to putting the entirety of userspace into a single process with no security boundaries, and no memory safe languages.