Security quotes of the week [LWN.net]

Security quotes of the week

Posted Apr 26, 2018 6:13 UTC (Thu) by mjthayer (guest, #39183)
Parent article: Security quotes of the week

> All of a sudden some critical code is optimised away, your code is insecure, and you scramble to figure out how to outwit the compiler once more.

Surely the most reliable way to outwit the compiler's optimiser is simply to turn it off. It would be very nice to be able to mark areas of source code which should or should not be optimised, but failing that, splitting code which should and should not be optimised into separate source files should work for any reasonable compiler, and you even get fine-grained control over which optimisations you want.

Given that most code in most projects is not expected to be performance-critical, I always wonder anyway why people waste time and fossil fuel (and risk uncovering assumptions in their code they would rather not have known about) optimising it build after build.

to post comments

Security quotes of the week

Posted Apr 26, 2018 6:29 UTC (Thu) by mjthayer (guest, #39183) [Link] (2 responses)

> Given that most code in most projects is not expected to be performance-critical, I always wonder anyway why people waste time and fossil fuel (and risk uncovering assumptions in their code they would rather not have known about) optimising it build after build.

Perhaps some day compilers will learn to detect code paths which will not benefit from optimisations and optimise them away...

Security quotes of the week

Posted Apr 26, 2018 7:08 UTC (Thu) by dgm (subscriber, #49227) [Link] (1 responses)

> Perhaps some day compilers will learn to detect code paths which will not benefit from optimisations and optimise them away...

Maybe, but at the cost of making them slower still. In the mean time, programmers could be doing a decent work at this right now, if they just were aware of the problem.

Security quotes of the week

Posted Apr 26, 2018 7:35 UTC (Thu) by mjthayer (guest, #39183) [Link]

> Maybe, but at the cost of making them slower still. In the mean time, programmers could be doing a decent work at this right now, if they just were aware of the problem.

Quite agree there. I was just wondering whether making compilers learn when not to optimise might be more of a fun/challenging task for compiler writers than deciding which code to optimise or not for programmers, and therefore more likely to happen. Then again, optimising build time has become fashionable lately, so perhaps there is hope.

Security quotes of the week

Posted Apr 26, 2018 6:57 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

Because it's easier to turn on the compiler's optimizer by default than it is to profile the code to know what is performance-critical.

Security quotes of the week

Posted Apr 26, 2018 11:41 UTC (Thu) by jwakely (subscriber, #60262) [Link] (1 responses)

> It would be very nice to be able to mark areas of source code which should or should not be optimised

GCC's optimize attribute allows that:

    int slow(int i, int j) __attribute__((noinline,optimize("0")));

Security quotes of the week

Posted May 3, 2018 20:37 UTC (Thu) by nix (subscriber, #2304) [Link]

... but of course this may not prevent the compiler biting you in the arse if you rely on undefined behaviour. Optimization isn't some special magic: it's just doing stuff during translation, and the compiler is quite within its rights to assume that the program is not invoking undefined behaviour in passes other than those that happen to be part of the optimizer. (And it does.)

People who assume that -O0 makes GCC into some sort of "translate the input into the output no matter what undefined stuff we do" machine are operating under a false assumption. No such magic machine exists (nor can it). It appears that what they actually want is a compiler that knows what undefined things they in particular are doing, and does the right thing in those cases. (Good luck with that.)

Can't always turn optimizers off

Posted Apr 26, 2018 11:42 UTC (Thu) by wittenberg (guest, #4473) [Link] (3 responses)

Even with optimization turned off, some compilers do some optimization anyway. It's really hard to find a way to get the compiler to do what you told it to do.

Can't always turn optimizers off

Posted Apr 26, 2018 12:29 UTC (Thu) by excors (subscriber, #95769) [Link] (2 responses)

Even if the compiler does what you told it to do, Spectre demonstrates that the CPU won't do what the compiler told it to do. Maybe we need to give up on the idea of implementing timing-attack-safe cryptographic primitives in software, and do it all in hardware instead.

Can't always turn optimizers off

Posted Apr 26, 2018 14:48 UTC (Thu) by mrshiny (guest, #4266) [Link] (1 responses)

"the CPU won't do what the compiler told it to" proves that you can't always do it in hardware either.

Can't always turn optimizers off

Posted Jun 7, 2018 1:34 UTC (Thu) by JanC_ (subscriber, #34940) [Link]

Especially as fixing the hardware is often not possible (or at least requires hardware vendor intervention).

Security quotes of the week

Posted Apr 26, 2018 17:03 UTC (Thu) by iabervon (subscriber, #722) [Link]

I think the idea of not optimizing code isn't really sensible: when compiling C, there are a lot of choices you have to make that are potentially relevant to performance and there's no clear unoptimized answer. You can certainly tell the compiler not to try to make each path individually as fast as possible, but that just means it's going to produce code that's easy to generate, which still might not conform to your expectations about what's the same.

The right thing is probably to define a standard for uniform performance, and then mark your crypto code that way, and then compilers will do what you've told them you expect.

Compiler writer's views

Posted Apr 26, 2018 20:16 UTC (Thu) by wittenberg (guest, #4473) [Link] (3 responses)

For a loud (if not entirely enlightening) discussion, see the Bugzilla entry: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
In which the compiler writers essentially tell the kernel developers: "tough"

Compiler writer's views

Posted Apr 26, 2018 22:39 UTC (Thu) by jschrod (subscriber, #1646) [Link] (2 responses)

Thanks for this pointer; that is really a scary thread.
I was a aware that too many applications demand -fwrapv nowadays, but didn't know why.

That bug discussion thread is reason to evaluate barring gcc usage in critical conditions.

Anybody can tell if the Clang developers are more reasonable if they receive that kind of problem report?

Compiler writer's views

Posted Apr 27, 2018 6:35 UTC (Fri) by mjthayer (guest, #39183) [Link]

Shouldn't undefined behaviour sanitiser make GCC warn about optimising things away like this?

Compiler writer's views

Posted May 3, 2018 20:40 UTC (Thu) by nix (subscriber, #2304) [Link]

I doubt it. As several people pointed out in that bug report, the complaint was about an optimization GCC has been doing since the *early 90s*, and they were demanding extremely impolitely that it get ripped out as if it were something that had been added the previous week, and ignoring the response that it just isn't as simple as that.