| Message ID | 20201026230027.25813-1-ardb@kernel.org |
|---|---|
| State | Accepted |
| Commit | 519a0d7e495a6d3ce62594e485aea2a3a4a2ca0a |
| Headers | show |
| Series | crypto: arm64/poly1305-neon - reorder PAC authentication with SP update | expand |
On Tue, Oct 27, 2020 at 12:00:27AM +0100, Ard Biesheuvel wrote: > PAC pointer authentication signs the return address against the value > of the stack pointer, to prevent stack overrun exploits from corrupting > the control flow. However, this requires that the AUTIASP is issued with > SP holding the same value as it held when the PAC value was generated. > The Poly1305 NEON code got this wrong, resulting in crashes on PAC > capable hardware. > > Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS ...") > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > --- > arch/arm64/crypto/poly1305-armv8.pl | 2 +- > arch/arm64/crypto/poly1305-core.S_shipped | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) This needs to be fixed at https://github.com/dot-asm/cryptogams too, I assume? - Eric
On Tue, 27 Oct 2020 at 00:03, Eric Biggers <ebiggers@kernel.org> wrote: > > On Tue, Oct 27, 2020 at 12:00:27AM +0100, Ard Biesheuvel wrote: > > PAC pointer authentication signs the return address against the value > > of the stack pointer, to prevent stack overrun exploits from corrupting > > the control flow. However, this requires that the AUTIASP is issued with > > SP holding the same value as it held when the PAC value was generated. > > The Poly1305 NEON code got this wrong, resulting in crashes on PAC > > capable hardware. > > > > Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS ...") > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > --- > > arch/arm64/crypto/poly1305-armv8.pl | 2 +- > > arch/arm64/crypto/poly1305-core.S_shipped | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > This needs to be fixed at https://github.com/dot-asm/cryptogams too, I assume? > Yes, and in OpenSSL.
(+ Andy) On Tue, 27 Oct 2020 at 00:04, Ard Biesheuvel <ardb@kernel.org> wrote: > > On Tue, 27 Oct 2020 at 00:03, Eric Biggers <ebiggers@kernel.org> wrote: > > > > On Tue, Oct 27, 2020 at 12:00:27AM +0100, Ard Biesheuvel wrote: > > > PAC pointer authentication signs the return address against the value > > > of the stack pointer, to prevent stack overrun exploits from corrupting > > > the control flow. However, this requires that the AUTIASP is issued with > > > SP holding the same value as it held when the PAC value was generated. > > > The Poly1305 NEON code got this wrong, resulting in crashes on PAC > > > capable hardware. > > > > > > Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS ...") > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > > --- > > > arch/arm64/crypto/poly1305-armv8.pl | 2 +- > > > arch/arm64/crypto/poly1305-core.S_shipped | 2 +- > > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > This needs to be fixed at https://github.com/dot-asm/cryptogams too, I assume? > > > > Yes, and in OpenSSL.
> (+ Andy)
Thanks! Applied to cryptogams, pinged openssl. Cheers.
On Tue, Oct 27, 2020 at 12:00:27AM +0100, Ard Biesheuvel wrote: > PAC pointer authentication signs the return address against the value > of the stack pointer, to prevent stack overrun exploits from corrupting > the control flow. However, this requires that the AUTIASP is issued with > SP holding the same value as it held when the PAC value was generated. > The Poly1305 NEON code got this wrong, resulting in crashes on PAC > capable hardware. > > Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS ...") > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > --- > arch/arm64/crypto/poly1305-armv8.pl | 2 +- > arch/arm64/crypto/poly1305-core.S_shipped | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Patch applied. Thanks.
diff --git a/arch/arm64/crypto/poly1305-armv8.pl b/arch/arm64/crypto/poly1305-armv8.pl index 6e5576d19af8..cbc980fb02e3 100644 --- a/arch/arm64/crypto/poly1305-armv8.pl +++ b/arch/arm64/crypto/poly1305-armv8.pl @@ -840,7 +840,6 @@ poly1305_blocks_neon: ldp d14,d15,[sp,#64] addp $ACC2,$ACC2,$ACC2 ldr x30,[sp,#8] - .inst 0xd50323bf // autiasp //////////////////////////////////////////////////////////////// // lazy reduction, but without narrowing @@ -882,6 +881,7 @@ poly1305_blocks_neon: str x4,[$ctx,#8] // set is_base2_26 ldr x29,[sp],#80 + .inst 0xd50323bf // autiasp ret .size poly1305_blocks_neon,.-poly1305_blocks_neon diff --git a/arch/arm64/crypto/poly1305-core.S_shipped b/arch/arm64/crypto/poly1305-core.S_shipped index 8d1c4e420ccd..fb2822abf63a 100644 --- a/arch/arm64/crypto/poly1305-core.S_shipped +++ b/arch/arm64/crypto/poly1305-core.S_shipped @@ -779,7 +779,6 @@ poly1305_blocks_neon: ldp d14,d15,[sp,#64] addp v21.2d,v21.2d,v21.2d ldr x30,[sp,#8] - .inst 0xd50323bf // autiasp //////////////////////////////////////////////////////////////// // lazy reduction, but without narrowing @@ -821,6 +820,7 @@ poly1305_blocks_neon: str x4,[x0,#8] // set is_base2_26 ldr x29,[sp],#80 + .inst 0xd50323bf // autiasp ret .size poly1305_blocks_neon,.-poly1305_blocks_neon
PAC pointer authentication signs the return address against the value of the stack pointer, to prevent stack overrun exploits from corrupting the control flow. However, this requires that the AUTIASP is issued with SP holding the same value as it held when the PAC value was generated. The Poly1305 NEON code got this wrong, resulting in crashes on PAC capable hardware. Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS ...") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- arch/arm64/crypto/poly1305-armv8.pl | 2 +- arch/arm64/crypto/poly1305-core.S_shipped | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)