FS drivers do not belong in privileged contexts. The FS driver for an untrusted FS should be executing in a context where it can do nothing worse than store or retrieve wrong data.
Conversation
This Tweet was deleted by the Tweet author. Learn more
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).
1
4
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
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.
Having low-level control and memory unsafe access available does not mean that you should write the majority of the code that way. The memory unsafe code can be contained into implementations of safe APIs, so that the trusted computing base for memory safety is extremely small.
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
Show replies