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.
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
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
if I were someone like I'd be trying like hell to get as many of these drivers as possible moved into user mode, since "rewrite 'em in a safe language" isn't viable in the short or medium term
3
1
7
Would be nice to see something like developer.android.com/things/sdk/dri for all the miscellaneous drivers in Android itself. Some drivers are harder than others. Also need to make sure IOMMU is set up correctly or drivers can bypass any isolation by using DMA but that matters either way.
1
Also, it's not so much that they need to be *rewritten* in a memory safe language but rather than new drivers written in a memory unsafe language should be banned. Qualcomm and other vendors are constantly rewriting their drivers / remaking the entire platform again and again.
It's a big part of why so few of their drivers are upstream. Android Things took the approach of requiring that all downstream drivers are written as userspace drivers in a memory safe language. It's for miscellaneous peripherals, etc. so it's not very ambitious but it's great.
1