Issue #1153: Adding new extra hardening build flags for debugging - fesco

fesco

#1153 Adding new extra hardening build flags for debugging

Closed None Opened 10 years ago by halfie.

== Proposal ==

GCC 4.8.1 in Fedora 19 (and higher) supports AddressSanitizer (ASAN) and ThreadSanitizer features.

AddressSanitizer is a fast memory error detector (http://clang.llvm.org/docs/AddressSanitizer.html).

ASAN can detect the following types of bugs:

Out-of-bounds accesses to heap, stack and globals
Use-after-free
Use-after-return (to some extent)
Double-free, invalid free

ThreadSanitizer is a tool that detects data races (http://clang.llvm.org/docs/ThreadSanitizer.html).

I am proposing to add support in Fedora 20 for building package with these features (ASAN, TSAN) on an on-demand basis.

== Benefits ==

Catch potentially "embarrassing" bugs (i.e. writing 4 bytes instead of 2, use-after-free) during development, testing and packaging stages.
https://bugzilla.gnome.org/show_bug.cgi?id=703991
https://github.com/karelzak/mutt-kz/issues/43
ASAN is super useful and has been heavily used by bug-bounty-hunters (and regular folks) to analyse Firefox and Chromium extensively.

Adding such support does not affect anything at all unless the SPEC files are explicitly modified to use the new flags. So this is a small self-contained change with no end-user visible and usable artefacts.

== Details ==

I have patched redhat-rpm-config package to enable building packages with ASAN / TSAN. I have added "_AddressSanitizer_build" and "_ThreadSanitizer_build" flags and turning them on enables ASAN and TSAN respectively. See https://bitbucket.org/dhiru/redhat-rpm-config/commits/all for details.

My patch is tiny, safe and does not affect anything unless the SPEC files are explicitly modified to use these new flags.

"-fsanitize=address" is incompatible with -fsanitize=thread and vice-versa. They are mutually exclusive.

It goes without saying that these new extra hardening flags should not be used to build production RPMS.

It would be great if we could add this functionality to redhat-rpm-config package in Fedora 20.

Additionally, it is likely that various upstream projects will try to become more ASAN friendly soon,

It would be nice to see Fedora taking a lead in becoming a "Grade A+" platform for doing ASAN and other hardening stuff.

I am currently working on writing step-by-step documentation for the packaging and QA folks. I am hoping that the QA folks will be able to use this feature heavily during their regression, coverage and stress testing runs.

mitr commented 10 years ago

QA running specially instrumented builds would be... new. Or would we consider enabling the sanitizers unconditionally for rawhide, like the kernel team using debug configurations? That would probably imply either two mass rebuilds during a release cycle, or two build targets.

(Procedural note: The RPM macros aspect can be handled by the FPC without FESCo involvement; the above discussion about sanitized builds probably belongs to FESCo, but also expands what halfie was asking for, so perhaps shouldn't block the FPC process.)

sgallagh commented 10 years ago

Also, while I am ''always'' in favor of improving security with build-flags, I must note that we are now well-past the Fedora 20 Change Submission deadline, so I recommend working with Panu (the redhat-rpm-config maintainer) towards having this ready as a Fedora 21 Change.

misc commented 10 years ago

Ideally, it would be nice to have it enabled on demand, like MALLOC_CHECK. I suspect this is not doable at all, but could be nice to ask to upstream ( even if I think they already know ).

Discussing on irc with halfie, maybe what should be done is to have a separate rebuild of the distribution enabling ASAN, and then have a test day using this separate distribution, with the objective of finding as much problem as possible.

Enabling by default is no-go due to runtime penalty, and I guess few people will enable it if this requires rebuild, except for very motivated QA people.

halfie commented 10 years ago

Replying to [comment:1 mitr]:

Or would we consider enabling the sanitizers unconditionally for rawhide, like the kernel team using debug configurations? That would probably imply either two mass rebuilds during a release cycle, or two build targets.

"Typical slowdown introduced by AddressSanitizer is 2x." I was told that people actually use rawhide to get work done. So, slowing down rawhide by 2x (or even more) might not be an acceptable / practical option.

halfie commented 10 years ago

Replying to [comment:3 misc]:

Enabling by default is no-go due to runtime penalty, and I guess few people will enable it if this requires rebuild, except for very motivated QA people.

Agreed.

Discussing on irc with halfie, maybe what should be done is to have a separate rebuild of the distribution enabling ASAN, and then have a test day using this separate distribution, with the objective of finding as much problem as possible.

This sounds like a good practical idea!

halfie commented 10 years ago

Bugzilla link is [https://bugzilla.redhat.com/show_bug.cgi?id=993502]