From Fedora Project Wiki
 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Change Proposal Name Aarch64 Pointer Authentication & Branch Target Enablement=
= Aarch64 Pointer Authentication & Branch Target Enablement =


== Summary ==
== Summary ==
Line 16: Line 16:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF33]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->  
<!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->  
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
<!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
<!-- Select proper category, default is Self Contained Change -->
<!-- Select proper category, default is Self Contained Change -->
[[Category:SystemWideChange]]
[[Category:SystemWideChange]]
Line 34: Line 33:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2403 #2403]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1847148 #1847148]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/512 #512]


== Detailed Description ==
== Detailed Description ==
Line 54: Line 53:
Assure their packages continue to compile and pass unit/integration/etc tests on v8.0 hardware. Continue to monitor runtime problems on v8.3+ for bugs, vs exploit attempts.   
Assure their packages continue to compile and pass unit/integration/etc tests on v8.0 hardware. Continue to monitor runtime problems on v8.3+ for bugs, vs exploit attempts.   


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: [https://pagure.io/releng/issue/9505 9505] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
Line 85: Line 84:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Testing falls into two categories. Assuring that the packages continue to work on existing arm v8.0 hardware without PAC, and testing on PAC enabled hardware. For the most part the expectation from the fedora community is that package maintainers assure their packages continue to work on existing systems. PAC hardware will be in limited supply during the F33 development cycle, so the expectation is that owners of that hardware will perform more complete systemwide testing and report any defects found against the packages in question along with fixes or hardware access.
Testing falls into two categories. Assuring that the packages continue to work on existing arm v8.0 hardware without PAC, and testing on PAC+BTI enabled hardware. For the most part the expectation from the fedora community is that package maintainers assure their packages continue to work on existing systems. PAC+ hardware will be in limited supply during the F33 development cycle, so the expectation is that owners of that hardware will perform more complete systemwide testing and report any defects found against the packages in question along with fixes or hardware access.


== User Experience ==
== User Experience ==
Line 106: Line 105:


== Contingency Plan ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Build affected packages with explicit compiler flags disabling the feature. Worse case the top level rpm macros reversion, and a rebuild of effected packages.
Build affected packages with explicit compiler flags disabling the feature. Worse case the top level rpm macros reversion, and a rebuild of effected packages.
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
Contingency deadline:  Beta target.
Contingency deadline:  Beta target.
Line 123: Line 121:


Further reference:  
Further reference:  
https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software/return-oriented-programming
* https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software/return-oriented-programming
https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-on-armv8-3.pdf
* https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authentication-on-armv8-3.pdf
https://www.usenix.org/system/files/sec19fall_liljestrand_prepub.pdf
* https://www.usenix.org/system/files/sec19fall_liljestrand_prepub.pdf
https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf
* https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf
https://lwn.net/Articles/789370/
* https://lwn.net/Articles/789370/


== Release Notes ==
== Release Notes ==

Latest revision as of 19:51, 20 July 2020

Aarch64 Pointer Authentication & Branch Target Enablement

Summary

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.

Owner

Current status

Detailed Description

Benefit to Fedora

PAC & BTI are code hardening features, they should serve to make fedora more resistant to a couple further classes of runtime attacks. By enabling this early, fedora is once again proven to be at the leading edge of security and linux development. If everything works as planned, this change will be invisible to the end user, except in cases where the applications will trap behaviour that appears to be caused by exploit attempts.

Scope

  • Proposal owners:

Work with individual package maintainers in the case of build failures or runtime exceptions. In the latter case there are two possibilities. First on v8.0 hardware, which is currently the most common, the additional instruction sequences are treated as NOP's and should be completely ignored by the hardware. It may be possible on v8.3/8.5 hardware that PAC or BTI may need additional tweaks for hand written assembly which interacts with PAC/BTI enabled code.

  • Other developers:

Assure their packages continue to compile and pass unit/integration/etc tests on v8.0 hardware. Continue to monitor runtime problems on v8.3+ for bugs, vs exploit attempts.

  • Release engineering: 9505 (a check of an impact with Release Engineering is needed)
  • Policies and guidelines:

At the moment, nothing needs to be changed as this should propagate as the default set of RPM build flags.

  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

If everything works as planned, this should be transparent to the end user.

How To Test

Testing falls into two categories. Assuring that the packages continue to work on existing arm v8.0 hardware without PAC, and testing on PAC+BTI enabled hardware. For the most part the expectation from the fedora community is that package maintainers assure their packages continue to work on existing systems. PAC+ hardware will be in limited supply during the F33 development cycle, so the expectation is that owners of that hardware will perform more complete systemwide testing and report any defects found against the packages in question along with fixes or hardware access.

User Experience

Dependencies

There are various gcc and kernel related changes which have already landed, but there continue to be a few cleanup patches trickling into the toolchain/compiler as problems are discovered.

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?)

Build affected packages with explicit compiler flags disabling the feature. Worse case the top level rpm macros reversion, and a rebuild of effected packages. Contingency deadline: Beta target.

  • Blocks release? No, except for major functionality loss due to core package bug.
  • Blocks product? No

Documentation

Arm pointer authentication is a technology designed to make software more robust by providing hardware assistance for code hardening. It protects pointers by cryptographically signing them and verifying their signatures when used, thereby mitigating certain attack vectors. Core support is provided to applications and libraries transparently via kernel and toolchain changes to generate hardended code. Branch Target identification, similarly provides landing pads, to harden code paths by restricting the processor from jumping into unexpected parts of a function.

Further reference:

Release Notes