No, that's not what I've been saying. I think it would be a serious regression to break compatibility with safe implementations by making it correct to be incompatible with them. You want to massively roll back safety and security, especially if you want to remove it by default.
Conversation
It's not a big deal if the spec says that overflow wraps. Anyway, a most useful version of trap-on-overflow would do this for unsigned, which isn't allowed in the current spec. It's fine to have security technologies that create interesting new behaviors.
2
The "breaking interface contracts is a security enhancement" view is a very very harmful one. It's the opposite.
3
7
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.
1
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
This Tweet was deleted by the Tweet author. Learn more
Once again, you're making strawman arguments and completely misrepresenting what I said. Let me just quote it for you: twitter.com/DanielMicay/st. This is about minimizing the trusted computing base. The amount of code that needs to do those things in a FS driver is very small.
Quote Tweet
Replying to @filpizlo @RichFelker and 4 others
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
There are certainly widely used examples of microkernels and memory safe languages. Every single smartphone has multiple microkernel-based operating systems running on it, and there's ever increasing adoption of memory safe language in the main OS too, including for systems code.
1
iOS 11 moved to a userspace network stack. Both Android and iOS have extensive usage of memory safe languages, including for systems code. Drivers are becoming part of that. Google has their own Linux userspace network stack, already used by Fuchsia:
github.com/google/netstack
iOS has been adopting Swift for various core system services and libraries. Android mostly uses Java above the kernel / driver layer (system_server). Their userspace network stack is Go. None of these is a low-level language like Rust, but most systems code doesn't need one.
1
There is no particular reason that components like init, vold, etc. could not be written in a high-level language like Go without manual memory management. Kernel components and native libraries would need a language like Rust, but most code doesn't need a low-level language.