You first have to modify "all C code". It's not just a set and forget compiler flag.

Note that corresponding checks for C++ library containers can be enabled without modifying the source. Google measured some very small overhead (< 0.5% IIRC) so they turned it on in production. But I'd expect an OS distro to be mostly C.

[1] https://libcxx.llvm.org/Hardening.html

And Android uses Clang for its Linux kernel.

-fbounds-safety is not yet available in upstream Clang though:

> NOTE: This is a design document and the feature is not available for users yet.

https://chimera-linux.org/

> The Linux kernel has always traditionally been compiled with GNU toolchains such as GCC and binutils. Ongoing work has allowed for Clang and LLVM utilities to be used as viable substitutes. Distributions such as Android, ChromeOS, OpenMandriva, and Chimera Linux use Clang built kernels. Google’s and Meta’s datacenter fleets also run kernels built with Clang.

https://docs.oracle.com/en/operating-systems/solaris/oracle-...

I still remember someone at Sun commented they treated warnings as errors. This is how software should be developed.

EDIT:

https://www.oracle.com/servers/sparc/

https://www.fujitsu.com/global/products/computing/servers/un...

Finally, it is up to Intel and AMD to come up with hardware memory tagging, so far they have messed up all attempts, with MPX being the last short lived one.

Some of us actually do read licenses before using products.

Also the FAANG are hardly any better only because they spew cool marketing stuff like do no evil.

One of these days the witch hunt against C will go away.

https://www.cisa.gov/sites/default/files/2023-12/CSAC_TAC_Re...

Surely your not suggesting that the Rust compiler never produces exploitable code?

If your attitude is that getting exploited doesn’t matter because your software is unprivileged, you need some part of your stack to be unexploitable. That’s a tall order if everything is C.

You can get exploitable code out of any compiler. But you’re far more likely to get it from real-world C than real-world Rust.

Kernel level process isolation is extremely robust.

> If your attitude is that getting exploited doesn’t matter because your software is unprivileged

It’s not that exploits doesn’t matter. It’s that process architecture is a stronger form of guarantee than anything provided by a language runtime.

I agree that the place where rust is most beneficial is for programs that must be privileged and that are likely to face attack - such as a web server.

But the idea that you can’t securely use a C program in your stack or that rust magically makes process isolation irrelevant is incorrect.

You have a process receiving untrusted, potentially malicious input from the outside. If there’s an exploit then an attacker can potentially take control of the process. Your process is isolated, that’s good. But it can still communicate with other parts of your system. It can make syscalls. Now you’re in the same situation where you have a program receiving untrusted, potentially malicious input from the outside, but now “the outside” is your subverted process, and “a program” is the kernel. The same factors that make your program difficult to secure from exploits if it’s written in C also apply to the kernel.

I’m not sure where those ideas as the end of your comment came from. I certainly didn’t say them.

Please learn more about this topic. You don't understand OS security models.

https://fil-c.org/pizlix

>Pizlix is LFS (Linux From Scratch) 12.2 with some added components, where userland is compiled with Fil-C. This means you get the most memory safe Linux-like OS currently available.

The author, @pizlonator, is active on HN.

Note also that it uses fil-c rather than clang with -fbounds-safety. I believe fil-c requires fewer code changes than -fbounds-safety.