5 ms·

> I cannot consistently write safe C/C++ code. I'm not ashamed of that; I don't know anyone else who can. With respect, two mistaken beliefs: 1: Only a few p

> I cannot consistently write safe C/C++ code. I'm not ashamed of that; I don't know anyone else who can. With respect, two mistaken beliefs: 1: Only a few programmers can write safe code. 2: One will naturally encounter such programmers in the course of a prestigious career working for a high-profile web browser company. But mediocre programmers consistently write safe C/C++ code, every day. They do it in the context of aviation, automotive, etc. They do it as part of a much larger safety process, that is designed to be robust against faults at all levels, from design through development through manufacturing through end-user servicing. Software development is but one facet, and compliance to MISRA, ISO 26262, etc is only the start. Get to know them, and see how safe C/C++ code is actually written!

hsjoberg 9y ago
In automotive, code is very rarely written it is mostly generated from simulink models. But yes software for aviation automotive, nuclear and medicine equipment are running safe C code. It is mostly generated from a model not necessarily simulink. The generated code usually have rules for the code so no global parameters, no pointers etc can be used.
- millstone 9y ago
  That's a great point. Often you need to run your system in simulation via a model. Generating the code directly from the model is one way to prove that your system matches the simulation. Of course the modeling tools speak mostly C. This illustrates how C's weaknesses are mitigated in practice, and how much work prospective C-replacements must do to be competitive.
  - hsjoberg 9y ago
    Yes and the code/models go through extensive testing. Everyone in the industry knows that a callback because of faulty software will cost an insane amount of money. This is changing a bit since more and more work is going towards over-the-air update.
  - kbenson 9y ago
    > This illustrates how C's weaknesses are mitigated in practice Except there's likely a false sense of security in how well those mitigations work. Part of the problem with C is that later optimizations by the compiler can yield insecure code at a later date because of undefined behavior and compiler optimization techniques that take advantage of it. In other words, if your generated code takes advantage of any undefined behavior, there's no guarantee that the same code compiler on the same compiler with the same flags but with a different/newer version of that compiler will yield bug free code in both cases. Can those models produce C code with absolutely no undefined behavior? Maybe? When's the last time someone did a close look at exactly what they were generating? Did they make sure to look again when the underlying architecture changed (even from one version of ARM to another...)? See the somewhat recent Cap'N'Proto remote vuln[1] submission for a modern case of this, and a good discussion of the problem in detail. 1: https://news.ycombinator.com/item?id=14163111 https://news.ycombinator.com/item?id=14163111
    - hsjoberg 9y ago
      Yeah testing needs to be done with compiled code on target card otherwise you can't be sure it works. Usually compiling code is super strict no further optimization then the standard can be used etc. Only specific cards and compilers are "trusted" to use.
SeanDav 9y ago
I doubt writing safe C/C++ code is as straightforward as the Parent post claims, otherwise people at Microsoft, Google and Mozilla must clearly be doing something wrong. They have the budget, the skills and the motivation to always produce safe code, yet their products all contain serious bugs, which would not occur if all their C/C++ code was "safe".
- millstone 9y ago
  We know how to write C/C++ code appropriate for safety-critical components, it's just very expensive and slow to develop. Any company who set out to write a social networking system at an ASIL D level (say) would be rapidly out-competed. ISO 26262 recognizes this, which is why different components in your car are developed to different integrity levels. No lives are lost if Firefox misrenders a JPEG, so it has a low rating permitting lax development practices. That said, with crypto-ransomware and other cybersecurity hazards, it's well past time for software development to take some pages from the safety engineering book. STPA-Sec is one example of an attempt at this.
  - adrianN 9y ago
    I've read those safety standards and I disagree. They don't prescribe much that isn't standard practice. The only thing they require that isn't commonly done is very extensive testing or formal verification. They high expensive mostly comes from proving compliance to external auditors. You could have 90% of the results with 10% of the work by just testing your software very thoroughly but not producing all the documentation required to prove compliance to the standard. SQLite for example is at least as rigorously developed as SIL 4 software.
kbenson 9y ago
> But mediocre programmers consistently write safe C/C++ code, every day. I think perhaps you and the author have different interpretations of "consistently". You might also differ on whether "safe code" is safe just because it hasn't failed (or been reported!) yet under current inputs. > They do it as part of a much larger safety process, that is designed to be robust against faults at all levels So, since we seem to have moderately good success through voluntary adherence to strict guidelines, we shouldn't automate away the possibility of some of these errors entirely when possible? What are the benefits of that approach? Edit: I think you can safely ignore my original comment. It's obvious now that I was interpreting it oddly by conflating it with some other comments and positions in this thread. Your comment does a good job of explaining how it is possible to write safe C/C++ consistently (although I might quibble by saying that it is only achieved by ignoring portions of the languages, thus confining you to a dialect of those languages, which is a point in itself to be discussed). I would delete the original portion, but I believe in acknowledging mistakes rather than hiding them, thus this correction.
- _nalply 9y ago
  OK. I also made mistakes and I understand you. However you should perhaps move the disclaimer to the top of your post, so people have a chance to abort reading your post.
  - kbenson 9y ago
    I could, but in this case I think it's more powerful as a reminder to be careful about interpretation for those that are in agreement with the original statement and then come upon the revision. That it might initially reinforce someone's similar mistake to then confront them with the fallibility of human nature appeals to me.
pjmlp 9y ago
MISRA, ISO 26262 make C feel like Ada with curly brackets, it is so constrained that it actually isn't C any longer. > Get to know them, and see how safe C/C++ code is actually written! I know them and also know that only in the context of high integrity computing are companies willing to pay for such processes, because they are cheaper than closing down the company if humans are killed due to a memory corruption error. Good luck imposing such process in industries where human lives aren't at risk. If companies could be sued by bad software quality, it would be another matter.
skrebbel 9y ago
That's a different kind of safe than the OP means. You mean "does not crash, produces the right results", he means "can'te be hacked". A non-networked engine control unit is super hard to hack by simple virtue of being unreachable from the internet. I bet if you run a fuzzer against your perfectly safe aviation code you'd find lots and lots of security issues. But those issues aren't important.
- noir_lord 9y ago
  > I bet if you run a fuzzer against your perfectly safe aviation code you'd find lots and lots of security issues. But those issues aren't important. As long as no one does something silly a decade from now when it comes to the networking on the plane/ship/factory.
  - adrianN 9y ago
    The "Industrial Internet of Things" is currently a very hot buzzword. I fear the worst.
- millstone 9y ago
  I don't follow your point. Software has to be prepared to deal with abnormal inputs, whether those are from a malfunctioning sensor, or an attacker on the same WiFi hotspot. Safety is a property of a system and the context in which it's used. Safety is not a property of its individual components, including its code. If your CPU's GPIOs were directly accessible through the Internet, your computer would be hacked too; does that mean your system is not safe?
  - adrianN 9y ago
    A malfunctioning sensor is very unlikely to prepare a specially crafted input that exploits a bug. An intelligent adversary is something completely different. Your claim that MISRA and standards for safety critical software also provide security against targeted attacks does not really follow.
- kbenson 9y ago
sytelus 9y ago
The aviation/automotive code doesn't get deployed on to millions of personal computers of tons varieties and locals and probed by professional hackers endlessly for vulnerabilities. The aviation/automotive code runs in very well defined environment, almost completely locked down and unavailable for user interaction for most parts. Its unfair to compare them with open ended applications like browsers which has to handle tons of formats, extensibility APIs and very complex and often incomplete protocols with numerous versions and compatibility issues. Two very different worlds.
- kbenson 9y ago
  The problem with security through obscurity (which is what this approach is analogous to), is that obscurity can't really be guaranteed, and you usually can't be sure exactly how your code will be implemented in the future. Here's some somewhat recent examples of that, where a Jeep was remotely controlled because the system's bus wasn't correctly segregated[1], and where an avionics messaging channel may be exploitable to send bogus information between planes and air traffic control[2]. 1: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig... 2: https://defcon.org/images/defcon-22/dc-22-presentations/Polstra/DEFCON-22-Phil-Polstra-Cyber-hijacking-Airplanes-Truth-or-Fiction-Updated.pdf https://defcon.org/images/defcon-22/dc-22-presentations/Pols...
adrianN 9y ago
A lot of the "safe" code written in embedded systems is only safe because the inputs are already safe. You don't get to exploit any bugs in a parser when the messages are created by a system under your control. Cars, planes, trains, medical devices, etc. don't really have interfaces to the outside world that can easily be exploited. Those interfaces they have get exploited. See for example https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig...
simias 9y ago
It's true but I'd argue that they're not really "coding" in C or C++ in the way it's commonly accepted in those critical environments. It's more like a "fill the blanks" exercise where everything is split in tiny functions that are thoroughly specified and tested. Effectively 90% of the dev work is done higher level by the various specification and constraint tools. All that's left to the C coder is the most menial of tasks, "dumbly" implementing the algorithm exactly as spelled out in the spec. And even then every piece of code will be checked multiple times before being validated. There's simply not enough leeway for the coder to make a significant mistake, or at least that's how it's supposed to be. Clearly generalizing this approach to all of software development seems impractical. It's extremely costly and makes it hard to make quick changes to the codebase. For non-critical applications it's probably overkill. There's room for a compromise I think. The problem with C IMO is that on its own it's highly and uselessly unsafe. At the time of its conception it was probably impractical to write a compiler that would check things like lifetimes statically because it would've made compile times unbearably long but nowadays it's not really a problem anymore. Do you really encourage people to write critical code in a language where the compiler gladly compiles codes like this, without even a warning (tested with -Wall -Wextra on gcc 6.4)? int test(void) { int i[3] = {0}; return i[8]; } And the following code only with a non-critical warning: int *test(void) { int i; return &i; } Isn't the entire hacker mantra to have the computer work for you? I'd prefer if my compiler was actively trying to detect my mistakes instead of dumbly spewing machine code.
- clarry 9y ago
  > int test(void) { > int i[3] = {0}; > > return i[8]; > } clang will warn. gcc will warn with -Wall -O2. > int *test(void) { > int i; > > return &i; > } You are free to use -Werror. I encourage people to learn to use their tools first. Instead of whining about the language when it is their tools that do not do what you want by default.
  - simias 9y ago
    Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Still only a warning though. And I don't think -Werror is a good general purpose solution because it's too broad. Many warnings are just fine as warnings and for big projects that build on several operating systems using a lot of 3rd party libraries there's bound to be a few harmless warnings here and there. For instance the perfectly valid "if (a && b || c)" will warn with -Wall. I guess I'd want a "-Werror-on-serious-warning". That's why sane defaults matter, if those warnings were errors to begin with they would be fixed upstream, if instead you decide unilaterally to turn on -Werror for your code then you're screwed if your third party headers weren't as stringent with their coding rules.

hsjoberg 9y ago

In automotive, code is very rarely written it is mostly generated from simulink models. But yes software for aviation automotive, nuclear and medicine equipment are running safe C code. It is mostly generated from a model not necessarily simulink. The generated code usually have rules for the code so no global parameters, no pointers etc can be used.

millstone 9y ago
That's a great point. Often you need to run your system in simulation via a model. Generating the code directly from the model is one way to prove that your system matches the simulation. Of course the modeling tools speak mostly C. This illustrates how C's weaknesses are mitigated in practice, and how much work prospective C-replacements must do to be competitive.
- hsjoberg 9y ago
  Yes and the code/models go through extensive testing. Everyone in the industry knows that a callback because of faulty software will cost an insane amount of money. This is changing a bit since more and more work is going towards over-the-air update.
- kbenson 9y ago
  > This illustrates how C's weaknesses are mitigated in practice Except there's likely a false sense of security in how well those mitigations work. Part of the problem with C is that later optimizations by the compiler can yield insecure code at a later date because of undefined behavior and compiler optimization techniques that take advantage of it. In other words, if your generated code takes advantage of any undefined behavior, there's no guarantee that the same code compiler on the same compiler with the same flags but with a different/newer version of that compiler will yield bug free code in both cases. Can those models produce C code with absolutely no undefined behavior? Maybe? When's the last time someone did a close look at exactly what they were generating? Did they make sure to look again when the underlying architecture changed (even from one version of ARM to another...)? See the somewhat recent Cap'N'Proto remote vuln[1] submission for a modern case of this, and a good discussion of the problem in detail. 1: https://news.ycombinator.com/item?id=14163111 https://news.ycombinator.com/item?id=14163111
  - hsjoberg 9y ago
    Yeah testing needs to be done with compiled code on target card otherwise you can't be sure it works. Usually compiling code is super strict no further optimization then the standard can be used etc. Only specific cards and compilers are "trusted" to use.

SeanDav 9y ago

I doubt writing safe C/C++ code is as straightforward as the Parent post claims, otherwise people at Microsoft, Google and Mozilla must clearly be doing something wrong. They have the budget, the skills and the motivation to always produce safe code, yet their products all contain serious bugs, which would not occur if all their C/C++ code was "safe".

millstone 9y ago
We know how to write C/C++ code appropriate for safety-critical components, it's just very expensive and slow to develop. Any company who set out to write a social networking system at an ASIL D level (say) would be rapidly out-competed. ISO 26262 recognizes this, which is why different components in your car are developed to different integrity levels. No lives are lost if Firefox misrenders a JPEG, so it has a low rating permitting lax development practices. That said, with crypto-ransomware and other cybersecurity hazards, it's well past time for software development to take some pages from the safety engineering book. STPA-Sec is one example of an attempt at this.
- adrianN 9y ago
  I've read those safety standards and I disagree. They don't prescribe much that isn't standard practice. The only thing they require that isn't commonly done is very extensive testing or formal verification. They high expensive mostly comes from proving compliance to external auditors. You could have 90% of the results with 10% of the work by just testing your software very thoroughly but not producing all the documentation required to prove compliance to the standard. SQLite for example is at least as rigorously developed as SIL 4 software.

kbenson 9y ago

> But mediocre programmers consistently write safe C/C++ code, every day. I think perhaps you and the author have different interpretations of "consistently". You might also differ on whether "safe code" is safe just because it hasn't failed (or been reported!) yet under current inputs. > They do it as part of a much larger safety process, that is designed to be robust against faults at all levels So, since we seem to have moderately good success through voluntary adherence to strict guidelines, we shouldn't automate away the possibility of some of these errors entirely when possible? What are the benefits of that approach? Edit: I think you can safely ignore my original comment. It's obvious now that I was interpreting it oddly by conflating it with some other comments and positions in this thread. Your comment does a good job of explaining how it is possible to write safe C/C++ consistently (although I might quibble by saying that it is only achieved by ignoring portions of the languages, thus confining you to a dialect of those languages, which is a point in itself to be discussed). I would delete the original portion, but I believe in acknowledging mistakes rather than hiding them, thus this correction.

_nalply 9y ago
OK. I also made mistakes and I understand you. However you should perhaps move the disclaimer to the top of your post, so people have a chance to abort reading your post.
- kbenson 9y ago
  I could, but in this case I think it's more powerful as a reminder to be careful about interpretation for those that are in agreement with the original statement and then come upon the revision. That it might initially reinforce someone's similar mistake to then confront them with the fallibility of human nature appeals to me.

pjmlp 9y ago

MISRA, ISO 26262 make C feel like Ada with curly brackets, it is so constrained that it actually isn't C any longer. > Get to know them, and see how safe C/C++ code is actually written! I know them and also know that only in the context of high integrity computing are companies willing to pay for such processes, because they are cheaper than closing down the company if humans are killed due to a memory corruption error. Good luck imposing such process in industries where human lives aren't at risk. If companies could be sued by bad software quality, it would be another matter.

skrebbel 9y ago

That's a different kind of safe than the OP means. You mean "does not crash, produces the right results", he means "can'te be hacked". A non-networked engine control unit is super hard to hack by simple virtue of being unreachable from the internet. I bet if you run a fuzzer against your perfectly safe aviation code you'd find lots and lots of security issues. But those issues aren't important.

noir_lord 9y ago
> I bet if you run a fuzzer against your perfectly safe aviation code you'd find lots and lots of security issues. But those issues aren't important. As long as no one does something silly a decade from now when it comes to the networking on the plane/ship/factory.
- adrianN 9y ago
  The "Industrial Internet of Things" is currently a very hot buzzword. I fear the worst.
millstone 9y ago
I don't follow your point. Software has to be prepared to deal with abnormal inputs, whether those are from a malfunctioning sensor, or an attacker on the same WiFi hotspot. Safety is a property of a system and the context in which it's used. Safety is not a property of its individual components, including its code. If your CPU's GPIOs were directly accessible through the Internet, your computer would be hacked too; does that mean your system is not safe?
- adrianN 9y ago
  A malfunctioning sensor is very unlikely to prepare a specially crafted input that exploits a bug. An intelligent adversary is something completely different. Your claim that MISRA and standards for safety critical software also provide security against targeted attacks does not really follow.
kbenson 9y ago

sytelus 9y ago

The aviation/automotive code doesn't get deployed on to millions of personal computers of tons varieties and locals and probed by professional hackers endlessly for vulnerabilities. The aviation/automotive code runs in very well defined environment, almost completely locked down and unavailable for user interaction for most parts. Its unfair to compare them with open ended applications like browsers which has to handle tons of formats, extensibility APIs and very complex and often incomplete protocols with numerous versions and compatibility issues. Two very different worlds.

kbenson 9y ago
The problem with security through obscurity (which is what this approach is analogous to), is that obscurity can't really be guaranteed, and you usually can't be sure exactly how your code will be implemented in the future. Here's some somewhat recent examples of that, where a Jeep was remotely controlled because the system's bus wasn't correctly segregated[1], and where an avionics messaging channel may be exploitable to send bogus information between planes and air traffic control[2]. 1: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig... 2: https://defcon.org/images/defcon-22/dc-22-presentations/Polstra/DEFCON-22-Phil-Polstra-Cyber-hijacking-Airplanes-Truth-or-Fiction-Updated.pdf https://defcon.org/images/defcon-22/dc-22-presentations/Pols...

adrianN 9y ago

A lot of the "safe" code written in embedded systems is only safe because the inputs are already safe. You don't get to exploit any bugs in a parser when the messages are created by a system under your control. Cars, planes, trains, medical devices, etc. don't really have interfaces to the outside world that can easily be exploited. Those interfaces they have get exploited. See for example https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig...

simias 9y ago

It's true but I'd argue that they're not really "coding" in C or C++ in the way it's commonly accepted in those critical environments. It's more like a "fill the blanks" exercise where everything is split in tiny functions that are thoroughly specified and tested. Effectively 90% of the dev work is done higher level by the various specification and constraint tools. All that's left to the C coder is the most menial of tasks, "dumbly" implementing the algorithm exactly as spelled out in the spec. And even then every piece of code will be checked multiple times before being validated. There's simply not enough leeway for the coder to make a significant mistake, or at least that's how it's supposed to be. Clearly generalizing this approach to all of software development seems impractical. It's extremely costly and makes it hard to make quick changes to the codebase. For non-critical applications it's probably overkill. There's room for a compromise I think. The problem with C IMO is that on its own it's highly and uselessly unsafe. At the time of its conception it was probably impractical to write a compiler that would check things like lifetimes statically because it would've made compile times unbearably long but nowadays it's not really a problem anymore. Do you really encourage people to write critical code in a language where the compiler gladly compiles codes like this, without even a warning (tested with -Wall -Wextra on gcc 6.4)? int test(void) { int i[3] = {0}; return i[8]; } And the following code only with a non-critical warning: int *test(void) { int i; return &i; } Isn't the entire hacker mantra to have the computer work for you? I'd prefer if my compiler was actively trying to detect my mistakes instead of dumbly spewing machine code.

clarry 9y ago
> int test(void) { > int i[3] = {0}; > > return i[8]; > } clang will warn. gcc will warn with -Wall -O2. > int *test(void) { > int i; > > return &i; > } You are free to use -Werror. I encourage people to learn to use their tools first. Instead of whining about the language when it is their tools that do not do what you want by default.
- simias 9y ago
  Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Still only a warning though. And I don't think -Werror is a good general purpose solution because it's too broad. Many warnings are just fine as warnings and for big projects that build on several operating systems using a lot of 3rd party libraries there's bound to be a few harmless warnings here and there. For instance the perfectly valid "if (a && b || c)" will warn with -Wall. I guess I'd want a "-Werror-on-serious-warning". That's why sane defaults matter, if those warnings were errors to begin with they would be fixed upstream, if instead you decide unilaterally to turn on -Werror for your code then you're screwed if your third party headers weren't as stringent with their coding rules.