Does anybody know how this interacts (or is intended to interact) with nested functions? My understanding is that GCC enables executable stacks when nested functions are used[1]; it'd be interesting to know whether they produce an error for this combination or continue to silently disable that mitigation.
[1]: https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html#Suppo...
I think the background to this is simplifying the mess of RPM macros which are needed to set all these flags:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/ra... https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/ra... https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/ra...
(and several other places). I'm sure Debian has something similar as do other distros, so having one flag which does it all is an advantage.
Do you know if any distros are going to enable it by default? I think -Fhardened should be opt-out not in.
Does it make sense to compile the linux kernel with -Fhardened?
I don't think it would work. Linux uses internal string functions while _FORTIFY_SOURCE works with help from glibc, plus PIE is just not an appropriate memory model for kernel code.
Performance impact would be too much likely. Control-flow integrity protections alone usually apply 5% overhead.
This line of reasoning will lead to always using insecure systems over secure ones. We lost much larger percentages due sidechannel mitigations. Layout has more effect than -O1 to -03 (Berger et al). Machines have never been faster than they are now, when will they be fast enough to also safe by default?
can you explain what these integrity protections are and why they're needed, or give a link? TIA
Wikipedia summarises it quite well. In short, they attempt to prevent code-reuse attacks (ROP/JOP) https://en.wikipedia.org/wiki/Control-flow_integrity
Is it "-Fhardened", "-fhardened", or "-fhardening"?
-fhardened. see the article.
Just the HN headline is wrong
The auto-capitalisation HN does to headlines seems completely unnecessary to me.
For info, it is not applied to edits of the title
The article includes "-fhardening" as well. I agree that it's most likely to be -fhardened though.
See https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630...
It's still discussed in gcc-patches, and the name is proposed as -fhardened
> -ftrivial-auto-var-init=pattern
Would be nice if this was zero instead of pattern.
In my field zeroes are a problem when there is byte shift (not aligned). Specially data transfers. Alignment corruption cannot be detected when the memory area is all zeroes. We use things like 0xaaaa will have you.
From the compiler's PoV this is buggy code so it's better to make it predictably wrong rather than unboundedly incorrect (=security issues) or predictably correct (=people rely on UB).
There is a proposal for C++ to zero-initialise automatic (ie local variables):
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...
If that goes through, zeroing automatics would just be doing the same thing.
(FYI the feedback section of that paper is quite funny)
Ideally C++ would tell people you can't do that and make it a compiler error ("Ill-formed") but my guess is that too many people insist they ought to be able to take arbitrary C++ 23 code, recompile it with C++ 26 and have that just always work even though the standard doesn't deliver that and so it won't happen.
P2723 is unlikely to happen. The "Erroneous behaviour" P2795 might have a better chance. This would say it's wrong to do uninitialized reads (whereas P2723 says they are initialized to zero and thus it's not wrong) but you always get zero anyway.
I think there's a fair chance WG21 manages to make everybody unhappy by kicking this can into the long grass as they have on many other controversial issues.
Zero is the wrong default, it's better than UB, but it's not good. This is actually a problem in languages like Go where zero defaults are core to the language design. The correct thing is that "I didn't initialize it" won't compile. Force the programmer to write what they meant, sometimes they meant zero, or None, or 0.0 or whatever, but surprisingly often when confronted with the question the programmer realises their design is wrong and needs a design level change.
The proposal discusses the above concern (as it should, since the author has gotten almost every version of possible concerns). Perhaps one of them will win out and alter the proposal appropriately.
On top of your reasons (which are good ones!), there’s another good reason to avoid default zero initialization in languages like C: zero is a special value for all kinds of sensitive operations (like UID 0 for root).
In other words: a mitigation that initializes all values to 0 may make some uses of uninitialized variables worse than they were before.
0 is also the most common variable value probably :p hard to tell a valid state from an invalid one
Yes, that's why the "uninitialized" part is important; we're talking about a mitigation that would make UB potentially easier rather than harder to exploit.
Having 0 as a default initialization value in a language where doing so is well defined makes perfect sense; this is primarily an issue for C and C++ (to a lesser extent).
UB is a property of standard. GCC implements plenty of deviations from standard. Nothing wrong with that, as long as it's explicitly documented.
I'd even argue that defined behaviour is a subset of undefined behaviour. So I'd value compiler options to force well defined and "expected" behaviour instead of the current insanity.
Clang "optimized" away empty loop. My MCU gets locked because of it. I have to write `b .` with assembly, because C can't cut it. It is insanity.
Optimizing out an empty loop in C is illegal.
N1570, 6.8.5, point 6 under "Semantics":
An iteration statement whose controlling expression is not a constant expression,156) that
performs no input/output operations, does not access volatile objects, and performs no
synchronization or atomic operations in its body, controlling expression, or (in the case of
a for statement) its expression-3, may be assumed by the implementation to terminate.
Note that the rules in C++ on this are different, and do allow even a constant-end-condition empty loop to be assumed to terminate.