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

11–20 of 72 posts

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

#11

Post by cozzyd »

kevin_thibedeau wrote: post #10
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 -…

It's a sign that the compiler devs value backward compatibility with earlier incarnations that lacked such programmer aids. These are features that come with an associated cost and you don't pay that price in C without explicitly choosing it.

Or worse, your 30 year-old program that used to compile and work just fine no longer compiles and you now have to figure out why.

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

#12

Post by kevin_thibedeau »

olig15 wrote: post #6
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…

Why, what’s the alternative - leave the warnings hanging around? I work on a multi million loc.C++ codebase that used -Werror. If we turned it off, the codebase would be full of warnings in hours.

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.

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

#13

Post by tester756 »

infamouscow wrote: post #9
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 -…

This kind of disdain really should be put to rest. All it does is alienate people that were on the fence, or maintain projects with different goals in mind. 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 can already see the replies that refuse to un…

>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 should be put to rest. All it does is alienate people that were on the fence, or maintain projects with different goals in mind.

I believe that languages and compilers should go way beyond just "enable things to be possible", but they also should be user friendly and be safe/sane by default.

That's why I'm critiquing this chaos. Don't you see this long ass list:

">-O2 -Wall -Wformat=2 -Wconversion -Wtrampolines -Wimplicit-fallthrough \ >-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 \ >-D_GLIBCXX_ASSERTIONS \ >-fstrict-flex-arrays=3 \ >-fstack-clash-protection -fstack-protector-strong \ >-Wl,-z,nodlopen -Wl,-z,noexecstack \ >-Wl,-z,relro -Wl,-z,now"

It is insane. Just because someone values different things then it doesnt make it flawless.

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

#14

Post by cozzyd »

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…

What would be more useful would be some better UI for displaying the warnings.

e.g. -Woutput_warning_[html,json,text]=DIRECTORY_TO_OUTPUT_TO or something, which would create a output file per compilation unit that displayed the warnings in a friendlier way.

It's possible something like this exists and I'm unaware...

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

#15

Post by david2ndaccount »

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…

Indeed, -Werror doesn’t make sense, but specifying specific errors (like -Werror=return-type to prevent forgetting to return a value from a function) is very, very necessary.

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

#16

Post by kevin_thibedeau »

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…

I wouldn't be so careless about sign conversion warnings. C can silently convert signed integers to unsigned and that can cause mayhem. I inherited a codebase that was exhibiting a classic signed conversion problem when a temperature reading dropped below 0°C. I simply turned on -Wextra and it flagged all the culprits with implicit conversion to unsigned. Throw in some casts and it was resolved.

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

#17

Post by r2vcap »

olig15 wrote: post #6
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…

Why, what’s the alternative - leave the warnings hanging around? I work on a multi million loc.C++ codebase that used -Werror. If we turned it off, the codebase would be full of warnings in hours.

If you're working in a controlled environment, such as proprietary software with a fixed number of toolchains or a few OSS projects like Chromium that use their own fixed toolchain, then it makes sense to turn on -Werror. However, most OSS projects deal with tons of different compilers, so it is not possible to enforce -Werror, as different compilers and versions handle warnings differently.

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

#18

Post by soulbadguy »

tester756 wrote: post #13
infamouscow wrote: post #9

Earlier quoted context omitted.

This kind of disdain really should be put to rest. All it does is alienate people that were on the fence, or maintain projects with different goals in mind. 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 can already see the replies that refuse to un…

>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…

> I believe that languages and compilers should go way beyond just "enable things to be possible", but they also should be user friendly and be safe/sane by default.

Everyone one wants sane and safe default, and ease of use etc... etc... The questions here is more nuance is about should an existing ( and dare i say very successful) language navigate the need for backward compatibility with with security and UX concerns.

> That's why I'm critiquing this chaos.

Critiquing a design is fair. Critiquing without understanding the context and constraints around the said design is not particularly helpful and tend to rub people the wrong way. Adding platitudes like "user friendly and be safe/sane" gets old even faster.

> It is insane.

Not really... it's just the results of very very constrained design space. Reality is messy

>

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

#19

Post by infamouscow »

tester756 wrote: post #13
infamouscow wrote: post #9

Earlier quoted context omitted.

This kind of disdain really should be put to rest. All it does is alienate people that were on the fence, or maintain projects with different goals in mind. 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 can already see the replies that refuse to un…

>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.

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

#20

Post by soulbadguy »

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…

genuilely curious : Do you have a class of warnings or a warning in particular you think should be left out of Werror by default ?
Post reply on HN