Systems code should be written in something higher level than assembler but lower level than the symbolic execution system that C claims to provide currently. “Just use assembly” or “just use a type safe language” aren’t useful answers.
Conversation
Systems code benefits from memory and type safety even more than most other code because it's often in a position of trust and privilege. Using a language where unsafety can be contained and quickly wrapped into safe APIs is certainly useful advice for newly written systems code.
1
2
6
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
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
This Tweet was deleted by the Tweet author. Learn more
Feel free to look through the hundreds of ext4 CVEs and consider reading what I pointed you towards:
events.linuxfoundation.org/wp-content/upl
kroah.com/log/blog/2018/
2
FWIW, I've never considered ext4 as a candidate for removable media. If your threat model includes physical alteration of internal drives you have bigger problems than ext4 CVEs. If your udev scripts auto-mount external ext4, your distro integrators are incompetent.
1
1
Systems using verified boot include alteration of the internal drive / filesystem contents in their threat model. It's extremely important for embedded systems. They shouldn't have any unverified code at all, and internal state should be as minimal / untrusted as possible.
The internal filesystem for state outside of the verified OS is part of the attack surface for verified boot. An attacker that compromises the system and wants to persist access needs to either defeat the tiny attack surface of verification or exploit the OS via persistent state.