5 ms·
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 fail
by nlewycky 3y ago
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 slots, etc., go on the safe stack. This has such a small performance impact, you'll measure improvement and slowdown in equal measure just because of the uncontrolled effects this has on memory layout. The main downside is that presently you can't enable it when building a shared object. Docs: https://clang.llvm.org/docs/SafeStack.html https://clang.llvm.org/docs/SafeStack.html
Also! While the usual sanitizer runtime libraries aren't security hardened for use in production environments, but for UBSan there's -fsanitize-minimal-runtime which switches to a different runtime library that is intended for this purpose (or use -fsanitize-trap=... instead, which executes an illegal instruction on error). Note that if your program terminates with a UBSan error, an attacker who can check whether your program terminated or not could use that as a primitive to leak data, so consider the security impact on your use case carefully. UBSan has a quite small performance impact when building with optimization, so you could deploy to production with it enabled, or parts of it enabled.
- synergy20 3y agovery informative,also there is __GLIBCXX_DEBUG etc to catch errors sanitizer can not detect
- dundarious 3y agoIt'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.
- dwheeler 3y agoWe 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).
- synergy20 3y agotypically for production releases I have -DNDEBUG, which will disable -D_GLIBCXX_ASSERTIONS
- dwheeler 3y agoThe `-fsanitize=safe-stack` and `-mshstk` options are already under discussion: https://github.com/ossf/wg-best-practices-os-developers/pull/311 https://github.com/ossf/wg-best-practices-os-developers/pull... ; see also https://github.com/ossf/wg-best-practices-os-developers/issues/267 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/issues/326 https://github.com/ossf/wg-best-practices-os-developers/issu...