Hacker News Reader

Sometimes you can work around a "has to be written in C" requirement by generating (known-safe) C at build time and avoiding writing it directly.

It is as much C, as MISRA, Frama-C et al are.

Or C coding on Windows with SAL.

Indeed. But I see these as workarounds for very particular requirements, not as ways to build new software in a responsible way if other options exist.

It's certainly better with such safety annotations than without...

It’s not clear to me that it necessarily is, if those annotations provide a false feeling of security. C-rusted doesn’t seem to have a real story for preserving invariants in linked-in but not locally compiled code, which is the main thing that makes C a valuable ecosystem.

To be fair, Rust does not really have such a story either. Externally compiled code (i.e. code not built with the exact same version of the compiler) must interact via the unsafe C ABI and be re-wrapped locally into safe Rust-friendly constructs. There are crates to make this a bit easier, though.

Things might be different if you could preserve useful invariants all the way down to binary code, of course. Then externally compiled code could also be meaningfully checked for safety.

The difference is culture and tooling: linking against random .so files is normal in the C world, while Rust strongly encourages you to use source dependencies.

For the time being, as Apple showed by their gigantic effort with Swift ABI, there are C and C++ shops (and Objective-C ones) that really care about dynamic libraries, which any alternative needs to take into account for their adoption.

The main issue is the culture, being more in line with ALGOL/PL/Ada/Wirth languages point of view of why security matters, even if there is a bit of unsafe core around.

This sounds like JavaScript: The Good Parts revisited. Agree with everything you’ve written. However, in the rare situation that one has to go down this path, a linter/static code analyzer can prove to be a life saver. Found some on this page: https://github.com/caramelomartins/awesome-linters#cc

Luckily, no one ever used The Bad Parts again after that book was published.

Even getting folks to reliably use a linter can be a chore. Getting all C coders current and future to use these new techniques seems wildly optimistic to me.

Is there maybe a linter you can use with C and then use as a required status check on merge requests in GitHub / Gitlab?

Yep, the company behind this advertises online demos in gitlab

but can't you lint for such things or even just grep? The world will always build a better idiot, we're just trying to reduce the attack surface.

>But I was always acutely aware that it only took one team member to declare a void * to an unbounded array for things to break out of that carefully constructed illusion of a safe jail.

This is why code reviews are a thing. If you have competent programmers, with a CR process as part of CI/CD pipeline, you really don't need language features to handhold programming.

Even with the best code reviews, even with the best development practices, even with the most comprehensive automated testing processes, you still do need a language to help you.

Case in point, even SQLite still has CVEs relating to memory safety: https://www.sqlite.org/cves.html

I dunno, those bugs look mostly no- or low-impact. Saying somebody needs a language for that is a bit strong in my opinion.

The page itself literally leads with multiple extensive statements about how the sqlite CVEs are exaggerated and inaccurate:

> Grey-hat hackers are rewarded based on the number and severity of CVEs that they write. This results in a proliferation of CVEs that have minor impact, or no impact at all, but which make exaggerated impact claims.

Also how most CVEs require arbitrary SQL injection (and if you have this access, you're screwed already):

> Almost all CVEs written against SQLite require the ability to inject and run arbitrary SQL.

It also explains that:

> Few real-world applications meet either of these preconditions, and hence few real-world applications are vulnerable, even if they use older and unpatched versions of SQLite.

---

It also explains that many CVEs are denial-of-service due to division-by-zero, which in Rust can only be caught by using the opt-in `checked_div` so would be equally safe in C and Rust(?)

It is true that a lot of people like to file CVEs for extremely theoretical security issues.

See for example - https://nvd.nist.gov/vuln/detail/CVE-2023-0687

The CVE is correct that the “gmon” component of the GNU C Library contains memory corruption bugs. In fact, I’ve found even more than the specific one that CVE is about.

But, the claim that this is a security vulnerability is a bit silly. These are profiler functions, which are usually only called in non-production builds with profiling enabled (gcc -pg), and even then only from CRT startup code. It is rather unlikely an attacker can exploit any of these bugs in them without already having the ability to run arbitrary code in the process, at which point they don’t need these functions, they’ve already got all these bugs have to give them.

Yeah, this kind of thing is tricky. Rust has had some CVEs filed against the standard library that are CVEs because of Rust's guarantees. Same issues existed in the C++ standard library but since it's UB, not a CVE there.

Do the C++ libraries require changes as a result of these issues?

Nope, their docs just say "don't do that" and so you're expected not to do that.

Ok, so this isn't an issue, right?

I'm not sure what you mean by "isn't an issue."

All I'm saying is that the CVE process is a human one, with lots of nuance. You're pointing out one aspect of that, that some CVEs are very practical, and others are more theoretical. I was trying to chime in with a similar way in which this is expressed, in that an identical bug in the standard library of one language may be a CVE, while in the other, it may not be a CVE, even with the same problem in both of them. That's "not an issue" in the sense that yeah, of course, Rust cares about this a lot more, so it's a more serious problem in Rust, so this process is legitimate, but it is in the sense that depending on how you're trying to do comparisons, there's more complexity than simply tallying up CVE counts.

CVEs aren’t really anything but an identifier for a problem. It says nothing about its severity, exploitability, or in some cases, whether it is even an actual bug. You can effectively get one for ~free. This is one of the reasons why tallying up their counts is not useful, but others include things like “people focus on some software more”.

With that said, I wouldn’t bring up this distinction here. The problem here is identical but Rust bills itself as a language where it takes responsibility for correctness bugs while C++ is a language where correctness is something that the programmer is supposed to provide. That doesn’t mean the Rust CVE is any less valid or complicated than the other CVE, it’s just that the bug would get assigned to Chromium or IOAccelerator. So if you’re saying that you shouldn’t just look at the number of CVEs and claim that Rust is somehow less secure: yes, absolutely. But if you’re saying this because you want to point out that Rust CVEs are somehow lesser because they are self-imposed, then no, that’s not true.

> if you’re saying that you shouldn’t just look at the number of CVEs and claim that Rust is somehow less secure

Even more general than that, it’s not about Rust specifically, just that number of CVEs alone, with no other context, is a bad metric.

> That Rust CVEs are somehow lesser because they are self-imposed

I am not saying that, yes. That would be incorrect.

Code reviews are great, competent programmers are also great. Even the best programmers make mistakes.

Additionally, the easier memory safety is, the more time those competent programmers can devote to work on new ideas instead of babysitting code.

Code reviews don't replace automatic tests or even linters. What leads you to believe they replace memory management errors?

I don't think I can agree with this. Competent programmers are no silver bullet against whole classes of possible errors. Mistakes can be made, mistakes can be missed during code review. The vulnerability repositories are full of those.

You call it handholding. I call it partial automation of code review. Why waste expensive hours of my co-workers' time when I can have a program do it in seconds for a few pennies of electricity?