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
It would be hard enough to make a microkernel secure if it was 50k lines of Rust with only 4k lines of unsafe code with potential memory corruption, let alone millions of lines of trusted C full of memory corruption from all kinds of trivial mistakes / oversights. It's a joke.
1
4
17
Just want to point out that seL4 is about 10K lines of C and is formally verified to use no UB, no OOB array access, no crashes, etc... Not trying to defend C but there are ways to make anything safe if you care enough. The problem is people don’t care.
3
1
8
Sure, but at that point it's not C. It's a subset of C that was verified via proofs. Those proofs are an extension to the language. Similarly, you can define a general purpose subset of C with annotations for ownership, lifetimes, etc. letting you write memory safe code.
You end up with something that looks a lot like Rust. You can't compile existing C codebases with an implementation of it. They have to be specifically written for it with the annotations, but they don't need complex proofs, unless they want to prove more than memory safety.
2
And by looks a lot like Rust, I mean it has a lot of the same things enforced via the supplementary type system, but it will be far less usable / ergonomic and way more verbose. Can also take a 2-3x performance hit + substantial memory increase and a memory safe C implementation.
1
Show replies
Sure it's C. You can do a lot of idiotic things with C. You can do a lot of idiotic things with most languages. You shouldn't do them.
1
There are ways to write C that are both completely idiomatic and amenable to static analysis, correctness proofs, etc. Doing so does not make it a weird and esoteric language that no longer resembles C. It makes it a much more readable and friendly language.
2
1
Show replies