mirror of
https://github.com/freebsd/freebsd-src
synced 2024-10-06 16:40:47 +00:00
OpenSSL: clean up botched merges in OpenSSL 3.0.9 import
No functional change intended.
This commit is contained in:
parent
bfed2417f4
commit
6b405053c9
|
@ -62,26 +62,6 @@
|
||||||
# define BN_SOFT_LIMIT (4096 / BN_BYTES)
|
# define BN_SOFT_LIMIT (4096 / BN_BYTES)
|
||||||
# endif
|
# endif
|
||||||
|
|
||||||
/*
|
|
||||||
* This should limit the stack usage due to alloca to about 4K.
|
|
||||||
* BN_SOFT_LIMIT is a soft limit equivalent to 2*OPENSSL_RSA_MAX_MODULUS_BITS.
|
|
||||||
* Beyond that size bn_mul_mont is no longer used, and the constant time
|
|
||||||
* assembler code is disabled, due to the blatant alloca and bn_mul_mont usage.
|
|
||||||
* Note that bn_mul_mont does an alloca that is hidden away in assembly.
|
|
||||||
* It is not recommended to do computations with numbers exceeding this limit,
|
|
||||||
* since the result will be highly version dependent:
|
|
||||||
* While the current OpenSSL version will use non-optimized, but safe code,
|
|
||||||
* previous versions will use optimized code, that may crash due to unexpected
|
|
||||||
* stack overflow, and future versions may very well turn this into a hard
|
|
||||||
* limit.
|
|
||||||
* Note however, that it is possible to override the size limit using
|
|
||||||
* "./config -DBN_SOFT_LIMIT=<limit>" if necessary, and the O/S specific
|
|
||||||
* stack limit is known and taken into consideration.
|
|
||||||
*/
|
|
||||||
# ifndef BN_SOFT_LIMIT
|
|
||||||
# define BN_SOFT_LIMIT (4096 / BN_BYTES)
|
|
||||||
# endif
|
|
||||||
|
|
||||||
# ifndef OPENSSL_SMALL_FOOTPRINT
|
# ifndef OPENSSL_SMALL_FOOTPRINT
|
||||||
# define BN_MUL_COMBA
|
# define BN_MUL_COMBA
|
||||||
# define BN_SQR_COMBA
|
# define BN_SQR_COMBA
|
||||||
|
|
|
@ -317,29 +317,6 @@ only understands up to SSLv3. In this case the client must still use the
|
||||||
same SSLv3.1=TLSv1 announcement. Some clients step down to SSLv3 with respect
|
same SSLv3.1=TLSv1 announcement. Some clients step down to SSLv3 with respect
|
||||||
to the server's answer and violate the version rollback protection.)
|
to the server's answer and violate the version rollback protection.)
|
||||||
|
|
||||||
=item SSL_OP_ENABLE_KTLS
|
|
||||||
|
|
||||||
Enable the use of kernel TLS. In order to benefit from kernel TLS OpenSSL must
|
|
||||||
have been compiled with support for it, and it must be supported by the
|
|
||||||
negotiated ciphersuites and extensions. The specific ciphersuites and extensions
|
|
||||||
that are supported may vary by platform and kernel version.
|
|
||||||
|
|
||||||
The kernel TLS data-path implements the record layer, and the encryption
|
|
||||||
algorithm. The kernel will utilize the best hardware
|
|
||||||
available for encryption. Using the kernel data-path should reduce the memory
|
|
||||||
footprint of OpenSSL because no buffering is required. Also, the throughput
|
|
||||||
should improve because data copy is avoided when user data is encrypted into
|
|
||||||
kernel memory instead of the usual encrypt then copy to kernel.
|
|
||||||
|
|
||||||
Kernel TLS might not support all the features of OpenSSL. For instance,
|
|
||||||
renegotiation, and setting the maximum fragment size is not possible as of
|
|
||||||
Linux 4.20.
|
|
||||||
|
|
||||||
Note that with kernel TLS enabled some cryptographic operations are performed
|
|
||||||
by the kernel directly and not via any available OpenSSL Providers. This might
|
|
||||||
be undesirable if, for example, the application requires all cryptographic
|
|
||||||
operations to be performed by the FIPS provider.
|
|
||||||
|
|
||||||
=back
|
=back
|
||||||
|
|
||||||
The following options no longer have any effect but their identifiers are
|
The following options no longer have any effect but their identifiers are
|
||||||
|
|
Loading…
Reference in a new issue