|
|
|
#! /usr/bin/env perl
|
|
|
|
# Copyright 2014-2016 The OpenSSL Project Authors. All Rights Reserved.
|
|
|
|
#
|
|
|
|
# Licensed under the OpenSSL license (the "License"). You may not use
|
|
|
|
# this file except in compliance with the License. You can obtain a copy
|
|
|
|
# in the file LICENSE in the source distribution or at
|
|
|
|
# https://www.openssl.org/source/license.html
|
|
|
|
|
|
|
|
# ====================================================================
|
|
|
|
# Written by Andy Polyakov <appro@openssl.org> for the OpenSSL
|
|
|
|
# project. The module is, however, dual licensed under OpenSSL and
|
|
|
|
# CRYPTOGAMS licenses depending on where you obtain it. For further
|
|
|
|
# details see http://www.openssl.org/~appro/cryptogams/.
|
|
|
|
#
|
|
|
|
# Permission to use under GPLv2 terms is granted.
|
|
|
|
# ====================================================================
|
|
|
|
#
|
|
|
|
# SHA256/512 for ARMv8.
|
|
|
|
#
|
|
|
|
# Performance in cycles per processed byte and improvement coefficient
|
|
|
|
# over code generated with "default" compiler:
|
|
|
|
#
|
|
|
|
# SHA256-hw SHA256(*) SHA512
|
|
|
|
# Apple A7 1.97 10.5 (+33%) 6.73 (-1%(**))
|
|
|
|
# Cortex-A53 2.38 15.5 (+115%) 10.0 (+150%(***))
|
|
|
|
# Cortex-A57 2.31 11.6 (+86%) 7.51 (+260%(***))
|
|
|
|
# Denver 2.01 10.5 (+26%) 6.70 (+8%)
|
|
|
|
# X-Gene 20.0 (+100%) 12.8 (+300%(***))
|
|
|
|
# Mongoose 2.36 13.0 (+50%) 8.36 (+33%)
|
|
|
|
#
|
|
|
|
# (*) Software SHA256 results are of lesser relevance, presented
|
|
|
|
# mostly for informational purposes.
|
|
|
|
# (**) The result is a trade-off: it's possible to improve it by
|
|
|
|
# 10% (or by 1 cycle per round), but at the cost of 20% loss
|
|
|
|
# on Cortex-A53 (or by 4 cycles per round).
|
|
|
|
# (***) Super-impressive coefficients over gcc-generated code are
|
|
|
|
# indication of some compiler "pathology", most notably code
|
|
|
|
# generated with -mgeneral-regs-only is significanty faster
|
|
|
|
# and the gap is only 40-90%.
|
|
|
|
|
|
|
|
$output=pop;
|
|
|
|
$flavour=pop;
|
|
|
|
|
|
|
|
if ($flavour && $flavour ne "void") {
|
|
|
|
$0 =~ m/(.*[\/\\])[^\/\\]+$/; $dir=$1;
|
|
|
|
( $xlate="${dir}arm-xlate.pl" and -f $xlate ) or
|
|
|
|
( $xlate="${dir}../../../perlasm/arm-xlate.pl" and -f $xlate) or
|
|
|
|
die "can't locate arm-xlate.pl";
|
|
|
|
|
|
|
|
open OUT,"| \"$^X\" $xlate $flavour $output";
|
|
|
|
*STDOUT=*OUT;
|
|
|
|
} else {
|
|
|
|
open OUT,">$output";
|
|
|
|
*STDOUT=*OUT;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($output =~ /512/) {
|
|
|
|
$BITS=512;
|
|
|
|
$SZ=8;
|
|
|
|
@Sigma0=(28,34,39);
|
|
|
|
@Sigma1=(14,18,41);
|
|
|
|
@sigma0=(1, 8, 7);
|
|
|
|
@sigma1=(19,61, 6);
|
|
|
|
$rounds=80;
|
|
|
|
$reg_t="x";
|
|
|
|
} else {
|
|
|
|
$BITS=256;
|
|
|
|
$SZ=4;
|
|
|
|
@Sigma0=( 2,13,22);
|
|
|
|
@Sigma1=( 6,11,25);
|
|
|
|
@sigma0=( 7,18, 3);
|
|
|
|
@sigma1=(17,19,10);
|
|
|
|
$rounds=64;
|
|
|
|
$reg_t="w";
|
|
|
|
}
|
|
|
|
|
|
|
|
$func="sha${BITS}_block_data_order";
|
|
|
|
|
|
|
|
($ctx,$inp,$num,$Ktbl)=map("x$_",(0..2,30));
|
|
|
|
|
|
|
|
@X=map("$reg_t$_",(3..15,0..2));
|
|
|
|
@V=($A,$B,$C,$D,$E,$F,$G,$H)=map("$reg_t$_",(20..27));
|
|
|
|
($t0,$t1,$t2,$t3)=map("$reg_t$_",(16,17,19,28));
|
|
|
|
|
|
|
|
sub BODY_00_xx {
|
|
|
|
my ($i,$a,$b,$c,$d,$e,$f,$g,$h)=@_;
|
|
|
|
my $j=($i+1)&15;
|
|
|
|
my ($T0,$T1,$T2)=(@X[($i-8)&15],@X[($i-9)&15],@X[($i-10)&15]);
|
|
|
|
$T0=@X[$i+3] if ($i<11);
|
|
|
|
|
|
|
|
$code.=<<___ if ($i<16);
|
|
|
|
#ifndef __ARMEB__
|
|
|
|
rev @X[$i],@X[$i] // $i
|
|
|
|
#endif
|
|
|
|
___
|
|
|
|
$code.=<<___ if ($i<13 && ($i&1));
|
|
|
|
ldp @X[$i+1],@X[$i+2],[$inp],#2*$SZ
|
|
|
|
___
|
|
|
|
$code.=<<___ if ($i==13);
|
|
|
|
ldp @X[14],@X[15],[$inp]
|
|
|
|
___
|
|
|
|
$code.=<<___ if ($i>=14);
|
|
|
|
ldr @X[($i-11)&15],[sp,#`$SZ*(($i-11)%4)`]
|
|
|
|
___
|
|
|
|
$code.=<<___ if ($i>0 && $i<16);
|
|
|
|
add $a,$a,$t1 // h+=Sigma0(a)
|
|
|
|
___
|
|
|
|
$code.=<<___ if ($i>=11);
|
|
|
|
str @X[($i-8)&15],[sp,#`$SZ*(($i-8)%4)`]
|
|
|
|
___
|
|
|
|
# While ARMv8 specifies merged rotate-n-logical operation such as
|
|
|
|
# 'eor x,y,z,ror#n', it was found to negatively affect performance
|
|
|
|
# on Apple A7. The reason seems to be that it requires even 'y' to
|
|
|
|
# be available earlier. This means that such merged instruction is
|
|
|
|
# not necessarily best choice on critical path... On the other hand
|
|
|
|
# Cortex-A5x handles merged instructions much better than disjoint
|
|
|
|
# rotate and logical... See (**) footnote above.
|
|
|
|
$code.=<<___ if ($i<15);
|
|
|
|
ror $t0,$e,#$Sigma1[0]
|
|
|
|
add $h,$h,$t2 // h+=K[i]
|
|
|
|
eor $T0,$e,$e,ror#`$Sigma1[2]-$Sigma1[1]`
|
|
|
|
and $t1,$f,$e
|
|
|
|
bic $t2,$g,$e
|
|
|
|
add $h,$h,@X[$i&15] // h+=X[i]
|
|
|
|
orr $t1,$t1,$t2 // Ch(e,f,g)
|
|
|
|
eor $t2,$a,$b // a^b, b^c in next round
|
|
|
|
eor $t0,$t0,$T0,ror#$Sigma1[1] // Sigma1(e)
|
|
|
|
ror $T0,$a,#$Sigma0[0]
|
|
|
|
add $h,$h,$t1 // h+=Ch(e,f,g)
|
|
|
|
eor $t1,$a,$a,ror#`$Sigma0[2]-$Sigma0[1]`
|
|
|
|
add $h,$h,$t0 // h+=Sigma1(e)
|
|
|
|
and $t3,$t3,$t2 // (b^c)&=(a^b)
|
|
|
|
add $d,$d,$h // d+=h
|
|
|
|
eor $t3,$t3,$b // Maj(a,b,c)
|
|
|
|
eor $t1,$T0,$t1,ror#$Sigma0[1] // Sigma0(a)
|
|
|
|
add $h,$h,$t3 // h+=Maj(a,b,c)
|
|
|
|
ldr $t3,[$Ktbl],#$SZ // *K++, $t2 in next round
|
|
|
|
//add $h,$h,$t1 // h+=Sigma0(a)
|
|
|
|
___
|
|
|
|
$code.=<<___ if ($i>=15);
|
|
|
|
ror $t0,$e,#$Sigma1[0]
|
|
|
|
add $h,$h,$t2 // h+=K[i]
|
|
|
|
ror $T1,@X[($j+1)&15],#$sigma0[0]
|
|
|
|
and $t1,$f,$e
|
|
|
|
ror $T2,@X[($j+14)&15],#$sigma1[0]
|
|
|
|
bic $t2,$g,$e
|
|
|
|
ror $T0,$a,#$Sigma0[0]
|
|
|
|
add $h,$h,@X[$i&15] // h+=X[i]
|
|
|
|
eor $t0,$t0,$e,ror#$Sigma1[1]
|
|
|
|
eor $T1,$T1,@X[($j+1)&15],ror#$sigma0[1]
|
|
|
|
orr $t1,$t1,$t2 // Ch(e,f,g)
|
|
|
|
eor $t2,$a,$b // a^b, b^c in next round
|
|
|
|
eor $t0,$t0,$e,ror#$Sigma1[2] // Sigma1(e)
|
|
|
|
eor $T0,$T0,$a,ror#$Sigma0[1]
|
|
|
|
add $h,$h,$t1 // h+=Ch(e,f,g)
|
|
|
|
and $t3,$t3,$t2 // (b^c)&=(a^b)
|
|
|
|
eor $T2,$T2,@X[($j+14)&15],ror#$sigma1[1]
|
|
|
|
eor $T1,$T1,@X[($j+1)&15],lsr#$sigma0[2] // sigma0(X[i+1])
|
|
|
|
add $h,$h,$t0 // h+=Sigma1(e)
|
|
|
|
eor $t3,$t3,$b // Maj(a,b,c)
|
|
|
|
eor $t1,$T0,$a,ror#$Sigma0[2] // Sigma0(a)
|
|
|
|
eor $T2,$T2,@X[($j+14)&15],lsr#$sigma1[2] // sigma1(X[i+14])
|
|
|
|
add @X[$j],@X[$j],@X[($j+9)&15]
|
|
|
|
add $d,$d,$h // d+=h
|
|
|
|
add $h,$h,$t3 // h+=Maj(a,b,c)
|
|
|
|
ldr $t3,[$Ktbl],#$SZ // *K++, $t2 in next round
|
|
|
|
add @X[$j],@X[$j],$T1
|
|
|
|
add $h,$h,$t1 // h+=Sigma0(a)
|
|
|
|
add @X[$j],@X[$j],$T2
|
|
|
|
___
|
|
|
|
($t2,$t3)=($t3,$t2);
|
|
|
|
}
|
|
|
|
|
|
|
|
$code.=<<___;
|
|
|
|
#ifndef __KERNEL__
|
|
|
|
# include <openssl/arm_arch.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
.text
|
|
|
|
|
|
|
|
.extern OPENSSL_armcap_P
|
|
|
|
.globl $func
|
|
|
|
.type $func,%function
|
|
|
|
.align 6
|
|
|
|
$func:
|
|
|
|
___
|
|
|
|
$code.=<<___ if ($SZ==4);
|
aarch64: support BTI and pointer authentication in assembly
This change adds optional support for
- Armv8.3-A Pointer Authentication (PAuth) and
- Armv8.5-A Branch Target Identification (BTI)
features to the perl scripts.
Both features can be enabled with additional compiler flags.
Unless any of these are enabled explicitly there is no code change at
all.
The extensions are briefly described below. Please read the appropriate
chapters of the Arm Architecture Reference Manual for the complete
specification.
Scope
-----
This change only affects generated assembly code.
Armv8.3-A Pointer Authentication
--------------------------------
Pointer Authentication extension supports the authentication of the
contents of registers before they are used for indirect branching
or load.
PAuth provides a probabilistic method to detect corruption of register
values. PAuth signing instructions generate a Pointer Authentication
Code (PAC) based on the value of a register, a seed and a key.
The generated PAC is inserted into the original value in the register.
A PAuth authentication instruction recomputes the PAC, and if it matches
the PAC in the register, restores its original value. In case of a
mismatch, an architecturally unmapped address is generated instead.
With PAuth, mitigation against ROP (Return-oriented Programming) attacks
can be implemented. This is achieved by signing the contents of the
link-register (LR) before it is pushed to stack. Once LR is popped,
it is authenticated. This way a stack corruption which overwrites the
LR on the stack is detectable.
The PAuth extension adds several new instructions, some of which are not
recognized by older hardware. To support a single codebase for both pre
Armv8.3-A targets and newer ones, only NOP-space instructions are added
by this patch. These instructions are treated as NOPs on hardware
which does not support Armv8.3-A. Furthermore, this patch only considers
cases where LR is saved to the stack and then restored before branching
to its content. There are cases in the code where LR is pushed to stack
but it is not used later. We do not address these cases as they are not
affected by PAuth.
There are two keys available to sign an instruction address: A and B.
PACIASP and PACIBSP only differ in the used keys: A and B, respectively.
The keys are typically managed by the operating system.
To enable generating code for PAuth compile with
-mbranch-protection=<mode>:
- standard or pac-ret: add PACIASP and AUTIASP, also enables BTI
(read below)
- pac-ret+b-key: add PACIBSP and AUTIBSP
Armv8.5-A Branch Target Identification
--------------------------------------
Branch Target Identification features some new instructions which
protect the execution of instructions on guarded pages which are not
intended branch targets.
If Armv8.5-A is supported by the hardware, execution of an instruction
changes the value of PSTATE.BTYPE field. If an indirect branch
lands on a guarded page the target instruction must be one of the
BTI <jc> flavors, or in case of a direct call or jump it can be any
other instruction. If the target instruction is not compatible with the
value of PSTATE.BTYPE a Branch Target Exception is generated.
In short, indirect jumps are compatible with BTI <j> and <jc> while
indirect calls are compatible with BTI <c> and <jc>. Please refer to the
specification for the details.
Armv8.3-A PACIASP and PACIBSP are implicit branch target
identification instructions which are equivalent with BTI c or BTI jc
depending on system register configuration.
BTI is used to mitigate JOP (Jump-oriented Programming) attacks by
limiting the set of instructions which can be jumped to.
BTI requires active linker support to mark the pages with BTI-enabled
code as guarded. For ELF64 files BTI compatibility is recorded in the
.note.gnu.property section. For a shared object or static binary it is
required that all linked units support BTI. This means that even a
single assembly file without the required note section turns-off BTI
for the whole binary or shared object.
The new BTI instructions are treated as NOPs on hardware which does
not support Armv8.5-A or on pages which are not guarded.
To insert this new and optional instruction compile with
-mbranch-protection=standard (also enables PAuth) or +bti.
When targeting a guarded page from a non-guarded page, weaker
compatibility restrictions apply to maintain compatibility between
legacy and new code. For detailed rules please refer to the Arm ARM.
Compiler support
----------------
Compiler support requires understanding '-mbranch-protection=<mode>'
and emitting the appropriate feature macros (__ARM_FEATURE_BTI_DEFAULT
and __ARM_FEATURE_PAC_DEFAULT). The current state is the following:
-------------------------------------------------------
| Compiler | -mbranch-protection | Feature macros |
+----------+---------------------+--------------------+
| clang | 9.0.0 | 11.0.0 |
+----------+---------------------+--------------------+
| gcc | 9 | expected in 10.1+ |
-------------------------------------------------------
Available Platforms
------------------
Arm Fast Model and QEMU support both extensions.
https://developer.arm.com/tools-and-software/simulation-models/fast-models
https://www.qemu.org/
Implementation Notes
--------------------
This change adds BTI landing pads even to assembly functions which are
likely to be directly called only. In these cases, landing pads might
be superfluous depending on what code the linker generates.
Code size and performance impact for these cases would be negligble.
Interaction with C code
-----------------------
Pointer Authentication is a per-frame protection while Branch Target
Identification can be turned on and off only for all code pages of a
whole shared object or static binary. Because of these properties if
C/C++ code is compiled without any of the above features but assembly
files support any of them unconditionally there is no incompatibility
between the two.
Useful Links
------------
To fully understand the details of both PAuth and BTI it is advised to
read the related chapters of the Arm Architecture Reference Manual
(Arm ARM):
https://developer.arm.com/documentation/ddi0487/latest/
Additional materials:
"Providing protection for complex software"
https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software
Arm Compiler Reference Guide Version 6.14: -mbranch-protection
https://developer.arm.com/documentation/101754/0614/armclang-Reference/armclang-Command-line-Options/-mbranch-protection?lang=en
Arm C Language Extensions (ACLE)
https://developer.arm.com/docs/101028/latest
Change-Id: I4335f92e2ccc8e209c7d68a0a79f1acdf3aeb791
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42084
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
5 years ago
|
|
|
AARCH64_VALID_CALL_TARGET
|
|
|
|
#ifndef __KERNEL__
|
|
|
|
#if __has_feature(hwaddress_sanitizer) && __clang_major__ >= 10
|
|
|
|
adrp x16,:pg_hi21_nc:OPENSSL_armcap_P
|
|
|
|
#else
|
|
|
|
adrp x16,:pg_hi21:OPENSSL_armcap_P
|
|
|
|
#endif
|
|
|
|
ldr w16,[x16,:lo12:OPENSSL_armcap_P]
|
|
|
|
tst w16,#ARMV8_SHA256
|
|
|
|
b.ne .Lv8_entry
|
|
|
|
#endif
|
|
|
|
___
|
|
|
|
$code.=<<___;
|
aarch64: support BTI and pointer authentication in assembly
This change adds optional support for
- Armv8.3-A Pointer Authentication (PAuth) and
- Armv8.5-A Branch Target Identification (BTI)
features to the perl scripts.
Both features can be enabled with additional compiler flags.
Unless any of these are enabled explicitly there is no code change at
all.
The extensions are briefly described below. Please read the appropriate
chapters of the Arm Architecture Reference Manual for the complete
specification.
Scope
-----
This change only affects generated assembly code.
Armv8.3-A Pointer Authentication
--------------------------------
Pointer Authentication extension supports the authentication of the
contents of registers before they are used for indirect branching
or load.
PAuth provides a probabilistic method to detect corruption of register
values. PAuth signing instructions generate a Pointer Authentication
Code (PAC) based on the value of a register, a seed and a key.
The generated PAC is inserted into the original value in the register.
A PAuth authentication instruction recomputes the PAC, and if it matches
the PAC in the register, restores its original value. In case of a
mismatch, an architecturally unmapped address is generated instead.
With PAuth, mitigation against ROP (Return-oriented Programming) attacks
can be implemented. This is achieved by signing the contents of the
link-register (LR) before it is pushed to stack. Once LR is popped,
it is authenticated. This way a stack corruption which overwrites the
LR on the stack is detectable.
The PAuth extension adds several new instructions, some of which are not
recognized by older hardware. To support a single codebase for both pre
Armv8.3-A targets and newer ones, only NOP-space instructions are added
by this patch. These instructions are treated as NOPs on hardware
which does not support Armv8.3-A. Furthermore, this patch only considers
cases where LR is saved to the stack and then restored before branching
to its content. There are cases in the code where LR is pushed to stack
but it is not used later. We do not address these cases as they are not
affected by PAuth.
There are two keys available to sign an instruction address: A and B.
PACIASP and PACIBSP only differ in the used keys: A and B, respectively.
The keys are typically managed by the operating system.
To enable generating code for PAuth compile with
-mbranch-protection=<mode>:
- standard or pac-ret: add PACIASP and AUTIASP, also enables BTI
(read below)
- pac-ret+b-key: add PACIBSP and AUTIBSP
Armv8.5-A Branch Target Identification
--------------------------------------
Branch Target Identification features some new instructions which
protect the execution of instructions on guarded pages which are not
intended branch targets.
If Armv8.5-A is supported by the hardware, execution of an instruction
changes the value of PSTATE.BTYPE field. If an indirect branch
lands on a guarded page the target instruction must be one of the
BTI <jc> flavors, or in case of a direct call or jump it can be any
other instruction. If the target instruction is not compatible with the
value of PSTATE.BTYPE a Branch Target Exception is generated.
In short, indirect jumps are compatible with BTI <j> and <jc> while
indirect calls are compatible with BTI <c> and <jc>. Please refer to the
specification for the details.
Armv8.3-A PACIASP and PACIBSP are implicit branch target
identification instructions which are equivalent with BTI c or BTI jc
depending on system register configuration.
BTI is used to mitigate JOP (Jump-oriented Programming) attacks by
limiting the set of instructions which can be jumped to.
BTI requires active linker support to mark the pages with BTI-enabled
code as guarded. For ELF64 files BTI compatibility is recorded in the
.note.gnu.property section. For a shared object or static binary it is
required that all linked units support BTI. This means that even a
single assembly file without the required note section turns-off BTI
for the whole binary or shared object.
The new BTI instructions are treated as NOPs on hardware which does
not support Armv8.5-A or on pages which are not guarded.
To insert this new and optional instruction compile with
-mbranch-protection=standard (also enables PAuth) or +bti.
When targeting a guarded page from a non-guarded page, weaker
compatibility restrictions apply to maintain compatibility between
legacy and new code. For detailed rules please refer to the Arm ARM.
Compiler support
----------------
Compiler support requires understanding '-mbranch-protection=<mode>'
and emitting the appropriate feature macros (__ARM_FEATURE_BTI_DEFAULT
and __ARM_FEATURE_PAC_DEFAULT). The current state is the following:
-------------------------------------------------------
| Compiler | -mbranch-protection | Feature macros |
+----------+---------------------+--------------------+
| clang | 9.0.0 | 11.0.0 |
+----------+---------------------+--------------------+
| gcc | 9 | expected in 10.1+ |
-------------------------------------------------------
Available Platforms
------------------
Arm Fast Model and QEMU support both extensions.
https://developer.arm.com/tools-and-software/simulation-models/fast-models
https://www.qemu.org/
Implementation Notes
--------------------
This change adds BTI landing pads even to assembly functions which are
likely to be directly called only. In these cases, landing pads might
be superfluous depending on what code the linker generates.
Code size and performance impact for these cases would be negligble.
Interaction with C code
-----------------------
Pointer Authentication is a per-frame protection while Branch Target
Identification can be turned on and off only for all code pages of a
whole shared object or static binary. Because of these properties if
C/C++ code is compiled without any of the above features but assembly
files support any of them unconditionally there is no incompatibility
between the two.
Useful Links
------------
To fully understand the details of both PAuth and BTI it is advised to
read the related chapters of the Arm Architecture Reference Manual
(Arm ARM):
https://developer.arm.com/documentation/ddi0487/latest/
Additional materials:
"Providing protection for complex software"
https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software
Arm Compiler Reference Guide Version 6.14: -mbranch-protection
https://developer.arm.com/documentation/101754/0614/armclang-Reference/armclang-Command-line-Options/-mbranch-protection?lang=en
Arm C Language Extensions (ACLE)
https://developer.arm.com/docs/101028/latest
Change-Id: I4335f92e2ccc8e209c7d68a0a79f1acdf3aeb791
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42084
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
5 years ago
|
|
|
AARCH64_SIGN_LINK_REGISTER
|
|
|
|
stp x29,x30,[sp,#-128]!
|
|
|
|
add x29,sp,#0
|
|
|
|
|
|
|
|
stp x19,x20,[sp,#16]
|
|
|
|
stp x21,x22,[sp,#32]
|
|
|
|
stp x23,x24,[sp,#48]
|
|
|
|
stp x25,x26,[sp,#64]
|
|
|
|
stp x27,x28,[sp,#80]
|
|
|
|
sub sp,sp,#4*$SZ
|
|
|
|
|
|
|
|
ldp $A,$B,[$ctx] // load context
|
|
|
|
ldp $C,$D,[$ctx,#2*$SZ]
|
|
|
|
ldp $E,$F,[$ctx,#4*$SZ]
|
|
|
|
add $num,$inp,$num,lsl#`log(16*$SZ)/log(2)` // end of input
|
|
|
|
ldp $G,$H,[$ctx,#6*$SZ]
|
|
|
|
adrp $Ktbl,:pg_hi21:.LK$BITS
|
|
|
|
add $Ktbl,$Ktbl,:lo12:.LK$BITS
|
|
|
|
stp $ctx,$num,[x29,#96]
|
|
|
|
|
|
|
|
.Loop:
|
|
|
|
ldp @X[0],@X[1],[$inp],#2*$SZ
|
|
|
|
ldr $t2,[$Ktbl],#$SZ // *K++
|
|
|
|
eor $t3,$B,$C // magic seed
|
|
|
|
str $inp,[x29,#112]
|
|
|
|
___
|
|
|
|
for ($i=0;$i<16;$i++) { &BODY_00_xx($i,@V); unshift(@V,pop(@V)); }
|
|
|
|
$code.=".Loop_16_xx:\n";
|
|
|
|
for (;$i<32;$i++) { &BODY_00_xx($i,@V); unshift(@V,pop(@V)); }
|
|
|
|
$code.=<<___;
|
|
|
|
cbnz $t2,.Loop_16_xx
|
|
|
|
|
|
|
|
ldp $ctx,$num,[x29,#96]
|
|
|
|
ldr $inp,[x29,#112]
|
|
|
|
sub $Ktbl,$Ktbl,#`$SZ*($rounds+1)` // rewind
|
|
|
|
|
|
|
|
ldp @X[0],@X[1],[$ctx]
|
|
|
|
ldp @X[2],@X[3],[$ctx,#2*$SZ]
|
|
|
|
add $inp,$inp,#14*$SZ // advance input pointer
|
|
|
|
ldp @X[4],@X[5],[$ctx,#4*$SZ]
|
|
|
|
add $A,$A,@X[0]
|
|
|
|
ldp @X[6],@X[7],[$ctx,#6*$SZ]
|
|
|
|
add $B,$B,@X[1]
|
|
|
|
add $C,$C,@X[2]
|
|
|
|
add $D,$D,@X[3]
|
|
|
|
stp $A,$B,[$ctx]
|
|
|
|
add $E,$E,@X[4]
|
|
|
|
add $F,$F,@X[5]
|
|
|
|
stp $C,$D,[$ctx,#2*$SZ]
|
|
|
|
add $G,$G,@X[6]
|
|
|
|
add $H,$H,@X[7]
|
|
|
|
cmp $inp,$num
|
|
|
|
stp $E,$F,[$ctx,#4*$SZ]
|
|
|
|
stp $G,$H,[$ctx,#6*$SZ]
|
|
|
|
b.ne .Loop
|
|
|
|
|
|
|
|
ldp x19,x20,[x29,#16]
|
|
|
|
add sp,sp,#4*$SZ
|
|
|
|
ldp x21,x22,[x29,#32]
|
|
|
|
ldp x23,x24,[x29,#48]
|
|
|
|
ldp x25,x26,[x29,#64]
|
|
|
|
ldp x27,x28,[x29,#80]
|
|
|
|
ldp x29,x30,[sp],#128
|
aarch64: support BTI and pointer authentication in assembly
This change adds optional support for
- Armv8.3-A Pointer Authentication (PAuth) and
- Armv8.5-A Branch Target Identification (BTI)
features to the perl scripts.
Both features can be enabled with additional compiler flags.
Unless any of these are enabled explicitly there is no code change at
all.
The extensions are briefly described below. Please read the appropriate
chapters of the Arm Architecture Reference Manual for the complete
specification.
Scope
-----
This change only affects generated assembly code.
Armv8.3-A Pointer Authentication
--------------------------------
Pointer Authentication extension supports the authentication of the
contents of registers before they are used for indirect branching
or load.
PAuth provides a probabilistic method to detect corruption of register
values. PAuth signing instructions generate a Pointer Authentication
Code (PAC) based on the value of a register, a seed and a key.
The generated PAC is inserted into the original value in the register.
A PAuth authentication instruction recomputes the PAC, and if it matches
the PAC in the register, restores its original value. In case of a
mismatch, an architecturally unmapped address is generated instead.
With PAuth, mitigation against ROP (Return-oriented Programming) attacks
can be implemented. This is achieved by signing the contents of the
link-register (LR) before it is pushed to stack. Once LR is popped,
it is authenticated. This way a stack corruption which overwrites the
LR on the stack is detectable.
The PAuth extension adds several new instructions, some of which are not
recognized by older hardware. To support a single codebase for both pre
Armv8.3-A targets and newer ones, only NOP-space instructions are added
by this patch. These instructions are treated as NOPs on hardware
which does not support Armv8.3-A. Furthermore, this patch only considers
cases where LR is saved to the stack and then restored before branching
to its content. There are cases in the code where LR is pushed to stack
but it is not used later. We do not address these cases as they are not
affected by PAuth.
There are two keys available to sign an instruction address: A and B.
PACIASP and PACIBSP only differ in the used keys: A and B, respectively.
The keys are typically managed by the operating system.
To enable generating code for PAuth compile with
-mbranch-protection=<mode>:
- standard or pac-ret: add PACIASP and AUTIASP, also enables BTI
(read below)
- pac-ret+b-key: add PACIBSP and AUTIBSP
Armv8.5-A Branch Target Identification
--------------------------------------
Branch Target Identification features some new instructions which
protect the execution of instructions on guarded pages which are not
intended branch targets.
If Armv8.5-A is supported by the hardware, execution of an instruction
changes the value of PSTATE.BTYPE field. If an indirect branch
lands on a guarded page the target instruction must be one of the
BTI <jc> flavors, or in case of a direct call or jump it can be any
other instruction. If the target instruction is not compatible with the
value of PSTATE.BTYPE a Branch Target Exception is generated.
In short, indirect jumps are compatible with BTI <j> and <jc> while
indirect calls are compatible with BTI <c> and <jc>. Please refer to the
specification for the details.
Armv8.3-A PACIASP and PACIBSP are implicit branch target
identification instructions which are equivalent with BTI c or BTI jc
depending on system register configuration.
BTI is used to mitigate JOP (Jump-oriented Programming) attacks by
limiting the set of instructions which can be jumped to.
BTI requires active linker support to mark the pages with BTI-enabled
code as guarded. For ELF64 files BTI compatibility is recorded in the
.note.gnu.property section. For a shared object or static binary it is
required that all linked units support BTI. This means that even a
single assembly file without the required note section turns-off BTI
for the whole binary or shared object.
The new BTI instructions are treated as NOPs on hardware which does
not support Armv8.5-A or on pages which are not guarded.
To insert this new and optional instruction compile with
-mbranch-protection=standard (also enables PAuth) or +bti.
When targeting a guarded page from a non-guarded page, weaker
compatibility restrictions apply to maintain compatibility between
legacy and new code. For detailed rules please refer to the Arm ARM.
Compiler support
----------------
Compiler support requires understanding '-mbranch-protection=<mode>'
and emitting the appropriate feature macros (__ARM_FEATURE_BTI_DEFAULT
and __ARM_FEATURE_PAC_DEFAULT). The current state is the following:
-------------------------------------------------------
| Compiler | -mbranch-protection | Feature macros |
+----------+---------------------+--------------------+
| clang | 9.0.0 | 11.0.0 |
+----------+---------------------+--------------------+
| gcc | 9 | expected in 10.1+ |
-------------------------------------------------------
Available Platforms
------------------
Arm Fast Model and QEMU support both extensions.
https://developer.arm.com/tools-and-software/simulation-models/fast-models
https://www.qemu.org/
Implementation Notes
--------------------
This change adds BTI landing pads even to assembly functions which are
likely to be directly called only. In these cases, landing pads might
be superfluous depending on what code the linker generates.
Code size and performance impact for these cases would be negligble.
Interaction with C code
-----------------------
Pointer Authentication is a per-frame protection while Branch Target
Identification can be turned on and off only for all code pages of a
whole shared object or static binary. Because of these properties if
C/C++ code is compiled without any of the above features but assembly
files support any of them unconditionally there is no incompatibility
between the two.
Useful Links
------------
To fully understand the details of both PAuth and BTI it is advised to
read the related chapters of the Arm Architecture Reference Manual
(Arm ARM):
https://developer.arm.com/documentation/ddi0487/latest/
Additional materials:
"Providing protection for complex software"
https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software
Arm Compiler Reference Guide Version 6.14: -mbranch-protection
https://developer.arm.com/documentation/101754/0614/armclang-Reference/armclang-Command-line-Options/-mbranch-protection?lang=en
Arm C Language Extensions (ACLE)
https://developer.arm.com/docs/101028/latest
Change-Id: I4335f92e2ccc8e209c7d68a0a79f1acdf3aeb791
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42084
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
5 years ago
|
|
|
AARCH64_VALIDATE_LINK_REGISTER
|
|
|
|
ret
|
|
|
|
.size $func,.-$func
|
|
|
|
|
|
|
|
.section .rodata
|
|
|
|
.align 6
|
|
|
|
.type .LK$BITS,%object
|
|
|
|
.LK$BITS:
|
|
|
|
___
|
|
|
|
$code.=<<___ if ($SZ==8);
|
|
|
|
.quad 0x428a2f98d728ae22,0x7137449123ef65cd
|
|
|
|
.quad 0xb5c0fbcfec4d3b2f,0xe9b5dba58189dbbc
|
|
|
|
.quad 0x3956c25bf348b538,0x59f111f1b605d019
|
|
|
|
.quad 0x923f82a4af194f9b,0xab1c5ed5da6d8118
|
|
|
|
.quad 0xd807aa98a3030242,0x12835b0145706fbe
|
|
|
|
.quad 0x243185be4ee4b28c,0x550c7dc3d5ffb4e2
|
|
|
|
.quad 0x72be5d74f27b896f,0x80deb1fe3b1696b1
|
|
|
|
.quad 0x9bdc06a725c71235,0xc19bf174cf692694
|
|
|
|
.quad 0xe49b69c19ef14ad2,0xefbe4786384f25e3
|
|
|
|
.quad 0x0fc19dc68b8cd5b5,0x240ca1cc77ac9c65
|
|
|
|
.quad 0x2de92c6f592b0275,0x4a7484aa6ea6e483
|
|
|
|
.quad 0x5cb0a9dcbd41fbd4,0x76f988da831153b5
|
|
|
|
.quad 0x983e5152ee66dfab,0xa831c66d2db43210
|
|
|
|
.quad 0xb00327c898fb213f,0xbf597fc7beef0ee4
|
|
|
|
.quad 0xc6e00bf33da88fc2,0xd5a79147930aa725
|
|
|
|
.quad 0x06ca6351e003826f,0x142929670a0e6e70
|
|
|
|
.quad 0x27b70a8546d22ffc,0x2e1b21385c26c926
|
|
|
|
.quad 0x4d2c6dfc5ac42aed,0x53380d139d95b3df
|
|
|
|
.quad 0x650a73548baf63de,0x766a0abb3c77b2a8
|
|
|
|
.quad 0x81c2c92e47edaee6,0x92722c851482353b
|
|
|
|
.quad 0xa2bfe8a14cf10364,0xa81a664bbc423001
|
|
|
|
.quad 0xc24b8b70d0f89791,0xc76c51a30654be30
|
|
|
|
.quad 0xd192e819d6ef5218,0xd69906245565a910
|
|
|
|
.quad 0xf40e35855771202a,0x106aa07032bbd1b8
|
|
|
|
.quad 0x19a4c116b8d2d0c8,0x1e376c085141ab53
|
|
|
|
.quad 0x2748774cdf8eeb99,0x34b0bcb5e19b48a8
|
|
|
|
.quad 0x391c0cb3c5c95a63,0x4ed8aa4ae3418acb
|
|
|
|
.quad 0x5b9cca4f7763e373,0x682e6ff3d6b2b8a3
|
|
|
|
.quad 0x748f82ee5defb2fc,0x78a5636f43172f60
|
|
|
|
.quad 0x84c87814a1f0ab72,0x8cc702081a6439ec
|
|
|
|
.quad 0x90befffa23631e28,0xa4506cebde82bde9
|
|
|
|
.quad 0xbef9a3f7b2c67915,0xc67178f2e372532b
|
|
|
|
.quad 0xca273eceea26619c,0xd186b8c721c0c207
|
|
|
|
.quad 0xeada7dd6cde0eb1e,0xf57d4f7fee6ed178
|
|
|
|
.quad 0x06f067aa72176fba,0x0a637dc5a2c898a6
|
|
|
|
.quad 0x113f9804bef90dae,0x1b710b35131c471b
|
|
|
|
.quad 0x28db77f523047d84,0x32caab7b40c72493
|
|
|
|
.quad 0x3c9ebe0a15c9bebc,0x431d67c49c100d4c
|
|
|
|
.quad 0x4cc5d4becb3e42b6,0x597f299cfc657e2a
|
|
|
|
.quad 0x5fcb6fab3ad6faec,0x6c44198c4a475817
|
|
|
|
.quad 0 // terminator
|
|
|
|
___
|
|
|
|
$code.=<<___ if ($SZ==4);
|
|
|
|
.long 0x428a2f98,0x71374491,0xb5c0fbcf,0xe9b5dba5
|
|
|
|
.long 0x3956c25b,0x59f111f1,0x923f82a4,0xab1c5ed5
|
|
|
|
.long 0xd807aa98,0x12835b01,0x243185be,0x550c7dc3
|
|
|
|
.long 0x72be5d74,0x80deb1fe,0x9bdc06a7,0xc19bf174
|
|
|
|
.long 0xe49b69c1,0xefbe4786,0x0fc19dc6,0x240ca1cc
|
|
|
|
.long 0x2de92c6f,0x4a7484aa,0x5cb0a9dc,0x76f988da
|
|
|
|
.long 0x983e5152,0xa831c66d,0xb00327c8,0xbf597fc7
|
|
|
|
.long 0xc6e00bf3,0xd5a79147,0x06ca6351,0x14292967
|
|
|
|
.long 0x27b70a85,0x2e1b2138,0x4d2c6dfc,0x53380d13
|
|
|
|
.long 0x650a7354,0x766a0abb,0x81c2c92e,0x92722c85
|
|
|
|
.long 0xa2bfe8a1,0xa81a664b,0xc24b8b70,0xc76c51a3
|
|
|
|
.long 0xd192e819,0xd6990624,0xf40e3585,0x106aa070
|
|
|
|
.long 0x19a4c116,0x1e376c08,0x2748774c,0x34b0bcb5
|
|
|
|
.long 0x391c0cb3,0x4ed8aa4a,0x5b9cca4f,0x682e6ff3
|
|
|
|
.long 0x748f82ee,0x78a5636f,0x84c87814,0x8cc70208
|
|
|
|
.long 0x90befffa,0xa4506ceb,0xbef9a3f7,0xc67178f2
|
|
|
|
.long 0 //terminator
|
|
|
|
___
|
|
|
|
$code.=<<___;
|
|
|
|
.size .LK$BITS,.-.LK$BITS
|
|
|
|
.asciz "SHA$BITS block transform for ARMv8, CRYPTOGAMS by <appro\@openssl.org>"
|
|
|
|
.align 2
|
|
|
|
___
|
|
|
|
|
|
|
|
if ($SZ==4) {
|
|
|
|
my $Ktbl="x3";
|
|
|
|
|
|
|
|
my ($ABCD,$EFGH,$abcd)=map("v$_.16b",(0..2));
|
|
|
|
my @MSG=map("v$_.16b",(4..7));
|
|
|
|
my ($W0,$W1)=("v16.4s","v17.4s");
|
|
|
|
my ($ABCD_SAVE,$EFGH_SAVE)=("v18.16b","v19.16b");
|
|
|
|
|
|
|
|
$code.=<<___;
|
|
|
|
.text
|
|
|
|
#ifndef __KERNEL__
|
|
|
|
.type sha256_block_armv8,%function
|
|
|
|
.align 6
|
|
|
|
sha256_block_armv8:
|
|
|
|
.Lv8_entry:
|
aarch64: support BTI and pointer authentication in assembly
This change adds optional support for
- Armv8.3-A Pointer Authentication (PAuth) and
- Armv8.5-A Branch Target Identification (BTI)
features to the perl scripts.
Both features can be enabled with additional compiler flags.
Unless any of these are enabled explicitly there is no code change at
all.
The extensions are briefly described below. Please read the appropriate
chapters of the Arm Architecture Reference Manual for the complete
specification.
Scope
-----
This change only affects generated assembly code.
Armv8.3-A Pointer Authentication
--------------------------------
Pointer Authentication extension supports the authentication of the
contents of registers before they are used for indirect branching
or load.
PAuth provides a probabilistic method to detect corruption of register
values. PAuth signing instructions generate a Pointer Authentication
Code (PAC) based on the value of a register, a seed and a key.
The generated PAC is inserted into the original value in the register.
A PAuth authentication instruction recomputes the PAC, and if it matches
the PAC in the register, restores its original value. In case of a
mismatch, an architecturally unmapped address is generated instead.
With PAuth, mitigation against ROP (Return-oriented Programming) attacks
can be implemented. This is achieved by signing the contents of the
link-register (LR) before it is pushed to stack. Once LR is popped,
it is authenticated. This way a stack corruption which overwrites the
LR on the stack is detectable.
The PAuth extension adds several new instructions, some of which are not
recognized by older hardware. To support a single codebase for both pre
Armv8.3-A targets and newer ones, only NOP-space instructions are added
by this patch. These instructions are treated as NOPs on hardware
which does not support Armv8.3-A. Furthermore, this patch only considers
cases where LR is saved to the stack and then restored before branching
to its content. There are cases in the code where LR is pushed to stack
but it is not used later. We do not address these cases as they are not
affected by PAuth.
There are two keys available to sign an instruction address: A and B.
PACIASP and PACIBSP only differ in the used keys: A and B, respectively.
The keys are typically managed by the operating system.
To enable generating code for PAuth compile with
-mbranch-protection=<mode>:
- standard or pac-ret: add PACIASP and AUTIASP, also enables BTI
(read below)
- pac-ret+b-key: add PACIBSP and AUTIBSP
Armv8.5-A Branch Target Identification
--------------------------------------
Branch Target Identification features some new instructions which
protect the execution of instructions on guarded pages which are not
intended branch targets.
If Armv8.5-A is supported by the hardware, execution of an instruction
changes the value of PSTATE.BTYPE field. If an indirect branch
lands on a guarded page the target instruction must be one of the
BTI <jc> flavors, or in case of a direct call or jump it can be any
other instruction. If the target instruction is not compatible with the
value of PSTATE.BTYPE a Branch Target Exception is generated.
In short, indirect jumps are compatible with BTI <j> and <jc> while
indirect calls are compatible with BTI <c> and <jc>. Please refer to the
specification for the details.
Armv8.3-A PACIASP and PACIBSP are implicit branch target
identification instructions which are equivalent with BTI c or BTI jc
depending on system register configuration.
BTI is used to mitigate JOP (Jump-oriented Programming) attacks by
limiting the set of instructions which can be jumped to.
BTI requires active linker support to mark the pages with BTI-enabled
code as guarded. For ELF64 files BTI compatibility is recorded in the
.note.gnu.property section. For a shared object or static binary it is
required that all linked units support BTI. This means that even a
single assembly file without the required note section turns-off BTI
for the whole binary or shared object.
The new BTI instructions are treated as NOPs on hardware which does
not support Armv8.5-A or on pages which are not guarded.
To insert this new and optional instruction compile with
-mbranch-protection=standard (also enables PAuth) or +bti.
When targeting a guarded page from a non-guarded page, weaker
compatibility restrictions apply to maintain compatibility between
legacy and new code. For detailed rules please refer to the Arm ARM.
Compiler support
----------------
Compiler support requires understanding '-mbranch-protection=<mode>'
and emitting the appropriate feature macros (__ARM_FEATURE_BTI_DEFAULT
and __ARM_FEATURE_PAC_DEFAULT). The current state is the following:
-------------------------------------------------------
| Compiler | -mbranch-protection | Feature macros |
+----------+---------------------+--------------------+
| clang | 9.0.0 | 11.0.0 |
+----------+---------------------+--------------------+
| gcc | 9 | expected in 10.1+ |
-------------------------------------------------------
Available Platforms
------------------
Arm Fast Model and QEMU support both extensions.
https://developer.arm.com/tools-and-software/simulation-models/fast-models
https://www.qemu.org/
Implementation Notes
--------------------
This change adds BTI landing pads even to assembly functions which are
likely to be directly called only. In these cases, landing pads might
be superfluous depending on what code the linker generates.
Code size and performance impact for these cases would be negligble.
Interaction with C code
-----------------------
Pointer Authentication is a per-frame protection while Branch Target
Identification can be turned on and off only for all code pages of a
whole shared object or static binary. Because of these properties if
C/C++ code is compiled without any of the above features but assembly
files support any of them unconditionally there is no incompatibility
between the two.
Useful Links
------------
To fully understand the details of both PAuth and BTI it is advised to
read the related chapters of the Arm Architecture Reference Manual
(Arm ARM):
https://developer.arm.com/documentation/ddi0487/latest/
Additional materials:
"Providing protection for complex software"
https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software
Arm Compiler Reference Guide Version 6.14: -mbranch-protection
https://developer.arm.com/documentation/101754/0614/armclang-Reference/armclang-Command-line-Options/-mbranch-protection?lang=en
Arm C Language Extensions (ACLE)
https://developer.arm.com/docs/101028/latest
Change-Id: I4335f92e2ccc8e209c7d68a0a79f1acdf3aeb791
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42084
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
5 years ago
|
|
|
// Armv8.3-A PAuth: even though x30 is pushed to stack it is not popped later.
|
|
|
|
stp x29,x30,[sp,#-16]!
|
|
|
|
add x29,sp,#0
|
|
|
|
|
|
|
|
ld1.32 {$ABCD,$EFGH},[$ctx]
|
|
|
|
adrp $Ktbl,:pg_hi21:.LK256
|
|
|
|
add $Ktbl,$Ktbl,:lo12:.LK256
|
|
|
|
|
|
|
|
.Loop_hw:
|
|
|
|
ld1 {@MSG[0]-@MSG[3]},[$inp],#64
|
|
|
|
sub $num,$num,#1
|
|
|
|
ld1.32 {$W0},[$Ktbl],#16
|
|
|
|
rev32 @MSG[0],@MSG[0]
|
|
|
|
rev32 @MSG[1],@MSG[1]
|
|
|
|
rev32 @MSG[2],@MSG[2]
|
|
|
|
rev32 @MSG[3],@MSG[3]
|
|
|
|
orr $ABCD_SAVE,$ABCD,$ABCD // offload
|
|
|
|
orr $EFGH_SAVE,$EFGH,$EFGH
|
|
|
|
___
|
|
|
|
for($i=0;$i<12;$i++) {
|
|
|
|
$code.=<<___;
|
|
|
|
ld1.32 {$W1},[$Ktbl],#16
|
|
|
|
add.i32 $W0,$W0,@MSG[0]
|
|
|
|
sha256su0 @MSG[0],@MSG[1]
|
|
|
|
orr $abcd,$ABCD,$ABCD
|
|
|
|
sha256h $ABCD,$EFGH,$W0
|
|
|
|
sha256h2 $EFGH,$abcd,$W0
|
|
|
|
sha256su1 @MSG[0],@MSG[2],@MSG[3]
|
|
|
|
___
|
|
|
|
($W0,$W1)=($W1,$W0); push(@MSG,shift(@MSG));
|
|
|
|
}
|
|
|
|
$code.=<<___;
|
|
|
|
ld1.32 {$W1},[$Ktbl],#16
|
|
|
|
add.i32 $W0,$W0,@MSG[0]
|
|
|
|
orr $abcd,$ABCD,$ABCD
|
|
|
|
sha256h $ABCD,$EFGH,$W0
|
|
|
|
sha256h2 $EFGH,$abcd,$W0
|
|
|
|
|
|
|
|
ld1.32 {$W0},[$Ktbl],#16
|
|
|
|
add.i32 $W1,$W1,@MSG[1]
|
|
|
|
orr $abcd,$ABCD,$ABCD
|
|
|
|
sha256h $ABCD,$EFGH,$W1
|
|
|
|
sha256h2 $EFGH,$abcd,$W1
|
|
|
|
|
|
|
|
ld1.32 {$W1},[$Ktbl]
|
|
|
|
add.i32 $W0,$W0,@MSG[2]
|
|
|
|
sub $Ktbl,$Ktbl,#$rounds*$SZ-16 // rewind
|
|
|
|
orr $abcd,$ABCD,$ABCD
|
|
|
|
sha256h $ABCD,$EFGH,$W0
|
|
|
|
sha256h2 $EFGH,$abcd,$W0
|
|
|
|
|
|
|
|
add.i32 $W1,$W1,@MSG[3]
|
|
|
|
orr $abcd,$ABCD,$ABCD
|
|
|
|
sha256h $ABCD,$EFGH,$W1
|
|
|
|
sha256h2 $EFGH,$abcd,$W1
|
|
|
|
|
|
|
|
add.i32 $ABCD,$ABCD,$ABCD_SAVE
|
|
|
|
add.i32 $EFGH,$EFGH,$EFGH_SAVE
|
|
|
|
|
|
|
|
cbnz $num,.Loop_hw
|
|
|
|
|
|
|
|
st1.32 {$ABCD,$EFGH},[$ctx]
|
|
|
|
|
|
|
|
ldr x29,[sp],#16
|
|
|
|
ret
|
|
|
|
.size sha256_block_armv8,.-sha256_block_armv8
|
|
|
|
#endif
|
|
|
|
___
|
|
|
|
}
|
|
|
|
|
|
|
|
$code.=<<___;
|
|
|
|
#ifndef __KERNEL__
|
|
|
|
.comm OPENSSL_armcap_P,4,4
|
|
|
|
.hidden OPENSSL_armcap_P
|
|
|
|
#endif
|
|
|
|
___
|
|
|
|
|
|
|
|
{ my %opcode = (
|
|
|
|
"sha256h" => 0x5e004000, "sha256h2" => 0x5e005000,
|
|
|
|
"sha256su0" => 0x5e282800, "sha256su1" => 0x5e006000 );
|
|
|
|
|
|
|
|
sub unsha256 {
|
|
|
|
my ($mnemonic,$arg)=@_;
|
|
|
|
|
|
|
|
$arg =~ m/[qv]([0-9]+)[^,]*,\s*[qv]([0-9]+)[^,]*(?:,\s*[qv]([0-9]+))?/o
|
|
|
|
&&
|
|
|
|
sprintf ".inst\t0x%08x\t//%s %s",
|
|
|
|
$opcode{$mnemonic}|$1|($2<<5)|($3<<16),
|
|
|
|
$mnemonic,$arg;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
open SELF,$0;
|
|
|
|
while(<SELF>) {
|
|
|
|
next if (/^#!/);
|
|
|
|
last if (!s/^#/\/\// and !/^$/);
|
|
|
|
print;
|
|
|
|
}
|
|
|
|
close SELF;
|
|
|
|
|
|
|
|
foreach(split("\n",$code)) {
|
|
|
|
|
|
|
|
s/\`([^\`]*)\`/eval($1)/geo;
|
|
|
|
|
|
|
|
s/\b(sha256\w+)\s+([qv].*)/unsha256($1,$2)/geo;
|
|
|
|
|
|
|
|
s/\.\w?32\b//o and s/\.16b/\.4s/go;
|
|
|
|
m/(ld|st)1[^\[]+\[0\]/o and s/\.4s/\.s/go;
|
|
|
|
|
|
|
|
print $_,"\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
close STDOUT or die "error closing STDOUT";
|