Three runs of timed "make check" (with suppressed output) on libgcrypt version 1.11.1, with and without the safety feature enabled, provide the following meaningful results:
safe (avg): 54.26 seconds unsafe (avg): 52.94 seconds Therefore, the performance loss of safe versus unsafe is 2.5%. In my opinion, such minimal performance loss does not justify the risk of leaving a vulnerable library around the system ! Consider, you cannot predict what applications (or libraries) are going to use libgcrypt code (now or in the future). We only know gnupg is currently using it and so a specific patch has already been posted for that... Guido On Sat, 14/06/2025 at 09.24 +0300, Jussi Kivilinna wrote: > Hello, > > On 25/05/2025 18:25, Guido Trentalancia via Gcrypt-devel wrote: > > Disable CPU speculation-related misfeatures which are in > > fact vulnerabilities causing data leaks: > > > > - Speculative Store Bypass > > - Indirect Branch Speculation > > - Flush L1D Cache on context switch out of the task > > > > For further information see the kernel documentation: > > Documentation/userspace-api/spec_ctrl.rst > > > > Signed-off-by: Guido Trentalancia <gu...@trentalancia.com> > > --- > > src/global.c | 21 +++++++++++++++++++++ > > 1 file changed, 21 insertions(+) > > > > --- a/src/global.c 2024-04-26 14:08:12.000000000 +0200 > > +++ b/src/global.c 2025-05-25 16:03:24.718598884 +0200 > > @@ -33,6 +33,7 @@ > > #ifdef HAVE_SYSLOG > > # include <syslog.h> > > #endif /*HAVE_SYSLOG*/ > > +#include <sys/prctl.h> > > > > #include "g10lib.h" > > #include "gcrypt-testapi.h" > > @@ -95,6 +96,26 @@ global_init (void) > > return; > > _gcry_global_any_init_done = 1; > > > > +/* Disable CPU speculation-related misfeatures which are in > > + * fact vulnerabilities causing data leaks: see the kernel > > + * documentation: Documentation/userspace-api/spec_ctrl.rst > > + * > > + * - Speculative Store Bypass > > + * - Indirect Branch Speculation > > + * - Flush L1D Cache on context switch out of the task > > + */ > > +#ifdef PR_SPEC_STORE_BYPASS > > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, > > PR_SPEC_FORCE_DISABLE, 0, 0); > > +#endif > > + > > +#ifdef PR_SPEC_INDIRECT_BRANCH > > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, > > PR_SPEC_FORCE_DISABLE, 0, 0); > > +#endif > > + > > +#ifdef PR_SPEC_L1D_FLUSH > > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > > PR_SPEC_FORCE_DISABLE, 0, 0); > > +#endif > > + > > Do other crypto libraries do this? Surely this control should not be > in library side but in > application. Libgcrypt could be loaded by application for number of > reasons and not all > those use-cases require toggling these knobs (such as file > checksumming, CRC or SHA). Even > worse, libgcrypt might be loaded by another library and actual > application may not even > have knowledge of that. Libgcrypt might get loaded through library > dependencies but > end up not being used by application at all (except initialization, > global_init, etc). > > -Jussi > _______________________________________________ Gcrypt-devel mailing list Gcrypt-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
