But certain languages (like C and C++, for instance) have built-in footguns. They were built in for various important reasons, but right now many of these reasons are not as pressing anymore. We can take something like Ada, Rust, OCaml instead, or at least use the extensive tooling that allows to statically check programs written in (a rather wide subset of) C and detect great many classical pitfalls.
So I'd say that it's not about safe languages, but mostly about safe methods of development for critical software, methods that remove large classes of defects that are commonly exploitable.
This, of course, can be only one layer of protection; the OS and the hardware design should also do their part. Advanced devices, like desktop and phone CPUs, have some very good hardware features for protection, like MMUs, w^x bits for RAM pages, secure enclaves, etc. Simpler devices (like IoT SoCs) often don't, and they can be potentially cracked into more easily.
Like the FAA does.
Never, ever going to happen in enterprise and consumer software.
Meanwhile, I have to argue with developers on a regular basis to convince them that they actually need to patch the libraries in their systems. Yes, even if they don't see an obvious exploit path. Yes, even if it's more work than drop-in-and-ship.
Getting them to use static analysis is a nightmare. Entirely too many developers view each finding as an attack on their style they can negotiate away.
As you so wisely and correctly say, we're at a point in time where we mostly have the tools to employ safer software development lifecycle methodologies. It is telling, then, how often we don't.
> There is no particular need to rewrite existing C code, provided the same benefit can be obtained more cheaply by alternative implementations of C
To be clear, those "alternative implementations" do not exist, and no-one actually working on C compilers or tools to make C code safer has been able to produce one, or even come up with a credible plan for producing one.
"Fail-Safe C" is a research project that has been dead for ten years. Note:
> Some benchmark results show that the execution time are around 3 to 5 times of the original, natively-compiled programs, in avarage
That overhead is actually a lot higher than similar projects I also consider failures, such as CCured.
To be clear, when we talk about "an alternative implementation of C", it needs to give similar performance and other properties (e.g. function and data interop) to other C compilers. You can't impose a 3-5x slowdown and say "look, C is safe".
When everything else fails, kill the bug with hardware memory tagging spray.
> To be clear, when we talk about "an alternative implementation of C", it needs to give similar performance and other properties (e.g. function and data interop) to other C compilers. You can't impose a 3-5x slowdown and say "look, C is safe".
Pretty much every language (except rust) which claims to be "C but safe" has the same issue, except you have to rewrite your program in it.
A C interpreter is not exactly the sort of thing that the embedded software industry has been waiting to deploy in production.
Further, CHERI is not enough to achieve temporal memory safety, it only provides the primitive that one could use to implement an efficient, correct tracing GC.
Perhaps most importantly, one can not use CHERI today. It is just not an option. Memory safe languages exist, and have existed for quite some time.
Pointer tagging and other approaches like CHERI are very promising. Keeping in mind of course that they double the size of pointers and have a global runtime performance cost. Less ambitious but otherwise similar mitigations are already being adopted.
(Disclaimer: been there, done that, part of the CHERI team)
Best of luck with the research, I'm quite bullish on the work.
Maybe a safety ranking is in order? How many CVEs from [year], weighed by severity, are impossible to happen in [language]. Obviously this idea has serious problems, but you see my point: C would get a straight up zero, as it should! (well, not completely zero, as many vulns come from dependencies and C's complete lack of a package and dependency system is actually an advantage here)
Instead, people should be schooled to write better code. Thats it. Don't let some random new employee with no certifications write safety-critical code. Don't hire people who are under qualified. Its really that easy.
I have no idea, honestly, how you would introduce a use-after-free bug with C++'s smart pointers. Its the lack of schooling, the lack of certification, and the lack of a safety-focused selection of applicants, not a language that you can write bad code in if you ignore all warnings and advice.
Even rust has unsafe{}, but I dont see anyone complain when thats used to introduce safety issues, because "youre not supposed to do that, even though technically you could".
You can have all the safety mechanisms in a language, but you need control, too, and anyone who is completely unqualified will use that to break something.
I understand what you're saying, but I'm not sure I agree.
For example, look at Google Chrome. They've got mountains of cash. They've got loads of people working for them, and loads of job applicants if they want more. They've got a strong business case to work on security. They've got in-house pen testers, and a bug bounty program. They've got code reviews. They can afford any static analyser on the market. They've got sandboxing. They've got open source so many eyes can spot bugs easily. They can dictate terms on requirements - if Chrome vetos a new web standard and it's as good as dead, and if Google decides plugins have got to go, they go.
And they've got 177 CVEs so far in 2021 [1] - including such greatest hits as use-after-free, buffer overflows and out-of-bounds access.
You and I think we're writing secure C++ - but if the best-resourced team in the world can't write secure C++, isn't it more likely we're just fooling ourselves?
The point is that memory safety bugs are the gift that keeps on giving.
You can throw as much money into the problem as you want, and the inherent complexity of memory management means you are still gonna ship bugs of all severity.
I might be wrong about this, too, but I think a lot of smaller companies have the really bad practices. Google shines as one of the major "suppliers" of C++ tooling, and their code quality is undeniably very high (considering the complexity of some of their codebases), but a lot of popular libraries are written by small teams, often not even under contract, and you end up with a lot of PR'ed stuff, which is great, but it needs to be thoroughly reviewed.
A good example of "unqualified" PR's was that recent one with the malicious PR into the linux kernel by some university. It was caught, but it does make you wonder how many vulnerabilities make it through because of simply trusting "random unqualified people" too much.
That's needless extremism, moderate programmers benefit from safety mechanisms, and you can't hire a lot of perfect programmers.
I agree, though that's not intractable. There's security compliance like ISO27001, which can't say "you're secure", but can say "you've got a threat model and you take measures to address it". It's then something you document and provide evidence for as part of your compliance obligations.
If we applied the same thing to a programming language I think it could be very clear to see the differences between languages.
That's not at all to say that I think ISO27001 is a good model for security, just that we already have systems that handle very nuanced ideas, so a formal definition, or proof, etc, is not really as necessary as it may seem.
As for the article, the dream to get all UBs right without a systematic approach is idealism.
Yes C/C++ have more footguns than Java but there's no "hard line" in the safety differences and there are real and important things that need doing that it's not always clear can be reasonably done in another language.
If you haven't, I'd encourage you to read the paper "Some Were Meant For C"[0] on why C still doesn't have a real replacement (though it could in the future).
[0] https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-p...