From: Nikola Pajkovsky Date: Thu, 10 Jul 2025 07:03:38 +0000 (+0200) Subject: sec_mem: add note about the perf implications X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c23a71635261dd69f802bcf8205d0e5016684d11;p=thirdparty%2Fopenssl.git sec_mem: add note about the perf implications Testing secure storage for ml-kem/dsa [1] shows performace penalty when secure storage is enabled. | Threads | baseline usec/handshake | secmem usec/handshake | |---------+-------------------------+-----------------------| | 1 | 586.784756 | 588.306131 | | 2 | 599.537648 | 601.007393 | | 4 | 610.663361 | 613.600663 | | 8 | 649.347376 | 869.693358 | | 16 | 1176.402781 | 2487.335286 | | 32 | 2345.594618 | 5155.747515 | | 64 | 4697.556045 | 11170.627031 | the test shows that sec mem is ok-ish up to the number of available cores, and when the sec mem lock gets contended, performance goes down rapidly. Tested on Apple M4 Pro. [1] https://github.com/openssl/openssl/pull/27625 Signed-off-by: Nikola Pajkovsky Reviewed-by: Viktor Dukhovni Reviewed-by: Kurt Roeckx Reviewed-by: Tomas Mraz Reviewed-by: Matt Caswell Reviewed-by: Paul Dale Reviewed-by: Neil Horman (Merged from https://github.com/openssl/openssl/pull/28011) (cherry picked from commit b8cc32766060757254f31139d6c521465d796d0d) --- diff --git a/doc/man3/OPENSSL_secure_malloc.pod b/doc/man3/OPENSSL_secure_malloc.pod index 1bddd773706..dbc7073aac1 100644 --- a/doc/man3/OPENSSL_secure_malloc.pod +++ b/doc/man3/OPENSSL_secure_malloc.pod @@ -45,7 +45,12 @@ the program's dynamic memory area, where keys and other sensitive information might be stored, OpenSSL supports the concept of a "secure heap." The level and type of security guarantees depend on the operating system. It is a good idea to review the code and see if it addresses your -threat model and concerns. +threat model and concerns. It should be noted that the secure heap +uses a single read/write lock, and therefore any operations +that involve allocation or freeing of secure heap memory are serialised, +blocking other threads. With that in mind, highly concurrent applications +should enable the secure heap with caution and be aware of the performance +implications for multi-threaded code. If a secure heap is used, then private key B values are stored there. This protects long-term storage of private keys, but will not necessarily @@ -135,7 +140,7 @@ a B in OpenSSL 3.0. =head1 COPYRIGHT -Copyright 2015-2024 The OpenSSL Project Authors. All Rights Reserved. +Copyright 2015-2025 The OpenSSL Project Authors. All Rights Reserved. Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy