So initial fededback: historically FPC has just asked that these changes be added to CFLAGS which applies to every program. We'll need some information about why this case is different. I take it that FESCo has looked into the matter and has some data and rationale here. If those could be added to this ticket/wiki page that would be a good place to start.

Having overheard the fesco meeting, turns out this isn't practical to be applied globally (for various reasons), but could be reasonable to apply carefully to some small subset of security-sensitive pieces of the distro.

Who decides what's "security sensitive" ... and how?

{{{
Perhaps this could be anything with suid or cap_sysadmin binaries that has a service file?
}}}

Which implies you don't know ... which scares me a lot.

Also why "isn't practical" ... because it breaks assumptions in some C code? Because it makes some things slower?

I'd be more inclined to have a rule that says "everything should use PIE", but here are the reasons why/how you can opt. out.
OR to have something which is an opt. in process, and have the security people convince who they want to opt. in (but anyone else can too).

Replying to [comment:3 james]:

Who decides what's "security sensitive" ... and how?

{{{
Perhaps this could be anything with suid or cap_sysadmin binaries that has a service file?
}}}

Which implies you don't know ... which scares me a lot.

Also why "isn't practical" ... because it breaks assumptions in some C code? Because it makes some things slower?

I'd be more inclined to have a rule that says "everything should use PIE", but here are the reasons why/how you can opt. out.
OR to have something which is an opt. in process, and have the security people convince who they want to opt. in (but anyone else can too).

Indeed. Given that there are security vulverabilities in all manner of code from the kernel to daemons to games, I second this.

our (fpc) job is only to come up with the packaging guideline, not to decide particularly which pkgs it applies to (that's for fesco)

As for details about why this isn't to be applied globally, please do read up in the fesco ticket.

Replying to [comment:5 rdieter]:

our (fpc) job is only to come up with the packaging guideline, not to decide particularly which pkgs it applies to (that's for fesco)

As for details about why this isn't to be applied globally, please do read up in the fesco ticket.

Gathering from the FESCO ticket, the performance penalty of PIE on startup of a large app is around .5 seconds. Is that really that big of a deal? I know we're chasing faster boot times, but aren't the security arguments worth it? Just curious.

That said, if it's to be mandated for a specific list, and not a category of packages, why have a guideline, why not just do it? If it's a category, there exists the possibility of a package review for a new pacakge in that category. If it's a static list, there doesn't.

While the runtime cost of PIE is smaller on x86_64 compared to i686 as you don't lose
one extra register and don't need to setup PIC pointer in most of the routines, it is
still very significant (extra indirection for many variable accesses). Furthermore,
PIEs aren't prelinkable, so you will loose up to half a second or so on startup of
larger apps. So I'm strongly against forcing it to all or most executables.

This seems to be the rationale for not forcing on everything ... which just seems awesome for creating arguments about if security or performance is more important for ldap etc. ... sigh.

our (fpc) job is only to come up with the packaging guideline, not to decide
particularly which pkgs it applies to (that's for fesco)

I'm happy for us to change the current CFLAGS guideline to say roughly "here's how you should do it if you want PIE exes and here's how you should do it if you don't" ... and then FESCO can "force" certain packagers to use the PIE version.

The original kind of "security" wording seems like a giant problem waiting to happen though.

So... the only thing in the fesco ticket is Jakub's comment about what resources are being consumed: https://fedorahosted.org/fesco/ticket/563#comment:17 Kylem was supposed to have run benchmarks at one point but I don't see those results.

Jakub's comment lists the .5s startup cost which doesn't seem like a big deal and also that extra registers are being consumed and extra indirection when accessing variables. No numbers on how these affect the runtime performance, though. If we could get some of that information it might be helpful if we're going to write guidelines on which packages need to do this.

Going a bit more broadly, james raises a good point, though. In recent history, FPC has tossed questions of which specific packages are required to do certain things or not do certain things to fesco instead of deciding it themselves. The makeup of FPC hasn't changed since the last time we did that so a vote would probably go the same in this instance.

So an FPC Guideline should probably be something like:

All Fedora Packages should use the default Fedora Compilation flags as listed on the http://fedoraproject.org/wiki/Packaging/RPMMacros#Build_flags_macros_and_variables page. Overriding these flags for performance optimizations (for instance, -O3 instead of -O2) is generally discouraged (if you can present benchmarks that show a significant speedup for this particular code, this could be revisited on a case-by-case basis). There are certain, security related flags that are commonly allowed. These flags may degrade performance slightly but the increased security can be worthwhile for [[list criteria here]] programs.

[[insert table of flag sets to add, what they actually do, and the potential performance impact]]

To add these flags, use something like this:

export CFLAGS="%{optflags} -Wl,-z,relro,-z,now"
%configure
make CFLAGS=$CFLAGS

FESCo maintains a list of packages that they require to have certain additional compilation flags enabled. See [instead page name here] for which packages require which flags.

Feel free to take that as the start of a draft.

I'm going to be traveling next week, but just a status update here:

I've started up a draft page, but I would like to have another discussion with fesco on exactly what we want to do.

https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags
is the very rough draft.

There's some outstanding questions there. :)

So, I would suggest tabling this for now here, and I will ping back here when the draft is ready for discussion. Thanks.

existing draft text (missing macros and FESCo list link) approved, waiting for missing pieces for final approval (+1:5, 0:0, -1:0)

Final draft approved (+1:6, 0:1, -1:0)

Announce text:

The section of the Packaging Guidelines regarding Compiler Flags has been updated and improved, most notably, to document handling of PIE enabled packages.