< Changes
(Initial PAC+BTI request) |
(→Scope) |
||
| Line 49: | Line 49: | ||
* Proposal owners: | * 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.2/8.4 hardware that PAC or BTI may need additional tweaks for hand written assembly which interacts with PAC/BTI enabled code. | 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.2/8.4 hardware that PAC or BTI may need additional tweaks for hand written assembly which interacts with PAC/BTI enabled code. | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
| Line 60: | Line 59: | ||
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 --> | ||
* Policies and guidelines: | * Policies and guidelines: | ||
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | <!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | ||
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) | * Trademark approval: N/A (not needed for this Change) | ||
Revision as of 14:59, 28 April 2020
Change Proposal Name 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.2 (PAC) & v8.4 (BTI) enabled Arm machines.
Owner
- Name: Jeremy Linton & ARM SIG
- Email: jeremy.linton@arm.com
Current status
- Targeted release: Fedora 33
- Last updated: 2020-04-28
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
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.2/8.4 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.2+ for bugs, vs exploit attempts.
- Release engineering: #Releng issue number (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
N/A (not a System Wide Change)
How To Test
N/A (not a System Wide Change)
User Experience
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
- Blocks product? product
Documentation
N/A (not a System Wide Change)