GCC's new fortification level: The gains and costs

> the program continued using the same pointer, not the realloc call result, since the old pointer did not change

> In this context, it is a bug in the application

This is a non-intuitive result by the normal lens C pointers are viewed by; these two pointers compared equal, how could using one differ from using the other? Pointer provenance rears its ugly head here though; one of those "pointers that have the same value"'s provenance is different to the other. By the standard, they _are_ allowed to be treated differently, and honestly the standard requires it.

https://www.ralfj.de/blog/2020/12/14/provenance.html is pretty accessible, and shockingly on point: "just because two pointers point to the same address, does not mean they are equal in the sense that they can be used interchangeably".

EDIT: spelling

The `realloc` problem isn't the only one - it also breaks many formerly-well-defined programs that use `malloc_usable_size`.

Instead of fixing this, the developers behind the "dynamic object size" push have been changing the documentation to declare any use of `malloc_usable_size` buggy even though it used to be explicitly documented as safe.

I suspect that GCC's optimization passes will break even C-standard-compliant use of `realloc`, similar to how ASAN can break due to dynamic equality checks between pointers of different provenance.

Life would be much simpler for many of us if the standards committee bothered to standardize a function that says "give me a buffer of semi-arbitrary size and tell me how big it is; I promise to resize it later", which is very widely intended. An explicit "realloc in place only, else fail" would also make many more useful programs feasible to write.

For a comprehensive set of recommended compiler options for hardening C and C++ programs, see this OpenSSF guide: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-...

I wish these compiler protocols and interfaces were better documented. They just assume you're using glibc for support. I want to fully integrate them with my freestanding nolibc C projects but I can't figure out how to do it.

The compiler's stack canaries were simple enough. The only issue was the ugly symbols. I requested that a feature be added to override the symbol generated by the compiler so I could use good names instead.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113694

Things like instrumentation and sanitizers though? No idea. Even asked about it on Stack Overflow and got no answers to this day.

https://stackoverflow.com/q/77688456

I assume these object sizing builtins make use of function attributes such as malloc, alloc_align and alloc_size. I've added all of those attributes to my memory allocator but I'm not quite sure if they're doing anything useful.

I would imagine false positives could be a huge problem. The behavior if a violation is detected is to gracefully terminate the program, so you could end up with more (but less exploitable) crashes than without FORTIFY_SOURCE.

Unfortunately _FORTIFY_SOURCE=2 is documented as making some conforming program fail, and it seems hard to find precise informations on this subject, so i'd be hesitant to use it, as well as _FORTIFY_SOURCE=3

Title should be: GCC's new (2022) fortification level... ;)

(2022)

Just curious, does anyone run with _FORTIFY_SOURCE=3 in production? Did you catch any overflows because of it, and most importantly, is there a noticeable performance degradation?

I would encourage the community to find a unit of measurement for security. Every defense can be breached, so every defense has an active region, much like transistors. Question is how to quantify.

> C programs routinely suffer from memory management problems.

Again? There is a typo there. - programs + programmers

Oddly the example doesn't work on my GCC 13.3.1, regression or just bad copy paste?

article date 2022

the new feature appeared in 2021