Fedora 33 System-Wide Change proposal: Aarch64 Pointer Authentication & Branch Target Enablement

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication

== 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 ==
* Name: [[User:jlinton| Jeremy Linton]] & ARM SIG
* Email: jeremy.linton(a)arm.com


== 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: (pending)
* 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 ==
(not supplied)

== 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:
*
https://developer.arm.com/architectures/learn-the-architecture/providing-...
*
https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authent...
* https://www.usenix.org/system/files/sec19fall_liljestrand_prepub.pdf
* https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf
* https://lwn.net/Articles/789370/

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Przemek Klosowski]

On 5/18/20 3:36 PM, Ben Cotton wrote:
>  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. 
Is there a performance impact? do those landing pad instructions take an 
execution pipeline slots?

We're planning to use AUTIASP+RET, not RETAA, right?

[Igor Raits]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, 2020-05-18 at 15:36 -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication
>  
>  == 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. 
Is there some noticeable performance drop or anything like that?

>  == Owner ==
>  * Name: [[User:jlinton| Jeremy Linton]] & ARM SIG
>  * Email: jeremy.linton(a)arm.com
>  
>  
>  == 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. 
It would be nice if you would specify which exact flags and where you
will add them, so that it would be easy to see which people we need to
get on board for this change.

>  * 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: (pending)
>  * 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 ==
>  (not supplied)
>  
>  == 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:
>  * 
>
> https://developer.arm.com/architectures/learn-the-architecture/providing-...
>  * 
>
> https://www.qualcomm.com/media/documents/files/whitepaper-pointer-authent...
>  * 
>  https://www.usenix.org/system/files/sec19fall_liljestrand_prepub.pdf
>  * 
>  https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf
>  * https://lwn.net/Articles/789370/
>  
>  -- 
>  Ben Cotton
>  He / Him / His
>  Senior Program Manager, Fedora & CentOS Stream
>  Red Hat
>  TZ=America/Indiana/Indianapolis
>  _______________________________________________
>  devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
>  To unsubscribe send an email to 
>  devel-announce-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: 
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7EMcAACgkQEV1auJxc
> Hh430hAAuHRfXdDLdttuMU0jXfoVY7e+SyQIrw7c7AQh8NYseexlwjHb0gYGXcgI
> q21jW3KA5V86PIl+WI31jSf2bttwHkAw2NRYb42wU+lKk4e6Jy1J1NNNY0Wp7bSs
> bMu9C4+GjKh1JDxDBYPjnBtIGj0BwNMnEB/XPe4K/DZpwVDKhRZNcNWBGtmKjxbk
> lEs4zuzGBq+GOWQgpHmrCuUtgXmTOwovirIdnNW7qNs7EWwBo5oytb9Q6CUIE28A
> PfV5eRTJa1m1O7clNAe+2K3xGXuQ6k5OPmR/vZbZ3JqzsKUhh2UPLxoO7LIEmtlc
> C424ErAAxQd9Eop7eUrUA3KSr+6AFzW4fUCLnBYuTB9Hrwe3wl4smtwy8WfsiiTS
> przpZjNWDTGsxltIL3MWZFX09dxWq4jmy8aYaG7X5LHqMv/Mb5tDMrGXn0B0fczm
> sTOoNebE/TLkGLDoloOcsYBIXuSEOFlfHAnLECKZU4N2ZZEZeROjOWW6QI8w7Fng
> +XMJCQqih8NHc9eVxNWI5P089QLsBiL8xcnUyHaOAf8zx4K+1JsWiynLdjbjxvcu
> csUgWl/Ih894JN12EmuJyy0BxV/X0E/13SepMfieTte+fZqS2OAlykJWqx9aSkY2
> 5ameSrWfQ14zqAUGGn4ZkQXnh3N0ADPECDablEfYl2yH9ULfggo=
> =chx8
> -----END PGP SIGNATURE-----

[Jeremy Linton]

Hi,

On 5/19/20 1:38 PM, Przemek Klosowski via devel wrote:
>  On 5/18/20 3:36 PM, Ben Cotton wrote:
> > 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.
>  
>  Is there a performance impact? do those landing pad instructions take an 
>  execution pipeline slots? 
Potentially, depends on the microarch. In general on existing machines 
they decode as HIT/NOPs and get tossed, and since most of the ARM cores 
aren't decode limited it won't have an effect. On cores where its 
actually active its a lot harder to generalize and compare performance 
at the moment. In theory if a particular machine has a bad 
implementation we can just disable it for that given machine to return 
the behavior to just HIT/NOP.

>  
>  We're planning to use AUTIASP+RET, not RETAA, right? 
I believe that is the
case, retaa requires a 8.3 machine and we need 
compatibility with 8.0 so we need to stick to the pac portion which is 
in the HINT space and translates to NOPs on < v8.3 hardware.

Note:

https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/aarch64....


Thanks,

[Jeremy Linton]

Hi,

On 5/19/20 2:21 PM, Igor Raits wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA512
>  
>  On Mon, 2020-05-18 at 15:36 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication
> >
> > == 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.
>  
>  Is there some noticeable performance drop or anything like that? 
Potentially, please see my longer response in the other email.


>  
> > == Owner ==
> > * Name: [[User:jlinton| Jeremy Linton]] & ARM SIG
> > * Email: jeremy.linton(a)arm.com
> >
> >
> > == 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.
>  
>  It would be nice if you would specify which exact flags and where you
>  will add them, so that it would be easy to see which people we need to
>  get on board for this change. 
Its the gcc flag "-mbranch-protection=standard" I mentioned in the 
summary above. The assumption is that we place it in the arch specific 
opt stanza in /usr/lib/rpm/redhat/rpmrc, or we extend 
/usr/lib/rpm/redhat/macros hardening section to allow an arch specific 
hardening.

I've rebuilt a minimal install by creating a custom mock template, but I 
don't think that is the right official answer.


Thanks,