I'm surprised there isn't already a #pragma directive to say to the compiler: "Don't be clever here, just do as I say".

I'd have thought making every function and variable volatile for whatever it is you're trying to do would be enough to make the compiler not optimise out booleans, but not even then it seems.

Also, there is a #pragma GCC optimize ("-O0")... that didn't work either?

That is still unsafe. If they want certainty, they should provide assembly implementations for each architecture.

"... they should provide assembly implementations for each architecture."

Came here to say the same thing.

There is and I have had to use it for totally non crypto/security reasons (forcing ctor functions to run in static links.)

[gcc manual 6.62.15 Function Specific Option Pragmas]

#pragma GCC push_options

#pragma GCC optimize ("O0")

int sensitive (...) {

....

}

#pragma GCC pop_options

These attributes can also be applied with the function __attribute__() syntax as someone has also noted.

[6.31.1 Common Function Attributes]

-O3 is known to be dangerous, though.

Back in the days, it was a sure way to mess up the HEP simulations we were running.

There is a section in the Gentoo handbook that specifically warns users against setting -O3 globally in the make.conf $CFLAGS. Linux From Scratch also warns against using it in their handbook. Even the GCC manual itself warns that -O3 can and will break some code because it is so aggressive.

GCAIC, the GNU Compiler AI-enhanced Collection

Is that collection on the blockchain?

It's fully agentic and on-chain with zero trust.

... as a service....

For an extra monthly subscription fee

And the look of real wood.

The problem here is that programmers are trying to get the compiler to do something it is not required to do - the C Standard defines an abstract machine that is used to execute the program, and any attempt to "force" it to do things is likely to fail. Temporal behaviour is not part of the specification, so there are no guarantees as to what will happen if the programmer is trying to write isochronic code (where the execution paths all take the same amount of time).

Any infeasible paths are likely to be removed during optimisation (which are effectively a set of mathematical transformations that are applied to the code), and "turning them off" may not remove all optimisation. Compilers are also free to "mess" with values, as long as the code behaves "as if" it was what was intended. For example, have a look at [1]this Compiler Explorer example that shows Clang "changing" the values of enum constants and "forgetting" to call an error handler (note that the code produced by Clang is fully Standard Conforming). Reducing the optimisation level to '0' does 'fix' the code (it is still broken, but the infeasibility and undefined behaviour to not manifest).

The example also shows a function that erases a password buffer before it is returned to the memory pool. The write operations used to erase the buffer are strictly unnecessary writes as the values written are never subsequently used as they are followed by a call to 'free' (and this did use to happen). However, compilers are now taking this sort of use case into consideration to help programmers - even when the behaviour is not required by the standard.

[1] https://godbolt.org/z/bMsevabdo

"Meusel ran a constant-time implementation through GCC 15.2 (with -std=c++23 -O3"

The -O3 is telling the compiler to to optimization and then he is complaining about it doing optimizations?

Most of the suggested options are, well dumb, they are trying to trick the optimizer with a hope that it won't get more intelligent in a later release, if you don't want the optimizer to optimize than the best thing to do is explicitly tell it not to - looks like that functionality exists by declaring the function with __attribute__((optimize("O0")))

"Meusel ran a constant-time implementation through GCC 15.2 (with -std=c++23 -O3"

The -O3 is telling the compiler to to optimization and then he is complaining about it doing optimizations?

Exactly. He told the compiler explicitly to do whatever it can to make the code run faster, and then bitches about the code running faster.

I've recently discovered a dangerous flaw in the design of my car! When I take my foot of that pedal and press it on that other pedal the car suddenly STOPS!! This could happen right in the middle of the freeway!!! People could be killed!!!! Something must be done — Think Of The Children!!!!!

That said, even when you "turn off" optimization with -O0, the C standard still allows the compiler to do anything it wants that still produces "correct behavior". The definition of "correct behavior" does NOT (and never has) included constant (or even predictable or consistent) execution times.

Looping through each character is inefficient, especially with long keys / books for passwords. Wouldn't it be better to use a constant-time, cryptographically secure hash comparison?

Also insecure because an attacker can try each character in turn untill they find the correct one.

Who is the security guy in the article and what are his credentials?

We should not be comparing passwords character by character since we should not store passwords in clear text -- as it is a nightmare if/when some cracker gets hold of the password database.

We should store a hash or message digest of the password and when testing a candidate password hash/md it and compare that. Converting to a hash/md means reading *all* of the password and then comparing the result will give you no clue as to which pass of the candidate password is bad; so a timing attack will not work.

Anyway: the first step of authentication will be getting the password hash/md, very likely from a database. The time to access from a database will take vastly longer than character by character comparison.

So: I do not understand. Can someone please explain.

Thanks

@Alain_Williams

Yup......explanation is simple. Namely.....bad guys attended the FOSDEM talk........so the examples were MISDIRECTION!

Probably if legitimate programmers want THE REAL SCOOP on GNU C, they need to pay extra!

So.....not only misdirection, but a marketing ploy to get more revenue.

Is this paranoid enough? Probably not!

No need to pay extra when the source code is free.

Good point!

But getting the source code....and UNDERSTANDING the source code might be two different things!

How do you compare hashes that doesn't fit wholly in a CPU register? And if the hash is stored as a string, and the code still does a string comparison?

Hashes do not allow to reconstruct the plain-text easily - but if you can probe a stored hash directly to find a match.... is not different than comparing a plain text password - the elapsed time will tell you how far you went.

This was clearly a simplified example. No one has done this particular thing for thirty years. Of course, no one has used O3 in this context since it came out, so maybe he is a time traveler?

It's been a long time, but doesn't Fortran have a rule that says something about evaluation inside parentheses cannot be moved outside of those parentheses? I believe it related to evaluation of expressions involving very small floating point values.

Because of that I long ago put a 'strict' construct into my Zed programming language. The intent is that stuff directly within the range of the construct must be executed as they appear. There were a couple of provisos needed, but something like this would seem to be more reliable and universal than things like setting the optimization level of an entire C function. Maybe for C30? (Kidding!)

So ... security is hard?

Who'd have thought it?

Hopefully only a straw man for this example otherwise I am not too sure I would want M. Meusel lurking in the vicinity of my code.

I assume (purely because I would leave this sort of coding to those that know how to do it safely) that the clear text password would be read into secure memory (mlocked/mprotected ?) in its entirety before being hashed etc and verified with the clear text obliterated at the earliest opportunity.

The timing for a successful verification would be contrived to be indistinguishable from a rejection (whether rejected on the basis of an invalid identity or incorrect password or whatever.)

This stuff is hard enough without having to worry about compilers' enthusiastic optimisations. Pehaps GCC might be augmented with a —Ocryptographic_sensitive flag, attribute or pragma to render the code deterministic with respect to timing with code generation skewed towards the security concerns.

"good C programmers know to fear the aggressive optimization of Boolean logic, which can be hazardous to their finished products". The optimizations described in the linked article are quite different from the problems facing cryptographers. The optimizations in the linked article are just wrong, and a compiler that does them is not conforming to the C standard. The problem for cryptographers is that they want to specify behaviour that isn't part of the C language, namely timing.

As someone who spends a lot of time compiling of C into binary patches, I can say that GCC is a real pain in the ass, more than any other compiler. There are some optimizations and transformations it does to the code that can't be turned off. I use C as a kind of machine-independent assembly language and it's the perfect language for that purpose, with most simple straightforward compilers. But GCC always tries to be clever and abstract the code in the way that high-level languages do and the resulting code is often more instructions than necessary, more stack usage and generally reorganizing constructs in the most awkward way possible. I just want it to do what it's told and and turn a simple piece of C into a simple piece of assembler. I think the GCC developers have their heads in the high-level language world and don't understand the use-cases of embedded developers.