Hi,
http://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags says that "Compilers used to build packages must honor the applicable compiler flags set in the system rpm configuration. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build."
In Fedora, we recently enabled "-fstack-protector-strong" in system rpm configuration - but are all packages using this enhanced hardening feature?
To answer this question (and more), I wrote a program for scanning RPM packages, in order to see which compiler flags were being used to build them.
The "flags-scanner" projects lives on GitHub,
https://github.com/kholia/flags-scanner
Initial scan results are available on the following URL,
https://halfie.fedorapeople.org/flags-scanner/
Now, I need your feedback and cool ideas to improve this project :-)
Thanks, Dhiru
Dhiru Kholia dhiru.kholia@gmail.com wrote:
In Fedora, we recently enabled "-fstack-protector-strong" in system rpm configuration - but are all packages using this enhanced hardening feature?
What's the performance overhead of enabling this for everything?
David
Am 12.08.2014 um 16:01 schrieb David Howells:
Dhiru Kholia dhiru.kholia@gmail.com wrote:
In Fedora, we recently enabled "-fstack-protector-strong" in system rpm configuration - but are all packages using this enhanced hardening feature?
What's the performance overhead of enabling this for everything?
On Tue, 2014-08-12 at 15:26 +0200, Dhiru Kholia wrote:
Now, I need your feedback and cool ideas to improve this project :-)
So first, this is great!
However, the results.txt is very hard to use in order to check if maintainers need to do something.
How about instead, splitting the results into one file per srpm?
Also, maybe in the long-term integrate that somehow with Taskotron, so that the check is run after every build? (or at least for every Bodhi update)
On Tue, 12 Aug 2014, Mathieu Bridon wrote:
On Tue, 2014-08-12 at 15:26 +0200, Dhiru Kholia wrote:
Now, I need your feedback and cool ideas to improve this project :-)
So first, this is great!
Thanks :-)
However, the results.txt is very hard to use in order to check if maintainers need to do something.
Yes, the current report sucks ;(
How about instead, splitting the results into one file per srpm?
I will work on getting this done now.
https://github.com/kholia/flags-scanner/blob/master/scripts/results.py is the script which generated these results.
Also, maybe in the long-term integrate that somehow with Taskotron, so that the check is run after every build? (or at least for every Bodhi update)
Yes, Taskotron is awesome and it would be great to get this scanning stuff into Taskotron itself.
Currently, this is somewhat complicated because I need to patch and build Go (golang) manually. I need to polish my Go patch and push it upstream first.
Dhiru
Hi
On Tue, Aug 12, 2014 at 9:26 AM, Dhiru Kholia wrote:
Initial scan results are available on the following URL,
https://halfie.fedorapeople.org/flags-scanner/
Now, I need your feedback and cool ideas to improve this project :-)
Thanks for working on this. However the information that I am looking for, is any of my packages affected? This list doesn't make it easy to find that info.
Rahul
On Tue, Aug 12, 2014 at 7:26 AM, Dhiru Kholia dhiru.kholia@gmail.com wrote:
Now, I need your feedback and cool ideas to improve this project :-)
I notice that several packages that I maintain that include assembly language files showed up in your results, even though the C portions of those packages are, in fact, built with -fstack-protector-strong. I don't know what can or should be done about this; just thought I'd point it out. (See gmp-ecm for one example.)
Regards,
On Wed, 13 Aug 2014, Jerry James wrote:
On Tue, Aug 12, 2014 at 7:26 AM, Dhiru Kholia dhiru.kholia@gmail.com wrote: Now, I need your feedback and cool ideas to improve this project :-)
I notice that several packages that I maintain that include assembly language files showed up in your results, even though the C portions of those packages are, in fact, built with -fstack-protector-strong. I don't know what can or should be done about this; just thought I'd point it out. (See gmp-ecm for one example.)
Hi Jerry,
I noticed the same earlier and I am not sure how the stack protection works for assembly language files (it seems to be a super hard problem).
Can some compiler / toolchain folks handle this question?
Dhiru
On Wed, Aug 13, 2014 at 09:55:37PM +0200, Dhiru Kholia wrote:
I noticed the same earlier and I am not sure how the stack protection works for assembly language files (it seems to be a super hard problem).
Can some compiler / toolchain folks handle this question?
Long story short: assembly routines which set up their own stack frames won't have any stack protection, so it won't matter.
It would be possible, in theory, to do, but quite unpleasant, given it differs between X86 and elsewhere, and whether you've got TLS implemented or not on X86...
regards, Kyle
On Tue, Aug 12, 2014 at 03:26:07PM +0200, Dhiru Kholia wrote:
Initial scan results are available on the following URL,
https://halfie.fedorapeople.org/flags-scanner/
Now, I need your feedback and cool ideas to improve this project :-)
You should be excluding native OCaml objects. The compiler doesn't have these compiler flags and the language doesn't need them because it doesn't keep strings on the stack and it bounds checks strings anyway.
Rich.
On Thu, 14 Aug 2014, Michael Cronenworth wrote:
On 08/12/2014 08:26 AM, Dhiru Kholia wrote:
Now, I need your feedback and cool ideas to improve this project:-)
You could have saved yourself a few cycles and just used existing tools like readelf. Just an FYI before you devote further time on this...
Hi Michael!
Naw, naw, where is the fun in doing that?
More seriously, I did not have disk space when I started this project and I explicitly wanted a parallel design (parallel extraction on a shared disk is an "interesting" problem).
I have added a "history" section to the repository now,
https://github.com/kholia/flags-scanner
This said, I would love to use libdwarf in the next version of the scanner to reduce the memory usage.
Thanks, Dhiru