7 ms·

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

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.

Cthulhu_ 4y ago
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.
- optymizer 4y ago
  > 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?
  - entropicdrifter 4y ago
    >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.
    - optymizer 4y ago
      > 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.
eklavya 4y ago
I don’t know how many severed toes before the “elite chefs” realise they are not that special.
- optymizer 4y ago
  Right, because in Rust, we'll all be singing kumbaya.
  - 1ris 4y ago
    The non-cynical answer is: Yes, we will be doing so much more. https://blog.ploeh.dk/2019/07/01/yes-silver-bullet/ https://blog.ploeh.dk/2019/07/01/yes-silver-bullet/
1ris 4y ago
To reuse your metaphor: 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.
- optymizer 4y ago
  That's a strawman if I've ever seen one. What's the "extensive occupancy safety training" for C?
  - 1ris 4y ago
    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?
    - optymizer 4y ago
      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.
      - 1ris 4y ago
        "Training" and "being the (allergy) the most skilled" have no connection to you? You can't be serious. This is mincing words and a bad-faith argument. I consider this discussion pointless and will not continue.
sanxiyn 4y ago
> 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.
- optymizer 4y ago
  > This is patently untrue. proof or gtfo. > 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?
alpaca128 4y ago
> 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.
- optymizer 4y ago
  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.
  - pkulak 4y ago
    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.
    - optymizer 4y ago
      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.
      - nicoburns 4y ago
        > 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?
galangalalgol 4y ago
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. It is time to start the incremental change.
- optymizer 4y ago
  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.
  - 4y ago
mustache_kimono 4y ago
> 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!
- optymizer 4y ago
  Being sarcastic does not make you correct. > Aw, yes, the C makes genius programmers meme Not claiming that. I'm only claiming that to be effective at C you must understand computer architecture well. You did set up a strawman here. > if C makes gives us geniuses, we aren't seeing the results Perfect strawman execution. > Just glue on some wings and see if it flies... Right, because the only way to fix problems is to rewrite? Typical inexperienced programmer attitude.
  - mustache_kimono 4y ago
    > 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.
insanitybit 4y ago
It's not N - 1 + X. It's more like N - (N * .7) + X. And X is way smaller than N*.7 (it's ~0). Anyway, in terms of bug severity that 70% is also way worse than the other 30%. The rest of your post is all just silly "people should code better" and isn't worth responding to.
- optymizer 4y ago
  > And X is way smaller than N*.7 (it's ~0) 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".
  - insanitybit 4y ago
    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.
msla 4y ago
Do you have any arguments which couldn't also be used to prove C doesn't belong in kernel programming, and we must use assembly?
- optymizer 4y ago
  Yes, C is portable and assembly is not.
  - msla 4y ago
    I didn't see you mention portability in the post I responded to, though.
rowanG077 4y ago
> 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.

Cthulhu_ 4y ago

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.

optymizer 4y ago
> 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?
- entropicdrifter 4y ago
  >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.
  - optymizer 4y ago
    > 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.

eklavya 4y ago

I don’t know how many severed toes before the “elite chefs” realise they are not that special.

optymizer 4y ago
Right, because in Rust, we'll all be singing kumbaya.
- 1ris 4y ago
  The non-cynical answer is: Yes, we will be doing so much more. https://blog.ploeh.dk/2019/07/01/yes-silver-bullet/ https://blog.ploeh.dk/2019/07/01/yes-silver-bullet/

1ris 4y ago

To reuse your metaphor: 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.

optymizer 4y ago
That's a strawman if I've ever seen one. What's the "extensive occupancy safety training" for C?
- 1ris 4y ago
  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?
  - optymizer 4y ago
    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.
    - 1ris 4y ago
      "Training" and "being the (allergy) the most skilled" have no connection to you? You can't be serious. This is mincing words and a bad-faith argument. I consider this discussion pointless and will not continue.

sanxiyn 4y ago

> 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.

optymizer 4y ago
> This is patently untrue. proof or gtfo. > 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?

alpaca128 4y ago

> 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.

optymizer 4y ago
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.
- pkulak 4y ago
  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.
  - optymizer 4y ago
    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.
    - nicoburns 4y ago
      > 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?

galangalalgol 4y ago

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. It is time to start the incremental change.

optymizer 4y ago
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.
- 4y ago

mustache_kimono 4y ago

> 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!

optymizer 4y ago
Being sarcastic does not make you correct. > Aw, yes, the C makes genius programmers meme Not claiming that. I'm only claiming that to be effective at C you must understand computer architecture well. You did set up a strawman here. > if C makes gives us geniuses, we aren't seeing the results Perfect strawman execution. > Just glue on some wings and see if it flies... Right, because the only way to fix problems is to rewrite? Typical inexperienced programmer attitude.
- mustache_kimono 4y ago
  > 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.

insanitybit 4y ago

It's not N - 1 + X. It's more like N - (N * .7) + X. And X is way smaller than N*.7 (it's ~0). Anyway, in terms of bug severity that 70% is also way worse than the other 30%. The rest of your post is all just silly "people should code better" and isn't worth responding to.

optymizer 4y ago
> And X is way smaller than N*.7 (it's ~0) 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".
- insanitybit 4y ago
  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.

msla 4y ago

Do you have any arguments which couldn't also be used to prove C doesn't belong in kernel programming, and we must use assembly?

optymizer 4y ago
Yes, C is portable and assembly is not.
- msla 4y ago
  I didn't see you mention portability in the post I responded to, though.

rowanG077 4y ago

> 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.