Victor what is your interpretation of the results presented in the syzkaller slide deck?
This Tweet was deleted by the Tweet author. Learn more
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
The vast majority of the Linux kernel has no need for memory unsafe code. Rust still offers full low-level control and in fact exposes more low-level features of the hardware than C, where you usually need to use tons of non-portable compiler intrinsics and more inline assembly.
2
More importantly, it has no legitimate need to run in ring0/with physical/kernel memory mapped. Privilege separation is always better (and easier) than memory-safety.
1
You don't need to choose between them, and privilege separation is much weaker when the attack surface exposed between the components is memory unsafe. It's not hard to choose to write code in a memory safe language, and productivity is generally higher anyway. It's easier.
1
For existing code, it's definitely easier to implemented a sandbox than to rewrite it. There are plenty of new drivers and filesystems being written though. We're very likely to move on from filesystems like ext4 and existing drivers anyway, as we've done with most past ones.
1
I don't think it makes sense to rewrite all the existing drivers for a platform in a memory safe language. I do think it makes sense to stop using C as the first choice for writing new drivers, especially since they should be outside the Linux kernel in an isolated process.
1
Don't need to worry about trying to introduce another language in the Linux kernel because most drivers should not be in ring0 in the first place. I definitely don't think all these miscellaneous drivers for sensors, etc. need to be there.
iOS 12 moved most of the network stack to userspace *largely due to performance reasons*. Their network device drivers are still in the kernel (not ideal) but TCP/IP is implemented in userspace, which moves most of the complexity / attack surface outside of the kernel.
1
2
I think it works as a library now, so it's not as ideal as an implementation like github.com/google/netstack (which Fuchsia uses) where it's isolated from everything else at a (quite reasonable for a client) performance cost, but it's way better than having it in the kernel.
1