This is a tracking bug for Change: Aarch64 Pointer Authentication & Branch Target Enablement For more details, see: https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication Arm Pointer Authentication (PAC) is a method of hardening code from Return Oriented Programming (ROP) attacks. It uses a tag in a pointer to sign and verify pointers. Branch Target Identification (BTI) is another code hardening method, where the branch/jump target is identified with a special landing pad instruction. Outside of some system support in glibc+kernel, packages gain the additional hardening by compiling with the -mbranch-protection= flag available in recent versions of GCC. In particular -mbranch-protection=standard enables both BTI and PAC, with backwards compatible to armv8.0 code sequences that activate on v8.3 (PAC) & v8.5 (BTI) enabled Arm machines.
We should hold off on getting the flag in until gcc 10.2 lands as there are a couple PAC fixes in 10.2 we will want.
I went with the KISS method, and just added it to the optflags. The pull request is here: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/97 There is a build here: https://koji.fedoraproject.org/koji/taskinfo?taskID=47357962 The gcc bug that should be integrated before the mass rebuild is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 The fix has been backported to gcc 9/10.1 and is in the 10.2 branch as well. Its not clear to me if fedora is planning on moving to 10.2 before the rebuild, otherwise I can create a PR for the 10.1 backport.
As far as I can tell, this change requires special builds of gcc and glibc: https://sourceware.org/pipermail/libc-alpha/2020-July/116611.html As a result, the mass rebuild will NOT complete this change.
I've checked with Szabolcs, and its his understanding too that simply building gcc with mbranch-protection=standard will do what we want.
Branching F33 Change Tracker bugs. Today is the code complete (testable) deadline. All bugs should be at least in MODIFIED state by now to indicate they are testable.
Large parts of this are in place, I need to test/validate functionality, but I think the distro has definitely been "modified" so that is my error for not setting the bz state.
Yesterday we reached the Code complete (100% code complete) deadline for Fedora 33 Changes. If your Change is complete, please set this tracking bug to ON_QA. If you need to defer this Change to Fedora 34, please let NEEDINFO me. As a reminder, we are now in the Beta Freeze. If you need to land package updates, please propose it as a Freeze Exception at https://qa.fedoraproject.org/blockerbugs/propose_bug
I've been testing this on a v8.0 machine (honeycomb, rpi4) as well as a v8.5 model, and everything looks reasonable at the moment.
Closing tracking bugs for F33. If your change didn't make it into F33 for some reason, please reopen this and NEEDINFO me.
I compared booting Fedora-Cloud 32 and 33 aarch64 images in qemu-system-aarch64. F32: Startup finished in 4.518s (kernel) + 9.704s (initrd) + 13.090s (userspace) = 27.313s F33: Startup finished in 4.755s (kernel) + 19.132s (initrd) + 17.163s (userspace) = 41.051s Even more significant slowdown in qemu-aarch64-static, when running 'yum repolist' F32: real 0m1.455s F33: real 0m10.371s Could Pointer Authentication & Branch Target Enablement be the cause of a significant slowdown in Fedora 33+ aarch64 QEMU emulation?