Conversation

The expectations of software robustness and security have increased a lot, and it's simply not realistic to achieve it while using unsafe tools making it much more difficult to write safe code. Writing something complex like an safe ext4 implementation is C is not very realistic.
1
5
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.
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
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
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.