Just a naive question probably but, is there any particular reason why security related executables like sudo aren't replaced with versions written with a bounds checked language like say Go or Rust?
A technical reason for GNU/Linux not to use Rust or Go is that C supports a lot more platforms so you can't replace core components at this moment, also I want to remind you that memory safe languages existed before Go and Rust and the only project I am aware to create a safe OS and utilities was Midori by Microsoft.
Firefox and it's dependencies is not yet 100% Rust so I honestly expect a new browser started from scratch in a safe language to be done before Firefox is "ported".
That is a gargantuan project considering all the standards you need to support to have a competitive web browser. Especially javascript engine, video codecs and webgl are attack surfaces that is difficult to replace with code written in a safe language.
I think is less work then pressuring existing projects to be rewritten in Rust. I would usggest Rust fans to pcik one of those dependencies like a codec and reimplementit in Rust or gather money to pay someone to do it, I think it would be faster and less hostile.
Where are you getting your information from?
Going forward, all Android devices on ARM are required to use ARM MTE, because the only way to keep C develoeprs on track is to have hardware control their pointer usage.
https://security.googleblog.com/2019/08/adopting-arm-memory-...
And as of NDK 21, Fortify is enabled by default, https://android-developers.googleblog.com/2019/10/introducin...
Given that Linux kernel downstream on Qubes , ChromeOS and Android are the only ones with all of the security counter measured turned on, that speaks a lot for the standard Linux kernel on random distribution X.
Nitpick: there's assembly in there. Not that that undermines your point at all:)
I think the real problem is
a) C and C++ need a divorce. Because the things that you would do to really fix C make it incompatible with C++.
b) The senior maintainers of the gcc compiler need to be replaced with people willing to take these issues seriously. Right now they are focused on how fast their micro benchmarks run at the expense of everything else.
C++ community mostly adopts ISO C libraries post C89 and everything that has safer alternatives in C++ has been left out.
C style coding is discouraged in modern teaching materials for C++.
Signed integer arithmetic has been partially fixed.
Core guidelines are being pushed and for C++23 there are a couple of papers regarding improving the whole UB stuff.
A lot less than 90% in the graphs at https://www.zdnet.com/article/microsoft-70-percent-of-all-se.... Use-after-free and type-confusion bugs definitely aren't addressed by bounds-checking or split-stack approaches; many heap corruption bugs aren't either.