Hacker News new | ask | show | jobs
by rwmj 13 days ago
Major OS vendors have added loads of hardening to their C compilers. Not bounds checking specifically (because even if the overhead was only 20% that would be too high) but tons of other stuff such as: stack canaries, control flow integrity, hardened string functions, ASLR, zeroing uninitialized auto variables, forced warnings, linker hardening. These are added as standard in all decent Linux distros today. Probably Windows too, I've no idea. There's a good summary here: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-...

There are also bounds checking options for major C compilers so if you want to use it, you can, eg. -fbounds-safety or the various sanitize options in Clang.

2 comments

But no-one's claiming that the techniques which have been widely deployed already are bad or unworthy or haven't made a positive difference. (Certainly I'm not!) However it's evident that they haven't made a sufficient difference (and while they have an overall low cost compared to other approaches all that effort to patch and make do isn't free either).
Kind of, because to this day it has been a quixotic battle for devs to use them at scale.

Those OS vendors rather push for Swift, Java/Kotlin, C#, and Rust instead.

Alongside ARM MTE, Pluton, SPARC ADI.

Also, all those hardening measures and lack of bounds checking could have been solved with WG14 papers, nowhere to be found. C isn't set in stone.

Those techniques are implemented by default in Fedora & Debian. You have to opt out if for some reason you don't want to use them. So almost all C software compiled in these two major distros are using all of them. (Likely in other distros too, but I'm less familiar with how they configure their compilers).

Fedora will soon implement shadow stacks across the entire C codebase: https://discussion.fedoraproject.org/t/f45-change-proposal-e...