Visibility can get complicated when, e.g., ifuncs are involved. In
particular, SHA256/SHA512 on aarch64 use ifuncs for their _Transform
implementations, which then exposes global symbols of the same name that
break things trying to statically link both libcrypto and libmd.
Revert this part of the _Transform removal to fix the pkg-static build
on aarch64.
Fixes: 81de655acd ("libmd: stop exporting Transform() symbols")
These are reportedly likely to be specific to SSLeay's implementation
and likely not needed here. At the very least they shouldn't be used
by consumers, so let's kick them out now while we're already prepared
for a libmd soversion bump.
Requested by: delphij, fuz
They're not documented in libmd and we don't have any consumers. It's
problematic to keep them exported, as we don't currently export their
implementations. Make them all private.
PR: 280784 (exp-run)
Reviewed by: fuz
Differential Revision: https://reviews.freebsd.org/D34503
This change updates the crypto powerpc* ASM via the prescribed process
documented in `crypto/openssl/FREEBSD-upgrade`.
This change syncs the ASM with 3.0.15's generated ASM.
MFC after: 1 week
MFC with: a7148ab39c
MFC with: cc717b574d
Differential Revision: https://reviews.freebsd.org/D46604
Currently the assert checks for XOR of final and len.
This assert fails when running the unit tests in siphash_test.c.
We need to allow the case where both values are zero.
Signed-off-by: Mark O'Donovan <shiftee@posteo.net>
Reviewed by: imp, cperciva
Pull Request: https://github.com/freebsd/freebsd-src/pull/1324
Summary:
Add support for building ossl(4) on powerpc64* by implementing ossl_cpuid and
other support functions for powerpc. The required assembly files for ppc were
already present in-tree.
Test Plan: The changes were tested using the in-tree tools/tools/crypto/cryptocheck.c tool on both powerpc64 and powerpc64le on a POWER9 system.
Reviewed by: #powerpc, jhibbits, jhb
Differential Revision: https://reviews.freebsd.org/D41837
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
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
gcm_*_aesni() are used when the AVX512 implementation is not available.
Fix two bugs which manifest when handling operations spanning multiple
segments:
- Avoid underflow when the length of the input is smaller than the
residual.
- In gcm_decrypt_aesni(), ensure that we begin the operation at the
right offset into the input and output buffers.
Reviewed by: jhb
Fixes: 9b1d87286c ("ossl: Add a fallback AES-GCM implementation using AES-NI")
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D42838
ossl(4)'s AES-GCM implementation keeps mutable state in the session
structure, together with the key schedule. This was done for
convenience, as both are initialized together. However, some OCF
consumers, particularly ZFS, assume that requests may be dispatched to
the same session in parallel. Without serialization, this results in
incorrect output.
Fix the problem by explicitly copying per-session state onto the stack
at the beginning of each operation.
PR: 275306
Reviewed by: jhb
Fixes: 9a3444d91c ("ossl: Add a VAES-based AES-GCM implementation for amd64")
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D42783
Consumers may optionally provide a reference to a separate buffer
containing AAD, but ossl_aes_gcm() didn't handle this and would thus
compute an incorrect digest.
Fixes: 9a3444d91c ("ossl: Add a VAES-based AES-GCM implementation for amd64")
Reviewed by: jhb
MFC after: 3 days
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D42736
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
This adds the new BTI instructions when needed to the arm64 assembly.
Sponsored by: Arm Ltd
Reviewed by: Pierre Pronchery <pierre@freebsdfoundation.org> (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41941
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: 6485286f53 ("armv8_crypto: Switch to using FPU_KERN_NOCTX")
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41671
After commit 937b4473be 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: 937b4473be ("aesni: Switch to using FPU_KERN_NOCTX.")
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
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
There is a bug in the OpenSSL script which generates this file; the bug
is in the process of being fixed upstream.
Specifically, when generating the output, bsaes-armv7.pl strips some
labels that are used when the output asm is compiled with __KERNEL__
defined, resulting in a build error. As a step towards adding armv7
support to ossl(4), manually patch the generated asm. The upstream fix
will be imported later.
Reviewed by: andrew, jhb, emaste
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D41303
Chacha20+Poly1305 doesn't use an ossl_cipher instance the way AES-GCM
does, so ossl_lookup_cipher() failed causing ossl_newsession() to
always fail for Chacha20+Poly1305 sessions.
Reported by: gallatin (ktls_test fails with ossl.ko loaded)
Fixes: 9a3444d91c ossl: Add a VAES-based AES-GCM implementation for amd64
Tested by: gallatin
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D40580
This is required on i386. The patch has no functional change, since
AES-GCM isn't implemented for that platform.
Fixes: 9a3444d91c ("ossl: Add a VAES-based AES-GCM implementation for amd64")
Reported by: Jenkins
This lets one use ossl(4) for AES-GCM operations on contemporary amd64
platforms. A kernel benchmark indicates that this gives roughly
equivalent throughput to aesni(4) for various buffer sizes.
Bulk processing is done in aesni-gcm-x86_64.S, the rest is handled in a
C wrapper ported from OpenSSL's gcm128.c.
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Reviewed by: jhb
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D39967
aes-gcm-avx512.S is generated from OpenSSL 3.1 and implements AES-GCM.
ossl_x86.c detects whether the CPU implements the required AVX512
instructions; if not, the ossl(4) module does not provide an AES-GCM
implementation. The VAES implementation increases throughput for all
buffer sizes in both directions, up to 2x for sufficiently large
buffers.
The "process" implementation is in two parts: a generic OCF layer in
ossl_aes.c that calls a set of MD functions to do the heavy lifting.
The intent there is to make it possible to add other implementations for
other platforms, e.g., to reduce the diff required for D37421.
A follow-up commit will add a fallback path to legacy AES-NI, so that
ossl(4) can be used in preference to aesni(4) on all amd64 platforms.
In the long term we would like to replace aesni(4) and armv8crypto(4)
with ossl(4).
Note, currently this implementation will not be selected by default
since aesni(4) and ossl(4) return the same probe priority for crypto
sessions, and the opencrypto framework selects the first registered
implementation to break a tie. Since aesni(4) is compiled into the
kernel, aesni(4) wins. A separate change may modify ossl(4) to have
priority.
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Reviewed by: jhb
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D39783
This is needed to let OpenSSL 3.1 routines detect VAES and VPCLMULQDQ
extensions. The intent is to import ASM routines which implement
AES-GCM using VEX-prefixed AES-NI instructions.
No functional change intended.
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D39782
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
All the other functions used pointers for from/to instead of
fixed-size array parameters. More importantly, this function can
accept pointers to buffers of multiple blocks, not just a single
block.
Reported by: GCC -Warray-parameter
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D37547
