In my opinion, if you can't handle a sharp knife, you've got no business being in the kitchen.
It seems that the primary security argument is that N-1 types of issues is better than N. I would argue that the formula is really N - 1 + X, and that we're all focused on the very positive "-1" aspect, but what's the value of X? In other words, what are we trading off by using Rust instead of C in the kernel? Why trade a language which we know the pitfalls of (N) for a language that's potentially adding X pitfalls, and if you're going to argue that Rust has no pitfalls, then to me that's just the kool-aid talking. Realistically, in a new language, you don't know if X is 0, and adding unknown unknowns are precisely the one thing you do not want in a critical piece of software like a kernel.
Furthermore, if OSes need to be secure, and system kernels need to be even more secure, which we all agree on, then all you're doing by advocating against using a stable language with known pitfalls like C is you're lowering the knowledge bar ("hey look I can write kernel code now because I won't introduce memory issues!"), thereby increasing the pool of people who will make logical mistakes out of lack of knowledge, which you will not eliminate with static analysis.
C is not ideal, but it's a practical way to gate the entry to critical software, because
1. C, the language, has a handful of pitfalls, while the software written in any language has orders of magnitude more avenues to exploit it (e.g. access permissions, communication protocols, environmental assumptions, etc).
2. Most of what's difficult in C stems from the realities of dealing with computer architectures. If you can't be bothered to learn the ins and outs of C, you're not fit to write portable low level machine code in a kernel just yet. Just because we can be reasonably sure you won't introduce a memory problem is not sufficient guarantee that you won't do stupid things in the kernel that will cause security problems in a different way.
In the end, I hope I'm wrong about Rust and X is 0, but it seems to me that there's a much better way to ensure we get to an N-1 situation without an X: introduce the borrow checker in C.
Why throw the baby with the bath water? The software industry is very aware by now of the pitfalls of rewriting a project instead of making incremental changes. Bring the memory safety to C. You get 50 years of stability and well documented issues, while still removing a whole class of bugs. Now that would be an absolute win.
> C is not ideal, but it's a practical way to gate the entry to critical software
Aw, yes, the C makes genius programmers meme. I think we've seen very little evidence this is the case. C may be useful to know. Learning C well, because it is difficult, may be useful. These things are speculative, but let's grant them. Unfortunately for you, the proof of the pudding is in the eating? The fact that lots of C code has lots of problems should be an indication that, not only is C not working to solve many modern problems, but that, if C gives us geniuses, we aren't seeing the results.
> introduce the borrow checker in C
You: Just glue on some wings and see if it flies...
Me: That's not how this works! That's not how any of this works!
> I'm only claiming that to be effective at C you must understand computer architecture well.
You still have this problem: We have lots and lots of buggy C code in critical software.
If your claim is to be effective at C you must understand computer architecture well, but unfortunately few are effective at C, because few really understand computer architecture well, and unfortunately we have lots of buggy C code as a result, I'm not sure where you are after that?
Is it possible C hasn't worked as the gate you say it has worked as?
> to be effective at C you must understand computer architecture well.
So long as we are here, I would also quibble with this claim. Knowing loads about C, or more specifically how to prevent C memory safety issues, is perhaps not the best indication one knows anything about network security or cryptography. In fact, we know the reverse is the case. There are plenty of OpenSSL devs who are domain experts in cryptography, who have not proven themselves well adapted to deal with C memory safety issues. Something like Rust sounds perfect for such a use case?
> Right, because the only way to fix problems is to rewrite? Typical inexperienced programmer attitude.
What do you think writing a borrow checker for C would entail?! Do I think it would be a tremendous effort, with little gained? Oh yeah. Do I think we should just use Rust for new software? Yep, because why wait for this C borrow checker? I just don't get it. I think saying "Just use Rust" makes me sensible. "Let's build a borrow checker for C!" is tilting at windmills.
I've programmed in C for 20 years and Rust for 3 and I'm a _much_ better programmer after using Rust. From experience, Rust doesn't make you a lazy programmer, it makes you a much better programmer.
> if you can't handle a sharp knife, you've got no business being in the kitchen.
Sure, and we have driving licenses to make sure people know how to handle a car, but you won't find a race driver who doesn't use seatbelts. Because even the best humans are still human.
Arguing against safety measures because you think you're too skilled to make mistakes is also something to be avoided.
See, you're arguing that Rust is putting seatbelts in racecars, when what is really happening is you're replacing racecars that have no seatbelts with Corollas that have seatbelts.
We agree though that adding memory safety to C would be the equivalent of racecars with seatbelts.
Bit of a stretch to call Rust a Corolla. A lot of the time they both compile to equivalent assembly, and when they don't, the run-time performance is usually very close.
Sure, let's be more accurate. Replace the Corolla with BrandNewCarX. How do you know the engine won't blow up 5 laps into the race? You objectively can't know, because the only way to find out is to perform extensive testing over a long period of time, so as far as I'm concerned whoever is adding Rust into the kernel is making the kernel a testbed for Rust and if it doesn't go as planned, everyone will be paying the price. Since Rust is already in the kernel, I hope all the Rust fans are right about it.
> How do you know the engine won't blow up 5 laps into the race? You objectively can't know, because the only way to find out is to perform extensive testing over a long period of time
Well it's been 6 years since Rust 1.0 was released. And it's had extensive adoption over that time period, including in projects used in vast numbers of devices and services. Firefox runs on Rust, Dropbox runs on Rust, AWS and Cloudflare are both using Rust for core services. Android is shipping Rust. Microsoft is looking at adopting it in Windows. What would count as a long time for you?
If I look at Perl, I'd say about 25 years. People were equally excited about it at the time. It took a few decades for everyone to agree it's a net negative to use it in a project, even though it's still very good at what it does.
> How do you know the engine won't blow up 5 laps into the race?
Lol you do realise this is a dunk on C right? 40 years of experience and we have seen all kinds of stupid shit written by very smart people. Just imagine if the kernel wasn’t written in C and someone wants to introduce C instead.
If professional chefs would constantly maim themself and each other despite extensive occupancy safety training, knives have no place in the hands of a responsible professional.
Using C is the SE equivalent of taping down one button of the two-hand control device of a die cutter.
Kernel hackers are considered the most skilled people in the whole profession. The Linux kernel is one of the most read source code on the planet. The code is audited to death. Much of the research into static code analysis starts there. They have tools available most other people don't. That's what i mean.
If, what ever the happens there, is not up to your standard of professionalism, maybe your standard is unrealistic?
That's not training. That's being thrown in the lake to learn how to swim.
Now you're measuring how many people drowned, and you're saying "let's enforce that everyone use a flotation device, and there will be fewer deaths".
Sure, but there will also be fewer actual swimmers.
To make this more concrete, you can't look at something in aggregate and say "well, we are having this one type of issue, let's just throw everything away and start over".
Yes we must do something, I just don't think that Rust is the best answer. Maybe have an actual safety training. The language is hard. Write a compiler for it, study the spec, simplify the spec, upgrade the language, etc.
Just because you didn't understand my argument doesn't make it in bad faith.
If working on the Linux kernel is the training then you're measuring incidents that occur _during training_.
The whole point of training is to practice and make mistakes _before_ the actual work. Once they're considered experts, you can measure the knife cuts in their work.
Some of the first software I ever wrote was C and then C++. I’ve since worked on Billion+ line Java code bases. I’ve also worked professionally in python, ruby, Type/JavaScript.
When I picked up Rust 15 years into writing software, it taught me to write better code.
Let me repeat that: even after extensive training and professional use of other languages, rustc the compiler taught me to write better code.
If you’re looking for a “we should train people better to not make mistakes” you want people to learn software development from rustc. That training is very transferable back to C and C++ and even Java. Could this automated “teacher” be better? Sure. Could it be less strict? In certain cases sure. Is it the best training program we have? This best I’ve ever seen.
I understand your argument. It works with starting from a massive misrepresentation of what I have said (aka bad faith). Your argument is fatally flawed due to the reason i stated. And that's why there is nothing to be said to the substance, other than what was written and this discussion was and remains over.
>It does not misrepresent what you said, and failure to see that means you did not actually understand it
Oh yes, I do. I do know what i mean and I can see that your quote of it was either extremely unintelligent, something you can by definition not see, or intentionally miss representing and therefore bad faith and therefore something you by definition lie about.
I'm heavily leaning to bad faith, because you never make any attempts to refute arguments anywhere in the whole thread.
So, of course, I'm obviously correct on on this one, so it's good thing either of us wasted any time talking on the substance.
> Most of what's difficult in C stems from the realities of dealing with computer architectures
This is patently untrue. What do malloc and free have to do with computer architecture? Most of C's difficulty is deficiency of the language unrelated to its low level nature.
> What do malloc and free have to do with computer architecture?
You're talking about a library at this point, but ultimately the root cause for allocating memory is because memory is limited, unlike, say CPU time. We do not allocate CPU time explicitly, even though there could be a CPU architecture that could support that, and C would run on it.
> Most of C's difficulty is deficiency of the language unrelated to its low level nature
Do you think that comparing signed and unsigned integers is also unrelated to CPU architectures?
I don't disagree, but this is objectively just hope. The only reason N*7 is huge is because C's adoption. There is nothing to suggest that Rust's N*(bad issue %) is smaller than Cs if it had the same adoption as C. It's fanbase is just trying to increase its presence at the expense of C, to then be able to say "see, we did it, we replaced C and we're better off!", but today, it's equally likely that the outcome is going to be "well, we didn't know about <insert issue here> at the time".
It's not so much hope as it is just me being an expert in security and rust and being able to state that very confidently based on my deep understanding of the relevant fields. I could be wrong in the sense that all things are unknowable and truth doesn't exist, but I think I'm right.
But Rust builds on top of that 50 years of experience, stability and known issues and has solved a lot of them. What does C have to offer that Rust doesn't?
I don't think it's fair to blame the issues that code written in C can have on incompetence.
> But Rust builds on top of that 50 years of experience
Is it? Rewrites only succeed if the original people rewrite the original code, because code is just a serialization of someone's thoughts. That's why it's the people who are the most important assets in a project, not the code. When the original people leave, projects typically fail.
Rust is not being written by the same people who made GCC. It's a different group of people who are trying to do better than C. I wish them best of luck, but to say that they're "building on top of 50 years of experience" is implying that the software they generate is as good as software that has been battle tested for decades on numerous architectures.
> I don't think it's fair to blame the issues that code written in C can have on incompetence.
It's not a blaming game. Code written in C has issues because C has issues, but are you then saying that Rust has no issues? Will never have any issues? What's the bar here?
> It's not a blaming game. Code written in C has issues because C has issues, but are you then saying that Rust has no issues? Will never have any issues? What's the bar here?
For a given value of "issues," that's an accurate portrayal. Statically verified memory safety at the language level is a central part of Rust's mission statement. This is an essential difference from C in how it approaches that problem space. Rust might "have issues" in the sense that compiler bugs are exposed by particular edge cases, or that dealing with certain problems is needlessly difficult or verbose, but reducing everything to "issues" to portray it as equivalent to C is absurd. You might as well say they both have "syntax" and conclude that all code written in Rust is still written in C.
>It's not a blaming game. Code written in C has issues because C has issues, but are you then saying that Rust has no issues? Will never have any issues? What's the bar here?
Rust eliminates an entire class of issues that constitute 70% of C bugs (and largely the most critical bugs at that) by design. Nobody's saying Rust has no issues and never will, but they are saying that this is an objective improvement.
> Nobody's saying Rust has no issues and never will
Ok, so we agree that Rust must have some issues, some of them undiscovered yet. What suggests that Rust won't introduce issues that will be larger than the 70% of issues that it solves with C? Because to me, it just sounds like we can't know so we're being hopeful that we don't run into that situation.
Seatbelts have issues. Some of them undiscovered yet. What suggests that Seatbelts won't introduce issues that will be larger than the 70% of issues that it solves with crashes? Because to me, it just sounds like we can't know so we're being hopeful that we don't run into that situation.
What a ridiculous way to make an argument. Even a silly seatbelt had to wait for about 10 years after being released before it was required to be in cars. Maybe write a few other kernels in Rust before using it in billions of devices? But no, shoot straight for Linux because "C bad, Rust good".
> In my opinion, if you can't handle a sharp knife, you've got no business being in the kitchen.
Great! So we agree that no person should have any business writing C. It's proven time and time again that even the best of the best C developers can't write safe C code.
I do wish that rust had stayed a simpler language, but I do think it started about as simple as you could while having a borrow checker. The fact that c2rust transpilers (for unsafe rust) popped up so soon after its release years ago, is good evidence that at least a subset of rust is only slightly syntactically different to c. Even if you only had to add lifetime notations to c, the amount of code that would have to be rewritten is vast. And a lot of the extra stiff in rust is to lower the performance cost of safety. Like avoiding runtime bounds checking or unnecessary copies while keeping the benefits. Tl;dr I don't think c with a borrow checker and bounds checking is what we want performance wise. I think that is pretty much carbon.
If you want robust and well known, pick ada/spark. That language and it's culture is all about security and has been for decades. It also doesn't have quite the performance of c and rust.
And about the sharp knife... I have worked embedded c++ for decades now, some safety critical where we inspected the assembly generated and verified 100% code and branch coverage, on the assembly. I have made one memory safety error that escaped test in those years. That has been found yet...
I'm not in the kernel culture so I don't know. But it doesn't seem like it values things like static analysis, unit test coverage, san builds etc. It seems from the outside they are simply relying on their knife skills instead of measuring the quality of their work. Microsoft and Google both say over 70% of their exploits have come from memory safety errors. So it isnt M-1 + x. It is M0.3 + X. And rust isn't super new, so we have some ideas about X from early production use in firefox and dropbox. And we have an idea about how many knife users never cut themselves given even just the recent history like beacown.
Thank you for a thoughtful response. I do hope I am wrong and we as an industry end up in a better spot overall, though I suspect Rust is not the language that's going to get us there. Most accounts I've read or conversations I've had with people who used Rust in large projects boil down to "it's not worth fighting the language", so my general impression is that Rust is the Perl of this decade, and I'm excited for the next generation of languages after Rust, because they will have to consider the safety aspect.
In the three projects I've been on that used rust, there really hasn't been much of that. Mostly I have been surprised at how high level it feels even with all the control. I do think the type of project makes a difference. I have been doing mostly dsp type stuff. And coming at it from the mindset of ocaml or modern c++ (value semantics etc.) Vs the ansi c mindset I used on TI DSPs back in the day makes a big difference. And that is the problem with bolting on the safety. The borrow checker doesn't just find mistakes, it also forces you to code in a different style so it can reliabily do so. Not necessarily a better style, but not slower either, a different and easier style for it to check. The syntax could have been closer to c, but the style would end up being similar. As far as all the complexity getting added, ferrocene or someone like them may end up making a safety critical subset like spark is to ada, that is simpler to do formal verification on. That would be a good subset for drivers and kernels.
It seems that the primary security argument is that N-1 types of issues is better than N. I would argue that the formula is really N - 1 + X, and that we're all focused on the very positive "-1" aspect, but what's the value of X? In other words, what are we trading off by using Rust instead of C in the kernel? Why trade a language which we know the pitfalls of (N) for a language that's potentially adding X pitfalls, and if you're going to argue that Rust has no pitfalls, then to me that's just the kool-aid talking. Realistically, in a new language, you don't know if X is 0, and adding unknown unknowns are precisely the one thing you do not want in a critical piece of software like a kernel.
Furthermore, if OSes need to be secure, and system kernels need to be even more secure, which we all agree on, then all you're doing by advocating against using a stable language with known pitfalls like C is you're lowering the knowledge bar ("hey look I can write kernel code now because I won't introduce memory issues!"), thereby increasing the pool of people who will make logical mistakes out of lack of knowledge, which you will not eliminate with static analysis.
C is not ideal, but it's a practical way to gate the entry to critical software, because
1. C, the language, has a handful of pitfalls, while the software written in any language has orders of magnitude more avenues to exploit it (e.g. access permissions, communication protocols, environmental assumptions, etc).
2. Most of what's difficult in C stems from the realities of dealing with computer architectures. If you can't be bothered to learn the ins and outs of C, you're not fit to write portable low level machine code in a kernel just yet. Just because we can be reasonably sure you won't introduce a memory problem is not sufficient guarantee that you won't do stupid things in the kernel that will cause security problems in a different way.
In the end, I hope I'm wrong about Rust and X is 0, but it seems to me that there's a much better way to ensure we get to an N-1 situation without an X: introduce the borrow checker in C.
Why throw the baby with the bath water? The software industry is very aware by now of the pitfalls of rewriting a project instead of making incremental changes. Bring the memory safety to C. You get 50 years of stability and well documented issues, while still removing a whole class of bugs. Now that would be an absolute win.