The beginning of the end of use-after-free, buffer overflows, stack smashers, et al will be when we as a community finally accept that C is a terrible language, impossible for ordinary humans to reason about, and must be abandoned. Only when we begin to accept that truth will we all get serious about moving away from it.
For many years the response has been that "C is fine" or some variant of "humans will be better programmers in the future" both of which are demonstrably false.
No one questions the wisdom of paramtaraizing SQL. No one questions the wisdom of not writing your own crypto. Yet despite the mountains of evidence, wasting billions (yes BILLIONS) of man-hours and dollars, and even lives lost there is still resistance to the idea that C needs to die ASAP.
So as long as there are posts like yours our job of educating and persuading isn't finished and that's extremely important if we have a hope of actually making this desperately needed change.
If you still doubt let me go ahead and make a prediction: before the end of the year there will be another RCE exploit in the Linux kernel discovered and a different one will be written, code-reviewed, and committed but not discovered until later (but within 5 years). I'm happy to put $1,000 on this wager.
1) All the complaints you have apply equally well to assembly language, yet assembly language is all that the CPU understands. Somebody always has to deal with the low level complexity of writing the foundational software constructs necessary to build safe environments and C is still the most natural mapping to varied assembly languages that we have.
2) Nothing else will fit for many embedded systems. Your choices are C or assembly language. What safe environment/language are you going to fit into a microcontroller with 1kB of RAM?
(And, yes, maybe Rust or one of the other proposed system language replacements will be better than C someday, but that someday isn't today.)
No, machine code is all that the CPU understands. Assembly language is source code that gets converted into machine code by an assembler.
The problem is this line of reasoning doesn't generally hold up when applied to C codebases (because in practice statistics catches up with you eventually) and C code generators, in effect, happen to contain an admittedly small but rather obfuscated C codebase.
Moreover, you must always include such checks - manually crashing on e.g. null pointers even if you'd be entirely satisfied with a segfault - just to avoid the optimizer potentially going apeshit on your code. Which can have... poor effects on program performance.
So, then, why do you think that "We need to rewrite everything in Rust" isn't doing something productive? I've been a C++ and C developer for a long time and have been waiting for some safer language that lets me do what I've been doing in those languages. Knowing that Rust was a realistic option was what inspired me to learn it and write new things in it. If that happens at scale, that's how we actually get things written in a memory-safe language.
The Linux kernel didn't get written because people on a forum said "we need to write a complete open source reimplementation of the UNIX kernel," but because Torvalds just went ahead and wrote it. Most things in F/OSS work that way.
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready.
https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RR...
It would be much easier to submit patches to slowly upgrade the kernel to a memory safe language, but that would require a lot of political savvy to push through, also making it an unlikely path to be taken. Ultimately, you'd have to convince Linus of the merits, and we all know how much he likes complex languages.
For one, Rust is a different language from the other memory-safe languages that have existed in the past, and in fact incorporates a lot of research in programming languages that didn't exist when Ada was designed. But even if that weren't true, one thing that's changed since the past is we now are slowly understanding how difficult it is to write secure software in C, and how important it is to write secure software. When Unix was first designed we (the entire programming community) didn't know about a lot of security issues, and the lack of Internet meant that it was less important to defend against them. It is probably much more worth rewriting our tools in Ada today than it was ten or twenty or thirty years ago.
IMO, because it's harder to break the rules. Sometimes the rules just need to be broken. There was a recent article about someone attempting to interface with OpenGL in Rust a month or so ago, and it discussed how they ended up giving up, since the things they needed to do didn't mesh well with how Rust expected programs to be written. If interfacing with a driver is so hard, how will interfacing with hardware be easier?
Programming for hardware requires a lot of breaking and bending the rules. How can being memory safe help when you're creating memory spaces as most software knows of it?
Performance is King, low memory overhead is Queen. Even rust can't take those thrones away from C. Not yet, at least. Perhaps not ever (I expect that C++ would have done it, were it possible for a language with the complexity of Rust).
> If interfacing with a driver is so hard, how will interfacing with
> hardware be easier?
I'm still a noob at this kind of thing myself, but I recently wrote a (tiny) driver for a memory-mapped device. My first iteration had tons of unsafe code. My second iteration had three lines of unsafe code. My latest iteration has zero unsafe code, though you do need one call to an unsafe function outside of it in order to construct it. (to create a slice from the raw memory location that's mapped.)
That is, of course, pretty much the simplest possible case. But I believe the pattern will hold, over time, as people learn how to do it.
> Even rust can't take those thrones away from C.
Once there's a firm consensus that it's time to move away from C we'll probably stop talking about it. But that consensus has to develop through discussion and argument here and elsewhere (and if you look at the conversations now compared to a year or two ago, I'd say we've made a lot of progress). If you don't believe there's value in talking about technical issues then what are you even doing here?
You're welcome to post, of course. I'd just rather you not. There's no sense preaching to the choir.
A tree thread is good for discovery but not so good for reaching a conclusion/consensus. Flat/linear thread should be used instead.
Yes ..
Does this vulnerability work only on a particular architecture?
This is why seL4 does not support internal SMP. You can run an instance per core and assign it a separate memory space like to a VM though.
The advocates of these alternatives aren't creating this situation. The unavoidable fact is that our traditional tools have a propensity to propagate bugs that are fabulously difficult to discover. That's one of the lessons of nearly a half century of C. New tools are emerging that solve this problem and their advocates have every reason to say so.
Another lesson C teaches us through its popularity and longevity is that performance will always be critical for systems code; there will never be a day when we can squander cycles and RAM on garbage collectors and reference counts and indirections and all the other bookkeeping and abstractions inherent to so many languages that have utterly failed to displace C for systems programming.
I don't know what the future looks like. Maybe it's Rust. Maybe Linus will get fed up and invent a better language in 4 days. Maybe someone will create an AI system that can spot this sort of bug before it ever gets checked in. All I know for sure is that the current situation is intolerable and yelling at people to shut up about it won't work.
Every program written in Go is one program less written in C.
...
Make sure there's less C code around.
BTW the kernel is full of reference counts.
I think the OP is pointing to languages like Swift/Objective-C where reference counts are used even if you don't really need them, not that ever reference counting anything is a lazy abstraction.
Once your language is at that point, then start building up your arguments to convince Linus and the majority of the core kernel developers that your language is the right choice for continued development.
Until these occur, it's all just pointless speculation.
The biggest cost is not them, it's every other C programmer, every other company, the whole industry. It's unrealistic to even think that any significant part of them is going to invest resources into another language just to gain memory safety.
We've all heard it already, we all know what you'll say. So skip the smug post, and go do something productive. Like writing a really cool piece of new code, or fixing a use-after-free, or posting something more insightful, or inventing a new type of shoelace that doesn't come untied until you want it to.