i.e. writing the entire thing with zero memory corruption bugs for an attacker to exploit either via an attacker controlled filesystem or an application. Drivers similarly have to be written treating the hardware and code using them as adversarial. Choice of tools is important.
Conversation
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.
1
2
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
It's not something particularly special about the Linux kernel either. There are two common ways that code execution bugs happen: memory corruption and dynamic code execution. Both are primarily caused by unsafe language design. C and JavaScript are perfect examples of both.
1
Compared to exploitable memory corruption bugs, logic errors exploitable for privilege escalation in the Linux kernel like the Dirty COW bug are extremely rare. There are many orders of magnitudes fewer of those issues and most of the Linux kernel doesn't need memory unsafe code.