Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compiler Options Hardening Guide for C and C++

best.openssf.org

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Compiler Options Hardening Guide for C and C++

#51

Post by plorkyeran »

yellow_lead wrote: post #35
kevin_thibedeau wrote: post #12

Earlier quoted context omitted.

Use -Werror for the build server and have a policy that you can't commit code that generates warnings. That lets you still build locally without having to immediately fix minor warnings that would be a distraction.

How can the build system differentiate between new and old errors? Maybe I misunderstand you, but it seems like that piece is missing.

There are no old warnings because the commits introducing them would have been rejected. Obviously a prerequisite of this is that you get your codebase to the point where it has no warnings. It is sort of like asking how the build server should differentiate between new test failures and existing test failures.

Re: Compiler Options Hardening Guide for C and C++

#52

Post by infamouscow »

infamouscow wrote: post #19
tester756 wrote: post #13

Earlier quoted context omitted.

>And besides, we'll be making similar comments about more your favorite recent languages once they're 38 years old and the field of computing changes. And if you don't believe so, you're in for a very rude awakening. I'm not going to have a problem with critique of my $fav_lang if its designers and implementators underperform. So far they managed to do really good job after >2 decades. >This kind of disdain really sh…

You're replying to a blog post by the OpenSSF on how to harden C and C++ programs offering nothing of substance except childish remarks based entirely on your own subjective opinions. It seems like you're replying to a field of strawmen you've constructed rather than what's being said.

> I can already see the replies that refuse to understand this point.

Admittedly, it took longer than expected.

Re: Compiler Options Hardening Guide for C and C++

#54

Post by dataflow »

soulbadguy wrote: post #33
dataflow wrote: post #32

Earlier quoted context omitted.

The issue is that not every snapshot of a source file is intended to be committed as-is. So it really depends if you're testing code or committing it. When you're debugging something locally, warnings like "unused parameter" or "dead code" become extremely annoying as errors. I need to be able to put "return 0;" in the middle of my function and run it as-is without having to battle the toolchain for five minutes afte…

Of course i don't have the specifics of your usual configuration. But usually this mostly a configuration problem. Dev builds usually don't have -Werror turned on ( or have a very easy way to turn Werror off). In most project i worked on, Werror is informance on the release, and continious test builds. But i do agree that Werror on the code/build/test cycle sound like a pain.

I mean sure, you can work around any problem if you put enough effort into it. For this particular problem, in reality it introduces friction. e.g., one practical problem you face (if you've put sufficient work into your tooling to get to this point) is that your "dev" builds will now miss the cache far more often, because CI is running with different flags. Again, you can work around that... by (for example) spending more money and energy building with different flags. Nothing is impossible to do with enough investment, but these don't come free.

Re: Compiler Options Hardening Guide for C and C++

#55

Post by krylon »

dataflow wrote: post #2

> Developers should additionally use -Werror I've yet to be convinced that this makes sense for every warning. It really depends on the warning IMO. Edit to elaborate: I was mostly referring to non-committed/non-release code not deserving -Werror [1]. However, even for release builds, the story kind of depends on whether your builds are hermetic or not. If your commit also includes a snapshot of all your dependencies…

It's been a long time since I've done anything in C, but I tended to use -Werror -Wall -Wextra and then disable individual warnings/errors if I was sure they were false positives. It can be tedious, but I figured better safe than sorry.

EDIT: For the last couple of years I've used Go almost exclusively, where every warning is an error. It was annoying and tedious at first, but I've come to appreciate it.

Re: Compiler Options Hardening Guide for C and C++

#56

Post by jjgreen »

IshKebab wrote: post #7
dataflow wrote: post #2

> Developers should additionally use -Werror I've yet to be convinced that this makes sense for every warning. It really depends on the warning IMO. Edit to elaborate: I was mostly referring to non-committed/non-release code not deserving -Werror [1]. However, even for release builds, the story kind of depends on whether your builds are hermetic or not. If your commit also includes a snapshot of all your dependencies…

It definitely does for C/C++ . I think there are two reasons: 1. C/C++ build systems tend to be super noisy printing every file that they compile, often long commands and usually in an ugly style, so it is very easy to just miss warnings or to give up even trying to look for them because the output is so verbose. 2. C/C++ tend to produce a lot of warnings that are very annoying to resolve properly and usually not wor…

C/C++ build systems tend to be super noisy printing every file that they compile

  make --quiet

Re: Compiler Options Hardening Guide for C and C++

#57

Post by Someone »

bluGill wrote: post #38
dataflow wrote: post #2

> Developers should additionally use -Werror I've yet to be convinced that this makes sense for every warning. It really depends on the warning IMO. Edit to elaborate: I was mostly referring to non-committed/non-release code not deserving -Werror [1]. However, even for release builds, the story kind of depends on whether your builds are hermetic or not. If your commit also includes a snapshot of all your dependencies…

It makes sense on my project where we have 20 million lines of C++, all covered by it. Only rarely does it stop my build on a I don't care (generally i'm adding temp debugging code that i'll rip out before commiting). If you keep clean code clean it isn't hard to leave werror on and even compiler upgrades are not that painful.

> and even compiler upgrades are not that painful.

…if you do them frequently enough.

A problem with OSS code is that it may lie dormant for years, then get picked up by somebody. Even if they try to compile for the same CPU architecture with the same but newer compiler, getting things to compile with -Werror again can be a challenge. Changing architecture (e.g. integers becoming 64 bit, triggering lots of ‘possible truncation’ errors) or compiler makes it harder.

I don’t think there’s a solution for that problem. Bit rot exists, and the longer you ignore it, the more work it is to get rid of it, and not trying to get rid of it is an invitation for having a serious warning getting drowned in harmless ones.

Re: Compiler Options Hardening Guide for C and C++

#58

Post by n_plus_1_acc »

cozzyd wrote: post #8
tester756 wrote: post #4

Every compiler flag indicates a place where somebody failed. Those are either compiler implementators, language or standard designers, or all of them. >When compiling C or C++ code on compilers such as GCC and clang, turn on these flags for detecting vulnerabilities at compile time and enable run-time protection mechanisms: >-O2 -Wall -Wformat=2 -Wconversion -Wtrampolines -Wimplicit-fallthrough \ >-U_FORTIFY_SOURCE -…

No, it is just respect for backwards compatibility. Though, what might be nice is a shortcut or set of shortcuts for various recommendations e.g. -fopenssf-recommendation or something (and then you can override the parts you don't want afterwards). You could call it -fsafer but that might be too complicated to get everyone to agree on what it means...

That means in a few years, we'll get -freal_safer and -fsafer_v2

Re: Compiler Options Hardening Guide for C and C++

#59

Post by jpc0 »

pabs3 wrote: post #53

I wonder why GCC/LLVM don't set these options by default and leave it up to every single distro and upstream project to set them.

GCC/LLVM want projects to use the latest version of their compilers and if they added all this be default it would break millions of projects compiles.

Those project maintainers won't just add a million flags to make "legacy project 224" compile, they will just use the last compiler it worked with for eternity.

https://olano.dev/2023-11-30-code-is-run-more-than-read/

See that article that's current trending on HN if your response is "they just just fix the errors" or something along those lines, many times there isn't any business case to spend man-hours on something that works fine and has worked fine for decades.

Re: Compiler Options Hardening Guide for C and C++

#60

Post by bluGill »

Someone wrote: post #57
bluGill wrote: post #38

Earlier quoted context omitted.

It makes sense on my project where we have 20 million lines of C++, all covered by it. Only rarely does it stop my build on a I don't care (generally i'm adding temp debugging code that i'll rip out before commiting). If you keep clean code clean it isn't hard to leave werror on and even compiler upgrades are not that painful.

> and even compiler upgrades are not that painful. …if you do them frequently enough. A problem with OSS code is that it may lie dormant for years, then get picked up by somebody. Even if they try to compile for the same CPU architecture with the same but newer compiler, getting things to compile with -Werror again can be a challenge. Changing architecture (e.g. integers becoming 64 bit, triggering lots of ‘possible…

I maintain 20 million lines of C++ and I don't update my compiler very often. There is some pain on update, but it is small and generally easy to fix. Part of this is I already build with gcc and clang (including clang static analisys), and also run cppcheck.

Much of the complaints about upgrading compilers seem to be legacy from gcc 2.x days when they were adding a lot more warnings. Now gcc and clang both do a lot of testing against real world code to see if the warnings are noisy or not before adding them. (either that they are about visual studio or some other compiler I don't use)

Post reply on HN