GCC Preparing to Introduce “-Fhardened” Security Hardening Option
phoronix.com
phoronix.com
[1]: https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html#Suppo...
A desire to support clang is ubiquitous enough nowadays that weird stuff like this is getting ripped out of most active open source projects.
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.
Especially in kernel, is the likelihood of bugs so big that we increase the electricity consumption of everyone using Linux by default?
Sidechannel mitigations are not valid comparison, since it is protection against known, reproducible issues, not against "maybe there is a serious bug".
We should utilize the gains we get in increased computational power instead of wasting everything to inefficient software.
Machines are still not efficient enough to use garbage collected languages alone, which do not have the issues these compiler options mitigate. With efficient software, we can reduce the electricity bill and other resources.
And yet, horribly inefficient scripting languages are a thing. To save time of 1 or 2 developers ONCE, at the cost of countless users' compute capacity, again & again for as long as that software is used.
As long as that is considered acceptable, your argument holds no water.
Current hardware is way, way, waaayy fast enough for 99.999% of uses. Hardened software or not.
It is true that it costs more to hire more skilled developers, and for that reason we suffer. (e.g. Electron).
But even if that happens all the time, it does not mean that my point is invalid. If we want to reduce the energy waste, it starts from software as well.
> Current hardware is way, way, waaayy fast enough for 99.999% of uses. Hardened software or not.
For end-users yes, but not for any cloud computing, servers, et. all where the real computing happens. You can make significant saving in terms of required processors, memory and electricity simply by writing more efficient software. Just one method more to make world greener place.
E.g. compare to increased popularity of Rust and what it means in this context.
On Linux kernel the performance impact was from 2% to up to 25% and size increased around 30%.
On Android there was too much variance, but they note that Google got around 2-3% overhead, which sounds reasonable.
Without hardware acceleration (e.g. Intel CET), it will likely come with great cost. But we are yet to see those benchmarks.
But I would argue that you can take bigger impact for performance on Android or consumer phones anyway, since they are not performing high computation 24/7 usually, and they already have more computation power than most users require.
https://www.duo.uio.no/bitstream/handle/10852/79829/master.p...
I think the affected distros also ended up removing the check over other issues.
Just the HN headline is wrong
It's still discussed in gcc-patches, and the name is proposed as -fhardened. Rebased patch is here: https://github.com/rurban/gcc/tree/fhardened
Would be nice if this was zero instead of pattern.
In other words: a mitigation that initializes all values to 0 may make some uses of uninitialized variables worse than they were before.
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).
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.
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.
And, Rust's only actual loop is an infinite loop. Rust's "loop" syntax is an infinite loop, and both "for" and "while" in Rust are just syntax sugar which the documentation explains how to transform your "for" or "while" into the exact same "loop" that it's going to emit when you do that - they're not merely "equivalent" that's how it really works via a process called "de-sugaring".
Interestingly "loop" is categorically more powerful than "for" or "while" because it has a type, the type of a "for" or "while" is always the unit type, but the type of a "loop" can be anything, for example maybe the loop finds a Goose, and the value of your loop is a Goose, this means to exit the loop we need a Goose and we can't leave the loop without one.
Because of the C++ misfeature, Rust has sometimes run into problems where LLVM is like "Oh, that's an infinite loop, I'll just ignore it" but LLVM is not a C++ compiler. Clang is a C++ compiler so Clang is allowed to obey C++ rules, but LLVM is not, it's supposed to provide an actual infinite loop, for both C and Rust to use.
Lattner started work on Clang in 2006, but LLVM is from 2000..
And sure enough when the Rust project finds bugs in LLVM related to this, there is no "Oh you can't have the semantics we documented, we actually provide exactly whatever C++ says instead for some reason". Sometimes it's a doc bug but most often the problem is that as usual the optimisation passes assumed something that's just not true outside of C++.
Edit: LLVM predates clang, but dragon egg was a thing.
In any case, before C++11 there was no memory model suitable for a system language[1], so it was the obvious solution.
[1] POSIX, OpenMP and the linux kernel all had memory models, but they were either underspecified, not sufficient or both.
C likewise has the C++ Memory Ordering, but not its Forward Progress guarantee. As I wrote earlier, C has infinite loops, they're spelled the way you'd obviously write them in C or C++, but in C they're supposed to actually work (whereas in C++ they are UB). Rust is only different here syntactically, the semantic feature is identical to C's choice.
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)
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.
I almost sympathize with your point, except we are taking about a language where `Type var;` is the explicit way to initialize many variables to a perfectly well defined value: it is the only way to call the no-arguments constructor for a variable on the stack. It's only for non-class types that this has the bizarre behavior of allocating but not setting any value.
It's even worse in a language with templates:
template <class T>
void foo() T {
T local;
return local;
}
Is that really true? Ouch. In many languages that wouldn't feel crazy, but in a language where there's a whole book about initialization https://leanpub.com/cppinitbook that feels kinda silly.
Ideally the syntax `T var();` would have worked as well, but it turns out that it would be ambiguous with declaring a local function named var that takes no arguments and returns a T...
The syntax:
T var{};
Still, reading about it, there are cases where `T var{} ;` will do something different from `T var;`: if T is an aggregate object type, then it will invoke aggregate initialization instead of calling the no-args constructor.
The only catch is, as usual, list-initialiation. You have to hope that T is sane and any list initialization constructor with an empty list is equivalent to the nullary constructor.
Overall I think it's safe to say that the two syntaxes have different semantics, even if they overlap in most cases.
In any case this is also allowed:
T val = T();
class A {
protected:
A() {}
}
class B : public A {}
B x; //ok
B y{}; //not ok, can't access A::A()
Edit: I checked, and you're right - the syntax seems to be fully equivalent in C++17 or later. Great to hear!
edit: it works by making the inheritance protected, as B is no longer an aggregate. The right fix would be to also disqualify B from aggregate status if the base class constructor is unreachable.
Also making both A and B non-empty removes aggregate status, so it is really a dark corner of the language.
Flawless detection of uninitialized reads would require solving the halting problem, which is impossible. So requiring initialization does prevent optimal efficiency of some theoretical programs. Of course, this would only matter in cases where performance was extremely critical (and the whole point becomes moot if the alternative is to automatically zero the memory, which is even worse in this pedantic optimal-performance sense).
You won't write Rust's MaybeUninit<T>::assume_init() in your first program by mistake, whereas the equivalent mistake in C++ happens easily because it's the default.
The situation could be improved in two simple ways. One, you could unify the two meanings, and say that `T x;` allocates space and calls T::T() to initialize the value. The no-args constructor for built-in types already exists and initializes them to 0.
Or, you could also say `T x;` is illegal syntax, one must write `T x = val;` always (or at least when T is a built-in type).
In either case, an escape hatch is needed for allocating uninitialized space on the stack, since there are valid performance reasons for wanting that, in rare cases. But that should be new syntax, it really really shouldn't be the default. So you can still do something like `T x = std::uninitialized();` or whatever the syntax would be to get the current behavior in performance-critical cases, where the tradeoff makes sense.
Personally, especially given C++'s use of templates that don't distinguish between built-in types and classes, I believe the first option makes the most sense, and in fact removes am ugly inconsistency from the language.