From 6b405053c9977e2991a8a880f197f56107e29d87 Mon Sep 17 00:00:00 2001 From: Jung-uk Kim Date: Thu, 10 Aug 2023 22:36:15 -0400 Subject: [PATCH] OpenSSL: clean up botched merges in OpenSSL 3.0.9 import No functional change intended. --- crypto/openssl/crypto/bn/bn_local.h | 20 ---------------- .../openssl/doc/man3/SSL_CTX_set_options.pod | 23 ------------------- 2 files changed, 43 deletions(-) diff --git a/crypto/openssl/crypto/bn/bn_local.h b/crypto/openssl/crypto/bn/bn_local.h index 7c4d1d3ab78a..50e9d26e215b 100644 --- a/crypto/openssl/crypto/bn/bn_local.h +++ b/crypto/openssl/crypto/bn/bn_local.h @@ -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=" 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 diff --git a/crypto/openssl/doc/man3/SSL_CTX_set_options.pod b/crypto/openssl/doc/man3/SSL_CTX_set_options.pod index 1d5656b3ca63..176f8d25fc31 100644 --- a/crypto/openssl/doc/man3/SSL_CTX_set_options.pod +++ b/crypto/openssl/doc/man3/SSL_CTX_set_options.pod @@ -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