#7220 Fedora 28 system-wide change: Hardening Flags Updates
Closed: Fixed a year ago Opened 2 years ago by fweimer.

Change Proposal: https://fedoraproject.org/wiki/Changes/HardeningFlags28

This change requires a mass rebuild.

Please let me know if you need additional information.


Metadata Update from @mohanboddu:
- Issue tagged with: changes, f28

2 years ago

RelEng acknowledges the change and we will include this in the mass rebuild.

Metadata Update from @mohanboddu:
- Issue tagged with: change-ack

2 years ago

Metadata Update from @mohanboddu:
- Issue tagged with: mass rebuild

2 years ago

I see three open questions right now:

  • Do we want annobin annotations for the gcc/glibc bits which are statically linked into all binaries? If we don't do that, can we easily recognize them in annobin coverage checks?

  • We switched to generic tuning for armhfp in redhat-rpm-config only. The gcc defaults still use Cortex-8A tuning.

  • What about the hard-coding of build flags in Python/Ruby/…? Does the build order take care of that?

I'll ask around if there are other issues.

Based on a conversation with @sgallagh @fweimer we are going to just do the mass rebuild and then if needed manual builds may be performed for Python/Ruby and any other interpreted language that also provides the ability to compile native extensions.

We are still waiting to hear back with regard to the armhfp tuning and annobin tuning enablement.

Requested update in IRC at 9:41PM UTC (4:41pm US Eastern)

Mass rebuilds are on hold pending @fweimer getting the information on armhfp and annobin tuning enablement.

Spoke to @fweimer today.

The earliest this may get resolved is Tuesday February 6th.

Mass rebuilds still on hold.

@jkurik Do you see any schedule impact from this delay? Do you think we'll still be good to branch on 2018-02-20?

@jkurik Do you see any schedule impact from this delay? Do you think we'll still be good to branch on 2018-02-20?

The planning of the mass rebuild contains some "spare time" for issues like this. So, I do not expect we need to reschedule the release. However it would be better if RelEng can confirm.

@mohanboddu : do you see the delay (lets say we start the mass rebuild on Wednesday Feb 7th) as impacting the schedule ? The planned end of the mass rebuild is 2018-Feb-20.

We switched to generic tuning for armhfp in redhat-rpm-config only. The gcc defaults still use Cortex-8A tuning.

@fweimer What do we need to do to get the gcc defaults adjusted. I also have an open question around the FPU defaults. I'm not sure if we move to the neon-vfpv3 FPU option if it will use NEON if available and fall back to VFPv3 if it's not available (we have a couple of SoC series that don't have NEON that are still quite widely used). If the neon-vfpv3 will use either/or of those it would likely be worthwhile to move to that too.

https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

@pbrobinson Ping @jakub or file a gcc bug?

Regarding NEON—isn't it single precision only, much like SSE? Then it may not be worth the trouble for Fedora in general. The GCC manual also says that NEON vectorization isn't used by default because it's not IEEE-compliant.

@pbrobinson Ping @jakub or file a gcc bug?

For which bit? The gcc options?

Regarding NEON—isn't it single precision only, much like SSE? Then it may not be worth the trouble for Fedora in general. The GCC manual also says that NEON vectorization isn't used by default because it's not IEEE-compliant.

Yes, neon is a SIMD similar in style to SSE, so I tend to agree, a lot of projects (see pixman/opus/libpng as examples) have fast paths for neon if detected. It was more a query around the defaults as it seemed the docs suggested it was the suggested defaults but I found them to not be overly clear in the recommendations.

I discussed the gcc change which aligns it with redhat-rpm-config with Jakub and updated gcc.spec, so this part is done. The other ARM flag changes should be something for Fedora 29 and probably needs some consideration which boards remain supported etc. (I personally do not want to spend much time on armhfp.)

Regarding the open annobin question, I discussed this with a few toolchain folks, too, and I think we will stick with what we are doing now (no annobin for gcc/glibc), and revisit this for Fedora 29.

@jakub - are all clear from your perspective? @fweimer seems to have given the all clear and we need your sign off as well.

The pending bugs I'm aware of are mostly internal compiler errors, which aren't that severe for mass rebuild, worst case something doesn't rebuild and will need to be rebuilt when the compiler is fixed. One exception (for fedora filed rhbzs) is #1542124 which I could have a fix in rpm form tomorrow, the question is how often it can hit other packages (affects only math code with NaNs).

Metadata Update from @syeghiay:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata