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

41–50 of 72 posts

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

#41

Post by saagarjha »

soulbadguy wrote: post #28
saagarjha wrote: post #25

Earlier quoted context omitted.

Even projects with a “stable” set of targets have too much churn for this to be practical. Just because you support “latest macOS” doesn’t mean my build should fail if I’m on a beta build ahead.

> Even projects with a “stable” set of targets have too much churn for this to be practical. Are you speaking here from experience ? Because mine has been quite different.

Yes, I typically run toolchains that are slightly ahead or different than the one that is actually used in CI. I don't think it is reasonable to think that projects will be using it, though they often do appreciate me testing it early for them.

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

#42

Post by saagarjha »

soulbadguy wrote: post #30
saagarjha wrote: post #26

Earlier quoted context omitted.

A couple are kind of annoying, such as sign conversion/comparison.

Most security/safety feature either on the language or the tooling side are are some what annoying since by definition they tend to add constrains to one workflow. The real question is whether they introduce more pain than they safe in average.

Right, I understand that. I'm overwhelmingly in support for most warnings. I just think that a handful don't have good tradeoffs or are not necessarily the most valuable for many projects.

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

#43

Post by not2b »

ploxiln wrote: post #34
olig15 wrote: post #6

Earlier quoted context omitted.

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.

The alternative is to fix warnings! You don't have to completely fail the build, to have the good engineering sense to fix warnings. Unless you never build locally? And never look at a build log? You really never improve code if Werror doesn't force you to? It's really obnoxious to also immediately and completely fail the build for someone who wants to use an updated compiler, or wants to compile for a different arch…

Turning on -Werror means that once the warnings are eliminated, they stay eliminated, and a developer who adds code that produces a warning has their checkin rejected. If it isn't used the number of warnings will just grow and grow.

You're right, updated compilers that have more warnings are an issue, and that's why the document recommends that -Werror be used during development but not in the shipped code (for open source projects), so the recipient of the code isn't blocked by the problem you cite.

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

#44

Post by synergy20 »

nlewycky wrote: post #5

Not mentioned in this doc, I like using `-fsanitize=safe-stack` in release builds. Accesses to stack allocated arrays which have non-safe offsets (compiler fails to prove all accesses are in bounds) cause the object to be allocated on the unsafe stack, elsewhere in memory where overruns can only touch other things on the unsafe stack. Provably in-bounds accessed variables, return addresses, compiler generated spill s…

very informative,also there is __GLIBCXX_DEBUG etc to catch errors sanitizer can not detect

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

#45

Post by duped »

I'm not really convinced by the arguments that rpath should be discouraged wholesale. That seems like pessimistic/paranoid advice. It's very useful for people distributing executables to vendor their libraries and for that to take precedence over the default loader paths.

I see the argument for setgid/setuid binaries. That's a better argument against setgid/setuid permissions (doubly so if they're not statically linked) than against rpath.

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

#46

Post by cozzyd »

saagarjha wrote: post #22
cozzyd wrote: post #14

Earlier quoted context omitted.

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

This is what an IDE can help with ;)

yeah sure, then I'll get a bunch of errors about stray j's and k's :)

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

#47

Post by dundarious »

synergy20 wrote: post #44
nlewycky wrote: post #5

Not mentioned in this doc, I like using `-fsanitize=safe-stack` in release builds. Accesses to stack allocated arrays which have non-safe offsets (compiler fails to prove all accesses are in bounds) cause the object to be allocated on the unsafe stack, elsewhere in memory where overruns can only touch other things on the unsafe stack. Provably in-bounds accessed variables, return addresses, compiler generated spill s…

very informative,also there is __GLIBCXX_DEBUG etc to catch errors sanitizer can not detect

It's _GLIBCXX_DEBUG (one leading underscore) and it's not a good idea to use it in release builds, unlike the original comment's proposal.

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

#48

Post by dwheeler »

nlewycky wrote: post #5

Not mentioned in this doc, I like using `-fsanitize=safe-stack` in release builds. Accesses to stack allocated arrays which have non-safe offsets (compiler fails to prove all accesses are in bounds) cause the object to be allocated on the unsafe stack, elsewhere in memory where overruns can only touch other things on the unsafe stack. Provably in-bounds accessed variables, return addresses, compiler generated spill s…

The `-fsanitize=safe-stack` and `-mshstk` options are already under discussion: https://github.com/ossf/wg-best-practices-os-developers/pull... ; see also https://github.com/ossf/wg-best-practices-os-developers/issu...

The idea of using `-fsanitize-minimal-runtime` is interesting. I don't have any direct experience with that option. I've created an issue to investigate maybe adding that to the guide. Thanks for the tip! https://github.com/ossf/wg-best-practices-os-developers/issu...

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

#49

Post by dwheeler »

synergy20 wrote: post #44
nlewycky wrote: post #5

Not mentioned in this doc, I like using `-fsanitize=safe-stack` in release builds. Accesses to stack allocated arrays which have non-safe offsets (compiler fails to prove all accesses are in bounds) cause the object to be allocated on the unsafe stack, elsewhere in memory where overruns can only touch other things on the unsafe stack. Provably in-bounds accessed variables, return addresses, compiler generated spill s…

very informative,also there is __GLIBCXX_DEBUG etc to catch errors sanitizer can not detect

We did include `-D_GLIBCXX_ASSERTIONS` but we intentionally did not include `-D_GLIBCXX_DEBUG`, because we've been focusing on production releases.

The current plan is to add more information distinguishing between production code and instrumented test code, and adding options specific to each. There are many options that might make sense for instrumented test code that don't make sense for production code (and vice versa).

Post reply on HN