x3dc/0x47c
cryptomgr_test+0x38/0x60
Fixes: 0e89640b640d ("crypto: arm64 - Use modern annotations for assembly
functions")
Signed-off-by: Jeremy Linton
---
arch/arm64/crypto/aes-neonbs-core.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/aes-neonbs-
wrote:
On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
The AES code uses a 'br x7' as part of a function called by
a macro. That branch needs a bti_j as a target. This results
in a panic as seen below. Instead of trying to replace the branch
target with a bti_jc, lets r
x224/0x5f0
test_skcipher+0xbc/0x120
alg_test_skcipher+0xa0/0x1b0
alg_test+0x3dc/0x47c
cryptomgr_test+0x38/0x60
Fixes: commit 0e89640b640d ("crypto: arm64 - Use modern annotations for
assembly functions")
Signed-off-by: Jeremy Linton
---
arch/arm64/crypto/aes-neonbs-core.S | 6 ++
Hi,
On 10/5/20 2:59 PM, Mark Brown wrote:
On Mon, Oct 05, 2020 at 01:18:04PM -0500, Jeremy Linton wrote:
The AES code uses a 'br x7' as part of a function called by
a macro, that ends up needing a BTI_J as a target. Lets
define SYN_CODE_START_LOCAL() for this and r
Hi,
On 10/5/20 1:54 PM, Ard Biesheuvel wrote:
On Mon, 5 Oct 2020 at 20:18, Jeremy Linton wrote:
The AES code uses a 'br x7' as part of a function called by
a macro, that ends up needing a BTI_J as a target.
Could we instead just drop the tail call, i.e, replace it with a ret
an
quot;)
Signed-off-by: Jeremy Linton
---
arch/arm64/crypto/aes-neonbs-core.S | 8
arch/arm64/include/asm/linkage.h| 6 +-
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/crypto/aes-neonbs-core.S
b/arch/arm64/crypto/aes-neonbs-core.S
index b357164379f6..76de8
ECB modes don't use an initialization vector. The kernel
/proc/crypto interface doesn't reflect this properly.
Signed-off-by: Jeremy Linton
---
arch/arm/crypto/aes-ce-glue.c | 4 ++--
arch/arm64/crypto/aes-glue.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
