> What's the roadmap for reducing the number of security flaws in C software?

Thoughts and prayers.

A little controversial, but I would have liked the larger programming community to address this rather than write completely new languages.

Think of all the effort that has gone into rust. Compilers, package managers, libraries, etc. What would have happened if that same effort went into better analyzers, linters, compilers, etc, for C/C++? Rather than rewriting everything to be made "perfect" (which will never happen), this would be applied to the metric shit ton of existing code, making it better. Not perfect, but better.

Of course that work is dirty and necessarily political, and making a new language is sexy...

The reason that this wasn't done is that we believed (and it still seems to be true) that you cannot make C or C++ be memory safe at compile time. Or rather, you cannot do it without introducing backwards incompatibility, which means you're effectively making a new language anyway, and something that's a non-starter for those languages. (as it should be, IMHO.)

It had nothing to do with "sexy" and everything to do with engineering goals. I assure you, a lot of work in Rust is dirty, political, and not sexy too :)

There is already a metric shitton of work being poured into making C safer. Everybody realizes that most existing C code will be used for a long time. That's why we have a bunch of different sanitizers, fuzzers, static analyzers and so on. The problem is that these tools only find a fraction of the possible memory corruption bugs you have and many people don't even bother to use them. You can still find bugs in many open source projects with a simple fuzzer. Sanitizers are only as good as your testsuite, but except for SQLite, which project has extensive coverage?

As someone who has dabbled in the C++ program analysis space before: A _ton_ of effort has gone into this already. There's also a lot of promising stuff there already.

There's active research on how to best do aliasing/pointer analyses, both for optimizers and for linters.

I've often said that the holy grail of C++ program analysis is aliasing info that is perfect, local, and can be computed in a reasonable time. The current situation on this is basically "pick one", _sometimes_ "pick two" if you're good. Rust's design gets you all three by picking different defaults and asking for some extra annotations from the user. The kicker is: it's all based on existing research!

Firefox has its own static analysis and IIRC has looked into other static analysis stuff (the GC analyses are pretty awesome). C++ static analysis is good, but not good enough, in this case at least.

To me, it's quite clear: the target language would have forked from its base, creating of necessity an incompatible ecosystem (no one wants an improvement after which you still can still make the same old mistakes, and some mistakes are emedded in the C/C++ syntax), and we'd end up with something slightly worse than Rust, using somewhat more familiar tools.

I know the kernel is not the C language, but I think the efforts being undertaken to harden the kernel (use of syzkaller, etc) provide a good roadmap for C programs in general.

https://lwn.net/Articles/763641/

The Chrome team is working really hard to secure their program. They're also really good engineers. Yet there are still lots of memory corruption bugs in Chrome. That makes me believe that it's impossible to write safe C++ once your code is sufficiently complicated. I don't think C fares any better on that front.

Look at the languages made by ex C programmers. Zig is a good candidate.

A study backed by microsoft recently released a version of C that can be statically checked https://github.com/Microsoft/checkedc

That some stuff can be, of course:

> Static checking enforces the integrity of the bounds information and allows the eliding of some dynamic checking. Dynamic checking enforces the integrity of memory accesses at runtime when static checking cannot.

This is an OS problem, Rust won't save you there because you're going to use unsafe anyway, in Rust you would create wrappers for the unsafe part, they probably do the same in C/C++ for OS, you don't use unsafe / low level things for higher part of the OS.

Redox is an OS written in Rust and had kernel panic with bad arguments passed to a user space program so ... ( it was a community challenge from 2 years ago )

I think Rust has a good vision for security but it's clearly not bullet proof as people seem to think, especially not on the low level fields like OS.

> you're going to use unsafe anyway ... you don't use unsafe / low level things for higher part of the OS

It seems as if you contradict yourself here. Or are you trying to suggest that Microsoft's bugs were confined to the "lower part of the OS"?

> so ...

So, what, exactly? Your point is not clear. Redox used Rust and held a challenge to find bugs in Redox -- which was succesful at uncovering bugs in Redox. Ergo, what? "memory bugs still exist when programming in Rust"? Or "We haven't completely extinguished this kind of bug, therefore we haven't improved over C." It sounds bogus when I try to guess at what you're implying, so please clarify.

The whole unsafe escape hatch was designed to imbue the flexibility required to cover the design scope required for system software. Don't fault Rust for adding it. Credit Rust for Redox's stability after they did this challenge.

My point:

- Redox is built in Rust and had serious memory bugs triggered by userspace applications, people claim that we should build OS in Rust because it's "memory" safe, in reality it's much more complex than that

It did not have serious memory bugs. All of the unsafe code in Redox, of which only a small fraction is unsafe, is neatly compartmentalized so that it's easy to audit.

It was a year ago: https://gitlab.redox-os.org/redox-os/redox/issues/1136 https://gitlab.redox-os.org/redox-os/redox/issues/681

And we're talking about a bunch of people randomly clicking / trying things, so imagine what's really inside Redox.