| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
These files were changed as part of the 3.5.4 -> 3.5.5 upgrade. Please
see the upstream release notes linked in
1731fc70f7344af08db49b06c63c963fa12ee354, et al, for more details.
MFC after: 6 days
MFC with: 1731fc70f7344af08db49b06c63c963fa12ee354
Fixes: 1731fc70f7344af08d ("OpenSSL: update vendor sources to match 3.5.5 content")
|
| |
|
|
|
|
|
| |
in for() loops. Also, use 'while', where only the
conditional test of 'for' was used.
Reviewed by: sjg
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Separate ossl's existing AES-NI GCM implementation into a common
ossl_aes_gcm.c and add conditionals to switch between OpenSSL's AES-NI
and POWER8 GCM routines depending on the architecture. Since the
existing AVX-512 implementation is less agnostic, move it into a
separate ossl_aes_gcm_avx512.c.
Reviewed by: markj
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D44274
|
| |
|
|
|
|
|
|
|
|
| |
Migrate to OpenSSL 3.5 in advance of FreeBSD 15.0. OpenSSL 3.0 will be
EOL after 2026-09-07.
Approved by: philip (mentor)
Sponsored by: Alpha-Omega Beach Cleaning Project
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D51613
|
| |
|
|
|
|
| |
Reviewed by: imp, jhb
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D50913
|
| |
|
|
|
|
| |
MFC after: 1 week
MFC with: 0d0c8621fd181e507f0fb50ffcca606faf66a8c2
Differential Revision: https://reviews.freebsd.org/D49297
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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: a7148ab39c03abd4d1a84997c70bf96f15dd2a09
MFC with: cc717b574d7faa2e0b2de1a985076286cef74187
Differential Revision: https://reviews.freebsd.org/D46604
|
| |
|
|
| |
Sponsored by: Netflix
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Fixes: 44f8e1e8530e ("ossl: Add support for armv7")
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 9b1d87286c78 ("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: 9a3444d91c70 ("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: 9a3444d91c70 ("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
|
| |
|
|
|
| |
Fixes: ad991e4c142e ("OpenSSL: update to 3.0.12")
Sponsored by: The FreeBSD Foundation
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Reviewed by: emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41939
|
| |
|
|
|
|
| |
Tested with: cryptocheck -d ossl0 -a all -z on amd64
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D41568
|
| |
|
|
| |
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
| |
|
|
| |
Remove /^/[*/]\s*\$FreeBSD\$.*\n/
|
| |
|
|
| |
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 9a3444d91c70 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: 9a3444d91c70 ("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
|
| |
|
|
| |
X-MFC with: af19988f6cd3
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
1. https://github.com/openssl/openssl/commit/34ab13b7d8e3e723adb60be8142e38b7c9cd382a
needs to be merged for ELFv2 support on big-endian.
2. crypto/openssl/crypto/ppccap.c needs to be patched.
Same reason as in https://github.com/openssl/openssl/pull/17082.
Approved by: jkim, jhibbits
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33076
|
| |
|
|
|
|
|
|
|
| |
Now that the AES-CBC is supported we can handle ETA requests.
Sponsored by: Stormshield
Obtained from: Semihalf
Reviewed by: jhb
Differential revision: https://reviews.freebsd.org/D32100
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AES-CBC OpenSSL assembly is used underneath.
The glue layer(ossl_aes.c) is based on CHACHA20 implementation.
Contrary to the SHA and CHACHA20, AES OpenSSL assembly logic
does not have a fallback implementation in case CPU doesn't
support required instructions.
Because of that CPU caps are checked during initialization and AES
support is advertised only if available.
The feature is available on all architectures that ossl supports:
i386, amd64, arm64.
The biggest advantage of this patch over existing solutions
(aesni(4) and armv8crypto(4)) is that it supports SHA,
allowing for ETA operations.
Sponsored by: Stormshield
Obtained from: Semihalf
Reviewed by: jhb (previous version)
Differential revision: https://reviews.freebsd.org/D32099
|
| |
|
|
| |
This reverts commit 849faf4e0ba9a8b8f24ff34da93a0fd46c14eda9.
|
| |
|
|
| |
This reverts commit 048a71b46e816de8fb95b553a8ad0e98c0d51e12.
|
| |
|
|
|
|
|
|
|
| |
Now that the AES-CBC is supported we can handle ETA requests.
Sponsored by: Stormshield
Obtained from: Semihalf
Reviewed by: jhb(previous version)
Differential revision: https://reviews.freebsd.org/D32100
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AES-CBC OpenSSL assembly is used underneath.
The glue layer(ossl_aes.c) is based on CHACHA20 implementation.
Contrary to the SHA and CHACHA20, AES OpenSSL assembly logic
does not have a fallback implementation in case CPU doesn't
support required instructions.
Because of that CPU caps are checked during initialization and AES
support is advertised only if available.
The feature is available on all architectures that ossl supports:
i386, amd64, arm64.
The biggest advantage of this patch over existing solutions
(aesni(4) and armv8crypto(4)) is that it supports SHA,
allowing for ETA operations.
Sponsored by: Stormshield
Obtained from: Semihalf
Reviewed by: jhb
Differential revision: https://reviews.freebsd.org/D32099
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is useful for WireGuard which uses a nonce of 8 bytes rather
than the 12 bytes used for IPsec and TLS.
Note that this also fixes a (should be) harmless bug in ossl(4) where
the counter was incorrectly treated as a 64-bit counter instead of a
32-bit counter in terms of wrapping when using a 12 byte nonce.
However, this required a single message (TLS record) longer than 64 *
(2^32 - 1) bytes (about 256 GB) to trigger.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32122
|
| |
|
|
|
|
| |
Reviewed by: markj
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D30447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The loops for Chacha20 and Chacha20+Poly1305 which encrypted/decrypted
full blocks of data used the minimum of the input and output segment
lengths to determine the size of the next chunk ('todo') to pass to
Chacha20_ctr32(). However, the input and output segments could extend
past the end of the ciphertext region into the tag (e.g. if a "plain"
single mbuf contained an entire TLS record). If the length of the tag
plus the length of the last partial block together were at least as
large as a full Chacha20 block (64 bytes), then an extra block was
encrypted/decrypted overlapping with the tag. Fix this by also
capping the amount of data to encrypt/decrypt by the amount of
remaining data in the ciphertext region ('resid').
Reported by: gallatin
Reviewed by: cem, gallatin, markj
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D29517
|
| |
|
|
|
| |
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D28757
|
| |
|
|
|
| |
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D28756
|
| |
|
|
|
|
| |
Reviewed by: cem
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D28754
|