The "breaking interface contracts is a security enhancement" view is a very very harmful one. It's the opposite.
-
-
Replying to @RichFelker @DanielMicay and
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 reply 0 retweets 0 likes -
Replying to @filpizlo @RichFelker and
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 reply 1 retweet 6 likes -
Replying to @DanielMicay @filpizlo and
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 reply 0 retweets 6 likes -
Replying to @DanielMicay @filpizlo and
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 reply 0 retweets 2 likes -
Replying to @DanielMicay @filpizlo and
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 reply 0 retweets 2 likes -
Replying to @vyodaiken @RichFelker and
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 reply 0 retweets 4 likes -
Replying to @DanielMicay @vyodaiken and
Try reading the overview in https://events.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf …. 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 replies 0 retweets 6 likes -
Replying to @DanielMicay @vyodaiken and
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
4 replies 1 retweet 21 likes
I think I could write a memory safe fizzbuzz in C
-
-
Replying to @pcwalton @johnregehr and
I once tried to write a C program doing *nothing*, still UB.
1 reply 0 retweets 2 likes -
???
1 reply 0 retweets 0 likes - 7 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.