Hacker News Reader

Comment by Hermitian909 | Hacker News Reader

As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes.

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

View on HN

Certainly there's no boundary that clearly delineates "safe" and "unsafe" languages.

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.

Then punish defects. Give programmers the freedom to define their semantic space, but make sure to punish profit-seeking entities for insecure behavior. It's not that simple of course (it's easier for FB to pay a fine than a startup, for example), but we need to enforce the cost of defects at the organization level. I mean, there's also a world where FB apologizes about how they "forgot" to remove `unsafe` from a part of Rust code.

Definitly, liability needs to happen, sledgle with lawsuits hammer any company that doesn't take security seriously.

Sledge with lawsuits and company that knowingly buys uncertified software.

Like the FAA does.

Never, ever going to happen in enterprise and consumer software.

It already happens when that enterprise and consumer software is deployed in high integrity computing scenarios.

At the risk of being confrontational, show me a language without built-in footguns and we can talk. I've seen people fail to check their inputs in every language I've ever touched. I've seen people cobble together their own horrifically insecure SQL query builders. And so on.

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.

They certainly started off that way but modern static analysis can catch a lot. Plus these other languages (yes, including Rust) are all still at least partly implemented in C/C++ so you cant outright ban it.

That paper has many problems. For example:

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

This is false. There are multiple safe C implementations. compcert and https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html are two such.

Compcert is a verified compiler. It guarantees that the generated code does what the source code requires. It doesn't turn unsafe C programs into safe ones.

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

Actually that is what Oracle did with SPARC ADI, Google/ARM are pushing for with MTE, Apple is trying to do with PAC, Microsoft with Phonon.

When everything else fails, kill the bug with hardware memory tagging spray.

The CompCert C reference interpreter aborts execution on undefined behavior.

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

> The CompCert C reference interpreter aborts execution on undefined behavior.

A C interpreter is not exactly the sort of thing that the embedded software industry has been waiting to deploy in production.

Of course they exist, see eg CHERI: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

CHERI is far more than just an "alternative implementation of C". It includes a completely different hardware platform and replacing all your hardware can hardly be considered "cheap".

It's many orders of magnitude cheaper than replacing all your software.

You can't just adopt that hardware and get memory safety. The hardware is providing support for a capabilities model, which you then have to adopt at a software level both within your OS, compiler, and application code. This also would break C and C++ ABIs, so it's very unlikely to get adopted for a number of cases.

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.

Indeed, you need the whole stack. However, the (non-temporal) memory safety alone is still quite easy to get - the compiler will take care of it, as a programmer you just need to make sure your code doesn't get in the way by eg manually stashing pointers into non-pointer types. It's been demonstrated on large, real-world code bases, such as FreeBSD and PostgreSQL.

(Disclaimer: been there, done that, part of the CHERI team)

Yep, much of the wins look to be a matter of just recompiling, which is great. I'm a big fan of these pointer tagging techniques in general. I just want to be clear that pointing at CHERI and going "See? We already have memory safe C and C++" is glossing over some important details.

Best of luck with the research, I'm quite bullish on the work.

The author of that paper has written a safe C implementation.

https://github.com/stephenrkell/libcrunch

I applaud him for giving it a go, but it's far from complete ... no use-after-free protection at all yet, for example.

The line is far less blurry than you suggest. The stats from the article say 70% of vulnerabilities come from [insert list of a few memory-wrangling mistakes here]. I'd consider any language that enables the top 70% of vulnerabilities to happen to be unsafe.

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)

An statistical approach like that has the flaw any the most used language would always appear to be at the top of the "most unsafe".

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.

> Don't hire people who are under qualified. Its really that easy.

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?

[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome

So many CVEs are due to their bug bounty program, hackers are incentivized to sell vulnerabilities to Google rather than exploiting them. CVEs are publicly disclosed after they are fixed, of course.

The CVEs are due to the bug reporting, the bugs are not.

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.

You could have made that argument a few years ago, before we started to see in-the-wild exploitation of these vulnerabilities.

You make a good point. There is a lot of evidence that it's not as easy as I make it seem.

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.

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

That's needless extremism, moderate programmers benefit from safety mechanisms, and you can't hire a lot of perfect programmers.

> As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes.

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.

I agree with this article’s criticism of managed languages (Java, C#) for systems programming, but the author does not convince me that Swift and Rust would not be much, much better to build safe(r) systems and infrastructure software.

Even in confines of C there are coding conventions with lower bullrun compatibility and there are some projects that use them: putty and s2n use them with C, grpc library uses it with C++. Fat pointers are in talks since 80s and are cheaply implementable, meanwhile Fuchsia, an allegedly new codebase, is written in old good 70s vanilla C as if PDP-7 is still hot.

As for the article, the dream to get all UBs right without a systematic approach is idealism.

I advise you to update your Fuchsia knowledge, it is written in a mix of C++, Rust and Dart nowadays.

Reply on news.ycombinator.com