Hacker News Reader

Comment by millstone | Hacker News Reader

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

View on HN

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

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

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.

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.

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.

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.

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

Those examples are interesting, specifically because history has shown us this point of view to be erroneous through those exact systems.

Automotive control units that are supposed to be segregates from certain data channels sometimes aren't. That was the cause of the Jeep remote hijacking stuff.[1] Any automation has to have some inpute and output to be useful for more than anything as a heater, and assuming your inputs aren't "networked" may not be valid given you likely can't control exactly how it will be used now or in the future.

For aviation, there have been problems with assumptions regarding the integrity of the channels used for communication between planes and the ground. This has led to certain systems being exploitable, even if not as bad as the initial hype made it sound.[2]

1: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig...

2: https://defcon.org/images/defcon-22/dc-22-presentations/Pols...

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

The "Industrial Internet of Things" is currently a very hot buzzword. I fear the worst.

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?

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.

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

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.

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.

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.

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.

> 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

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.

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.

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.

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

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.

> Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on.

Right. So GCC isn't really a static analyzer. But it does the analysis that is required to perform certain optimizations, and as a side effect you also get some new warnings with the optimizations enabled.

> And I don't think -Werror is a good general purpose solution because it's too broad.

It sure is too broad for all existing software to compile, but if we're talking about security-critical software, what is with this double standard of bashing C for the lack of stringent checks per the standard and at the same time requiring compatibility with third party software that isn't built to the same standard?

I think if you're doing something security critical, then you must want the same stringent checks from all the libraries you use. Which means you choose the good libraries, or make your own, or fix the existing ones. Yes, positive encouragement from sane defaults could push other projects into doing the right thing, but as long as they don't, you really don't have to use their bad code in your security critical product. Yet, it is entirely usable. OpenBSD for instance compiles the kernel and libcrypto among other things with -Werror. Other parts of the system may be built with less stringent checks.

It is, by the way, possible to only turn specific errors into warnings with -Werror=... Likewise, you can disable specific annoying warnings.

I agree that it would be nice if compilers provided sane set of warnings (and errors) out of the box without any extra tweaking. I think we're getting closer and closer thanks to clang pushing things in that direction. On the other hand, I don't suppose people will ever agree which warnings are the right ones. I'd say most people who want stringent checks will enable -Wall and -Werror, and they will add the parentheses in the expression you mentioned, even if it is completely legit without them.

> It sure is too broad for all existing software to compile, but if we're talking about security-critical software

The problem I have with this is the assumption that software you write that may be used by others can easily be classified into security-critical software and non-security-critical software. Sometimes you don't know, sometimes it changes ten years later as something gets pulled in and used because it's easier, multiple times over the years until the original author of a portion of the code may be entirely unknown, much less their intention for whether it was sufficiently robust for security critical situations (think an OSS library that may have forked a few times, and copied small bits of code such as utility functions from some other projects).

It's time to switch to safety by default. We should fail safe, and require flags to allow previously failing code to compile, not to just hear that it might cause a problem.

Right, that is why I proposed people to use -Werror, even if that means you have to vet and fix third party code (which you should do anyway if you're depending on it). Ideally you use other tools too.

Apart from that, don't assume flags and static analyzers can save you. If you're building something security critical, you do not make any assumptions about the code you depend on. You don't assume it is in some class. You don't "don't know", you vet the code. Flags and analyzers, default or not, are at best going to save you from a small subset of problems. The code might still be completely backwards and insecure.

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.

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

2: https://defcon.org/images/defcon-22/dc-22-presentations/Pols...

Reply on news.ycombinator.com