FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F14.1 2024-03-29T13:53:05Z 2024-03-29T13:53:05Z Mark Johnston markj@FreeBSD.org 2023-12-04T17:29:30Z urn:sha1:955e13a3e2a84dabe3b11b7c80bf25eaec1e50c5 Fixes: 44f8e1e8530e ("ossl: Add support for armv7") (cherry picked from commit 0eea265a58f942f7f189ba758f4cac4355d42221) 2024-03-29T13:53:05Z Mark Johnston markj@FreeBSD.org 2023-12-04T17:29:11Z urn:sha1:0b9dffed30bad28cf9b9d356480f38065db3051f OpenSSL itself keeps only a single copy of this header. Do the same in sys/crypto/openssl to avoid the extra maintenance burden. This requires adjusting the include paths for generated asm files. No functional change intended. Reported by: jrtc27 Reviewed by: jhb MFC after: 3 months Differential Revision: https://reviews.freebsd.org/D42866 (cherry picked from commit e655cc70dfcda5cfedb5a1d9bef1e87d55519f64) 2024-03-29T13:53:05Z Mark Johnston markj@FreeBSD.org 2023-11-30T17:46:54Z urn:sha1:3166bb7c107deb82236d875701f55d1940ee0e27 This provides substantially higher throughput than the fallback implementation. Reviewed by: jhb MFC after: 3 months Sponsored by: Klara, Inc. Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D41305 (cherry picked from commit 629a72376d51aad812d6f1279403bc81c38c35d2) 2024-03-29T13:53:05Z Mark Johnston markj@FreeBSD.org 2023-11-30T17:46:08Z urn:sha1:15e12749ef1dd55a18a7b1e5672e2b75f1bde68b OpenSSL provides implementations of several AES modes which use bitslicing and can be accelerated on CPUs which support the NEON extension. This patch adds arm platform support to ossl(4) and provides an AES-CBC implementation, though bsaes_cbc_encrypt() only implements decryption. The real goal is to provide an accelerated AES-GCM implementation; this will be added in a subsequent patch. Initially derived from https://reviews.freebsd.org/D37420. Reviewed by: jhb Sponsored by: Klara, Inc. Sponsored by: Stormshield MFC after: 3 months Differential Revision: https://reviews.freebsd.org/D41304 (cherry picked from commit 44f8e1e8530e1d2e95e84bbbe3d22ac9cb2557fe) 2023-12-29T21:49:42Z John Baldwin jhb@FreeBSD.org 2023-08-28T23:24:42Z urn:sha1:13d39efedb32b31a49d4d1f1176200e993708124 crypto_unregister_all already disables new sessions and waits for existing sessions to be destroyed before returning. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D41581 (cherry picked from commit 79aeecc89f5c740f2a3b0c30238233d2a6bb7ec7) 2023-12-29T21:49:42Z John Baldwin jhb@FreeBSD.org 2023-08-28T23:24:32Z urn:sha1:332774b2aff18c848e4967be024627cdeb01e337 Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D41580 (cherry picked from commit 3e912bdc31a9e5372d3cedf35c6f566871b8ede7) 2023-12-29T21:49:42Z Zachary Leaf zachary.leaf@arm.com 2023-08-31T13:11:53Z urn:sha1:f7e5bdbc683acb6c3cfb9a2ae95716e75478e776 Now armv8_crypto is using FPU_KERN_NOCTX, this results in a kernel panic in armv8_crypto.c:armv8_crypto_cipher_setup: panic: recursive fpu_kern_enter while in PCB_FP_NOSAVE state This is because in armv8_crypto.c:armv8_crypto_cipher_process, directly after calling fpu_kern_enter() a call is made to armv8_crypto_cipher_setup(), resulting in nested calls to fpu_kern_enter() without the required fpu_kern_leave() in between. Move fpu_kern_enter() in armv8_crypto_cipher_process() after the call to armv8_crypto_cipher_setup() to resolve this. Reviewed by: markj, andrew Fixes: 6485286f536f ("armv8_crypto: Switch to using FPU_KERN_NOCTX") Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D41671 (cherry picked from commit 565c887a775284bfb1a15eadee2c3f312d288c01) 2023-12-29T21:49:42Z John Baldwin jhb@FreeBSD.org 2023-08-28T23:23:43Z urn:sha1:7945b99a003fec545140532662412696e93f1ae1 crypto_unregister_all already disables new sessions and waits for existing sessions to be destroyed before returning. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D41579 (cherry picked from commit fdd51760c278302773edbd2466d35b35b865f5d9) 2023-12-29T21:49:42Z John Baldwin jhb@FreeBSD.org 2023-08-28T23:22:33Z urn:sha1:991f34a04a97e63747ae9dafc8004fdc36c421bb Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D41578 (cherry picked from commit 6485286f536f1afb36d6d39e75fceabd114b082b) 2023-12-29T21:49:42Z Mark Johnston markj@FreeBSD.org 2023-08-29T01:26:53Z urn:sha1:276666497ed1072ff663cb174eb44fe333be9ee3 After commit 937b4473be21 aesni_cipher_crypt() and aesni_cipher_mac() execute in a FPU_KERN_NOCTX section, which means that they must run with preemption disabled. These functions handle discontiguous I/O buffers by allocating a contiguous buffer and copying as necessary, but this allocation cannot happen with preemption disabled. Fix the problem by pushing the FPU section down into aesni_cipher_crypt() and aesni_cipher_mac(). In particular, encrypt-then-auth transforms need not be handled with a single FPU section. Reported by: syzbot+78258dbb02eb92157357@syzkaller.appspotmail.com Discussed with: jhb Fixes: 937b4473be21 ("aesni: Switch to using FPU_KERN_NOCTX.") (cherry picked from commit 6b635c74fd4135eaae68970bfc5aad9ae905fec7)