system/freebsd-src
system/freebsd-src
1
0
Fork 0
mirror of https://github.com/freebsd/freebsd-src synced 2024-07-09 04:36:31 +00:00
Code Issues Packages Projects Releases Wiki Activity

OpenSSL: clean up botched merges in OpenSSL 3.0.9 import

Browse Source 
No functional change intended.
This commit is contained in:
Jung-uk Kim 2023-08-10 22:36:15 -04:00
parent bfed2417f4
commit 6b405053c9
2 changed files with 0 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
crypto/openssl/crypto/bn/bn_local.h
View File

@ -62,26 +62,6 @@
# define BN_SOFT_LIMIT (4096 / BN_BYTES)
# 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
# define BN_MUL_COMBA
# define BN_SQR_COMBA

23
crypto/openssl/doc/man3/SSL_CTX_set_options.pod
View File

@ -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
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
The following options no longer have any effect but their identifiers are