I think if C does not evolve, some people with giant C codebases will find themselves in the unfortunate position that they suddenly will be shut out of a market by regulators, because the C code is considered a risk, or that they will be liable for bugs caused by preventable memory safety issue, and keeping the code will not be sustainable.
back
2 comments
That's not really the case. For example Airbus has a giant codebase all written in C. It's never going to be rewritten. Instead they apply many tools to it including formals proofs (of both the code and the toolchain). They work closely with the relevant regulators.
I'm actually more confident in that process than I would be of some insane plan to rewrite it all in Rust - which would take forever and Rust doesn't have any of the tooling, formally proven compilers, a language specification, more than one implementation, etc etc.
People really don't know what they're talking about when they claim C codebases will be rewritten or will "have to be rewritten" because of "regulations", when the regulators are on top of this stuff already.
It is true that safe systems require more than just a programming language. However, the Rust compiler has already been qualified for some safety standards, with more on the way, including the things that Airbus does. You're right that "defense in depth," in a sense, is a good thing for safety, and starting with a language that's memory safe by default adds an additional layer in comparison to things that don't.
There is already a bill in the US (it's part of a funding bill so it's just a matter of time until it passes) that, after it passes, the DoD is going to be putting out a plan for moving towards memory safety for things purchased by the DoD. Now, as we all know, because this isn't something that will happen overnight, and so there will be signoffs for exceptions, I'm sure, so we'll see what actually comes of it.
There is also a similar one in the EU, but I know less about how things work there so I won't say more other than "I know it exists."
The DoD mandated the usage of Ada [1] in the early 90's but changed their minds a few years later. History repeats itself?
[1] https://en.wikipedia.org/wiki/Ada_(programming_language)
It doesn't necessarily repeat itself, but it does rhyme :)
I agree that this is a great story about how even a government mandate does not mean something may come to pass.
However, I also think that the conditions are different enough that it does not guarantee that this will fall the same fate. There's a few reasons why: the first is that the goals are different. Ada was created by the DoD, because they thought that there were too many languages in use there, and that standardizing on a single, modern language would be far better. So then they set off to create Ada, and in 1980, the first version was done. But it wasn't seen as popular, for various reasons.
In the words of the mandate itself: https://web.archive.org/web/20160304073005/http://archive.ad...
> In March, 1987, the Deputy Secretary of Defense mandated use of Ada in DOD weapons systems and strongly recommended it for other DOD applications. This mandate has stimulated the development of commercially-available Ada compilers and support tools that are fully responsive to almost all DOD requirements. However, there are still too many other languages being used in the DOD, and thus the cost benefits of Ada are being substantially delayed. Therefore, the Committee has included a new general provision, Section 8084, that enforces the DOD policy to make use of Ada mandatory.
It didn't catch on enough naturally, and so therefore needed a push, and the mandate was supposed to accomplish that. But it backfired. First of all, there were a LOT of exceptions. (which I mention could easily happen in this situation as well). The mandate:
> "Notwithstanding any other provisions of law, where cost effective, all Department of Defense software shall be written in the programming language Ada, in the absence of special exemption by an official designated by the Secretary of Defense."
That "where cost effective" was a big loophole.
Second, well, take this article from 1997: https://www.militaryaerospace.com/communications/article/167...
> Chief complaints about Ada since it first became a military-wide standard in 1983 centered on the perception among industry software engineers that DOD officials were "shoving Ada down our throats."
Part of the idea of repealing the mandate was that it would be more palatable to people, and that they'd be more likely to use it if it were repealed.
But there were a lot of other parts to this story that led to the removal of the mandate, like an overall movement towards more off-the-shelf commercial components rather than making everything in-house. But this comment is already too long.
---------------------------------
Okay so why is this different? Well, first of all, because it's not actually a mandate: the language in the bill is
> SEC. 1613. POLICY AND GUIDANCE ON MEMORY-SAFE SOFT- WARE PROGRAMMING. > > (a) POLICY AND GUIDANCE.—Not later than 270 days after the date of the enactment of this Act, the Secretary of Defense shall develop a Department of Defense wide policy and guidance in the form of a directive memorandum to implement the recommendations of the National Security Agency contained in the Software Memory Safety Cybersecurity Information Sheet published by the Agency in November, 2022, regarding memory-safe software programming languages and testing to identify memory-related vulnerabilities in software developed, acquired by, and used by the Department of Defense."
That sheet is this one: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
and the most salient part
> NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible.
"when possible" feels like that "where cost effective" bit. I guess I've said this twice in this comment now. We'll see.
But moreover, this is not recommending "rewrite everything in Rust." It is not recommending rewriting every single thing in any single language, or move towards a language that is new, designed by them. It goes on to mention
> Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®.
I suspect that this policy will not be as controversial as broadly as the Ada mandate was. It's just a different thing.
Time will tell, I guess.
Excellent write up. This would make a good article for HN :)
I may in fact have been like "damn I should make this even better and put it in a blog post" so thank you for validating that that is in fact a good idea!
There are tools to make C safe and for some industry use this will work. I also agree that rewriting in Rust is often a mistake.
But NSA is already advising against the use of C: https://www.nsa.gov/Press-Room/News-Highlights/Article/Artic...
And the EU is working on new liability rules. Yes, Airbus might be able to get around this. I am more worried about smaller companies or products including open source.
I bet that many C cowboys[0] will rather switch languages than code under the requirements that Airbus has to comply to.
[0] - A meme from the days they used to call programming with straightjacket regarding Modula-2 and Object Pascal, in Usenet flamewars.
I hope the tools and techniques become more widely available, and those which are proprietary are released or reimplemented as open source.
Memory bugs are just bugs. They are not particularly interesting bugs nor difficult to track down. Even if regulators hold vendors responsible for their bugs, memory bugs aren't the only type of bug nor are they the only mechanism for security breaches. Vendors should already be doing their do-diligence to catch bugs by writing a thorough test suite, fuzzing and static analysis. With C they only have one extra step and that is to run their thorough test suite against sanitizers.
Memory bugs very often allow exploitation which is not always the case for other types bugs. Although it is of course true that other types of bugs can also be serious, memory safety violations tend to be more serious if security is a requirement. Fuzzing with sanitizers is not currently able to detect all memory bugs.