From collin.funk1 at gmail.com Thu Jul 3 04:51:54 2025 From: collin.funk1 at gmail.com (Collin Funk) Date: Wed, 2 Jul 2025 19:51:54 -0700 Subject: [PATCH gpgme] Remove duplicate character passed to strchr. Message-ID: <5e22d59820d24bbcfb99fbc8f5782ea51284d557.1751511107.git.collin.funk1@gmail.com> * src/keylist.c (parse_sec_field15): Remove duplicate '0' character. Signed-off-by: Collin Funk --- src/keylist.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/keylist.c b/src/keylist.c index c0bf2155..7d4c706a 100644 --- a/src/keylist.c +++ b/src/keylist.c @@ -454,7 +454,7 @@ parse_sec_field15 (gpgme_key_t key, gpgme_subkey_t subkey, char *field) subkey->secret = 0; key->secret = 1; } - else if (strchr ("01234567890ABCDEFabcdef", *field)) + else if (strchr ("0123456789ABCDEFabcdef", *field)) { /* Fields starts with a hex digit; thus it is a serial number. */ key->secret = 1; -- 2.50.0 From wk at gnupg.org Thu Jul 3 09:21:26 2025 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Jul 2025 09:21:26 +0200 Subject: [PATCH gpgme] Remove duplicate character passed to strchr. In-Reply-To: <5e22d59820d24bbcfb99fbc8f5782ea51284d557.1751511107.git.collin.funk1@gmail.com> (Collin Funk via Gnupg-devel's message of "Wed, 2 Jul 2025 19:51:54 -0700") References: <5e22d59820d24bbcfb99fbc8f5782ea51284d557.1751511107.git.collin.funk1@gmail.com> Message-ID: <87h5zt91u1.fsf@jacob.g10code.de> On Wed, 2 Jul 2025 19:51, Collin Funk said: > * src/keylist.c (parse_sec_field15): Remove duplicate '0' character. Thanks. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From wk at gnupg.org Thu Jul 3 09:24:32 2025 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Jul 2025 09:24:32 +0200 Subject: [PATCH gnupg v2] Disable CPU speculation-related misfeatures In-Reply-To: <1751021219.6405.6.camel@trentalancia.com> (Guido Trentalancia's message of "Fri, 27 Jun 2025 12:46:59 +0200") References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> Message-ID: <87cyah91ov.fsf@jacob.g10code.de> Hi! I and other already explained that the way you propose the patches is not acceptable: - No autoconf macros and possibly tests to decide whether to use the feature. - No proper ChangeLog (see gnupg/doc/HACKING) Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From collin.funk1 at gmail.com Fri Jul 4 05:34:05 2025 From: collin.funk1 at gmail.com (Collin Funk) Date: Thu, 3 Jul 2025 20:34:05 -0700 Subject: [PATCH gpgme] Fix an uninitialized variable. Message-ID: <5b1f676a4db6395e4919281b77b97e13256fe012.1751600035.git.collin.funk1@gmail.com> * src/engine-gpg.c (gpg_getdirect): Initialize ERR to zero to satisfy the loop condition. -- Fixes-commit: 0a64c7d0c6d0463cf2e06b3a01ef5be4d879bcf0 Signed-off-by: Collin Funk --- src/engine-gpg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/engine-gpg.c b/src/engine-gpg.c index b3399027..c6c5c4e6 100644 --- a/src/engine-gpg.c +++ b/src/engine-gpg.c @@ -4226,7 +4226,7 @@ gpg_getdirect (void *engine, const char *argv[], gpgme_data_t dataout, unsigned int flags) { engine_gpg_t gpg = engine; - gpgme_error_t err; + gpgme_error_t err = 0; int i; if (!engine || !argv || !dataout || flags) -- 2.50.0 From collin.funk1 at gmail.com Fri Jul 4 05:42:43 2025 From: collin.funk1 at gmail.com (Collin Funk) Date: Thu, 03 Jul 2025 20:42:43 -0700 Subject: [PATCH gpgme] Fix an uninitialized variable. In-Reply-To: <5b1f676a4db6395e4919281b77b97e13256fe012.1751600035.git.collin.funk1@gmail.com> References: <5b1f676a4db6395e4919281b77b97e13256fe012.1751600035.git.collin.funk1@gmail.com> Message-ID: <87h5zs7hak.fsf@gmail.com> Collin Funk writes: > * src/engine-gpg.c (gpg_getdirect): Initialize ERR to zero to satisfy > the loop condition. > > -- > > Fixes-commit: 0a64c7d0c6d0463cf2e06b3a01ef5be4d879bcf0 > Signed-off-by: Collin Funk > --- > src/engine-gpg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/engine-gpg.c b/src/engine-gpg.c > index b3399027..c6c5c4e6 100644 > --- a/src/engine-gpg.c > +++ b/src/engine-gpg.c > @@ -4226,7 +4226,7 @@ gpg_getdirect (void *engine, const char *argv[], > gpgme_data_t dataout, unsigned int flags) > { > engine_gpg_t gpg = engine; > - gpgme_error_t err; > + gpgme_error_t err = 0; > int i; > > if (!engine || !argv || !dataout || flags) Hi Werner, forgot to CC. Looks like this was from that commit a few months ago. The original code: gpgme_error_t err; int i; if (!engine || !argv || !dataout || flags) return gpg_error (GPG_ERR_INV_VALUE); for (i=0; !err && argv[i]; i++) if ((err = add_arg (gpg, argv[i]))) return err; Basically, the first iteration will always read an uninitialized variable. Seems mostly harmless and will probably mostly work, but UB is UB. :) Collin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From guido at trentalancia.com Fri Jul 4 16:00:49 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Fri, 04 Jul 2025 16:00:49 +0200 Subject: [PATCH gnupg v3] Disable CPU speculation-related misfeatures In-Reply-To: <87cyah91ov.fsf@jacob.g10code.de> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> Message-ID: <1751637649.6137.2.camel@trentalancia.com> I have reformatted the commit log according to the gnupg coding style as in gnupg/doc/HACKING and created a v3 patch which follows. common: Disable CPU speculation-related misfeatures * common/init.c (early_system_init): 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 diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2024-05-15 12:33:38.000000000 +0200 +++ b/common/init.c 2025-06-27 12:35:33.543235132 +0200 @@ -29,6 +29,10 @@ #include +#if defined(__linux__) +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -131,6 +135,29 @@ writestring_via_estream (int mode, const void early_system_init (void) { +#if defined(__linux__) + +/* 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 + +#endif /* __linux__ */ } On Thu, 03/07/2025 at 09.24 +0200, Werner Koch wrote: > Hi! > > I and other already explained that the way you propose the patches is > not acceptable: > > - No autoconf macros and possibly tests to decide whether to use the > feature. > > - No proper ChangeLog (see gnupg/doc/HACKING) > > > > Shalom-Salam, > > Werner > From wk at gnupg.org Sat Jul 5 13:06:38 2025 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Jul 2025 13:06:38 +0200 Subject: [PATCH gpgme] Fix an uninitialized variable. In-Reply-To: <87h5zs7hak.fsf@gmail.com> (Collin Funk via Gnupg-devel's message of "Thu, 03 Jul 2025 20:42:43 -0700") References: <5b1f676a4db6395e4919281b77b97e13256fe012.1751600035.git.collin.funk1@gmail.com> <87h5zs7hak.fsf@gmail.com> Message-ID: <877c0m522p.fsf@jacob.g10code.de> On Thu, 3 Jul 2025 20:42, Collin Funk said: > for (i=0; !err && argv[i]; i++) > Basically, the first iteration will always read an uninitialized > variable. Seems mostly harmless and will probably mostly work, but UB is > UB. :) I would not call that a undefined behaviour but a plain bug. My fault :-( Thanks for reporting. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From jussi.kivilinna at iki.fi Sat Jul 5 13:37:19 2025 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sat, 5 Jul 2025 14:37:19 +0300 Subject: [PATCH gnupg v3] Disable CPU speculation-related misfeatures In-Reply-To: <1751637649.6137.2.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> Message-ID: On 04/07/2025 17:00, Guido Trentalancia via Gnupg-devel wrote: > I have reformatted the commit log according to the gnupg coding style > as in gnupg/doc/HACKING and created a v3 patch which follows. > > common: Disable CPU speculation-related misfeatures > > * common/init.c (early_system_init): 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 > > diff -pru a/common/init.c b/common/init.c > --- a/common/init.c 2024-05-15 12:33:38.000000000 +0200 > +++ b/common/init.c 2025-06-27 12:35:33.543235132 +0200 > @@ -29,6 +29,10 @@ > > #include > > +#if defined(__linux__) > +# include > +#endif > + > #ifdef HAVE_W32_SYSTEM > # if _WIN32_WINNT < 0x0600 > # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ > @@ -131,6 +135,29 @@ writestring_via_estream (int mode, const > void > early_system_init (void) > { > +#if defined(__linux__) > + > +/* 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 There is additional documentation of PR_SET_L1D_FLUSH at https://docs.kernel.org/admin-guide/hw-vuln/l1d_flush.html There's few limitations that might be interesting from gnupg point of view: - "The kernel command line allows to control the L1D flush mitigations at boot time with the option ?l1d_flush=?. on | Enables the prctl interface, applications trying to use the prctl() will fail with an error if l1d_flush is not enabled By default the mechanism is disabled." - "NOTE : The opt-in of a task for L1D flushing works only when the task?s affinity is limited to cores running in non-SMT mode. If a task which requested L1D flushing is scheduled on a SMT-enabled core the kernel sends a SIGBUS to the task." Is it really good idea to just blindly enable this like done here? Is crashing on SIGBUS acceptable behavior? I see that there was some heated discussion on this setting in linux kernel mailing list when there was first attempt to introduce this to kernel [1]. Which makes me wonder if changing this setting is good idea at all. -Jussi [1] https://lore.kernel.org/lkml/CAHk-=wgXf_wQ9zrJKv2Hy4EpEbLuqty-Cjbs2u00gm7XcYHBfw at mail.gmail.com/ > + > +#endif /* __linux__ */ > } > > > > On Thu, 03/07/2025 at 09.24 +0200, Werner Koch wrote: >> Hi! >> >> I and other already explained that the way you propose the patches is >> not acceptable: >> >> - No autoconf macros and possibly tests to decide whether to use the >> feature. >> >> - No proper ChangeLog (see gnupg/doc/HACKING) >> >> >> >> Shalom-Salam, >> >> Werner >> > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From guido at trentalancia.com Sun Jul 6 17:10:07 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Sun, 06 Jul 2025 17:10:07 +0200 Subject: [PATCH gnupg v3] Disable CPU speculation-related misfeatures In-Reply-To: References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> Message-ID: <1751814607.10569.5.camel@trentalancia.com> Please note that Level 1 Data Cache flushing is disabled. So, at the moment the corresponding vulnerability CVE-2020-0550 is not being addressed. That specific part can be enabled at a later time with an additional patch, for example through a specific autoconf configure option (say -- enable-l1d-cache-flushing or --enable-fix-CVE-2020-0550). Guido On Sat, 05/07/2025 at 14.37 +0300, Jussi Kivilinna wrote: > On 04/07/2025 17:00, Guido Trentalancia via Gnupg-devel wrote: > > I have reformatted the commit log according to the gnupg coding > > style > > as in gnupg/doc/HACKING and created a v3 patch which follows. > > > > common: Disable CPU speculation-related misfeatures > > > > * common/init.c (early_system_init): 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 > > > > diff -pru a/common/init.c b/common/init.c > > --- a/common/init.c 2024-05-15 12:33:38.000000000 +0200 > > +++ b/common/init.c 2025-06-27 12:35:33.543235132 +0200 > > @@ -29,6 +29,10 @@ > > > > #include > > > > +#if defined(__linux__) > > +# include > > +#endif > > + > > #ifdef HAVE_W32_SYSTEM > > # if _WIN32_WINNT < 0x0600 > > # define _WIN32_WINNT 0x0600 /* Required for > > SetProcessDEPPolicy. */ > > @@ -131,6 +135,29 @@ writestring_via_estream (int mode, const > > void > > early_system_init (void) > > { > > +#if defined(__linux__) > > + > > +/* 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 > > There is additional documentation of PR_SET_L1D_FLUSH at > https://docs.kernel.org/admin-guide/hw-vuln/l1d_flush.html > > There's few limitations that might be interesting from gnupg point of > view: > - "The kernel command line allows to control the L1D flush > mitigations > at boot time with the option ?l1d_flush=?. > on | Enables the prctl interface, applications trying to use > the prctl() > will fail with an error if l1d_flush is not enabled > By default the mechanism is disabled." > - "NOTE : The opt-in of a task for L1D flushing works only when the > task?s > affinity is limited to cores running in non-SMT mode. If a task > which > requested L1D flushing is scheduled on a SMT-enabled core the > kernel > sends a SIGBUS to the task." > > Is it really good idea to just blindly enable this like done > here? Is crashing on SIGBUS acceptable behavior? > > I see that there was some heated discussion on this setting in linux > kernel mailing list when there was first attempt to introduce this > to kernel [1]. Which makes me wonder if changing this setting is good > idea at all. > > -Jussi > > [1] https://lore.kernel.org/lkml/CAHk-=wgXf_wQ9zrJKv2Hy4EpEbLuqty-Cjb > s2u00gm7XcYHBfw at mail.gmail.com/ > > > + > > +#endif /* __linux__ */ > > } > > > > > > > > On Thu, 03/07/2025 at 09.24 +0200, Werner Koch wrote: > > > Hi! > > > > > > I and other already explained that the way you propose the > > > patches is > > > not acceptable: > > > > > > - No autoconf macros and possibly tests to decide whether to use > > > the > > > feature. > > > > > > - No proper ChangeLog (see gnupg/doc/HACKING) > > > > > > > > > > > > Shalom-Salam, > > > > > > Werner > > > > > > > _______________________________________________ > > Gnupg-devel mailing list > > Gnupg-devel at gnupg.org > > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > From guido at trentalancia.com Sun Jul 6 21:50:52 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Sun, 06 Jul 2025 21:50:52 +0200 Subject: [PATCH gnupg v4] Disable CPU speculation-related misfeatures In-Reply-To: <1751814607.10569.5.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> Message-ID: <1751831452.25372.4.camel@trentalancia.com> The following new v4 version has been created taking into account more recent discussions on the L1 Data Cache vulnerability. It should cater to the needs of most users, while it can also be configured for special cases... common: Disable CPU speculation-related misfeatures * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h * common/init.c (early_system_init): Disable CPU speculation-related misfeatures which are in fact vulnerabilities causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-06 18:24:18.564538076 +0200 @@ -29,6 +29,10 @@ #include +#if defined(__linux__) +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -132,6 +136,29 @@ writestring_via_estream (int mode, const void early_system_init (void) { +#if defined(__linux__) + +/* 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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0); +#endif + +#endif /* __linux__ */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-06 21:34:17.915056552 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,13 +1323,23 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) AC_CHECK_HEADERS([unistd.h langinfo.h termio.h locale.h \ pwd.h inttypes.h signal.h sys/select.h sys/time.h \ stdint.h signal.h termios.h \ - ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) + ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h \ + sys/prctl.h]) # On Sun, 06/07/2025 at 17.10 +0200, Guido Trentalancia via Gnupg-devel wrote: > Please note that Level 1 Data Cache flushing is disabled. > > So, at the moment the corresponding vulnerability CVE-2020-0550 is > not > being addressed. > > That specific part can be enabled at a later time with an additional > patch, for example through a specific autoconf configure option (say > -- > enable-l1d-cache-flushing or --enable-fix-CVE-2020-0550). > > Guido > > On Sat, 05/07/2025 at 14.37 +0300, Jussi Kivilinna wrote: > > On 04/07/2025 17:00, Guido Trentalancia via Gnupg-devel wrote: > > > I have reformatted the commit log according to the gnupg coding > > > style > > > as in gnupg/doc/HACKING and created a v3 patch which follows. > > > > > > common: Disable CPU speculation-related misfeatures > > > > > > * common/init.c (early_system_init): 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 > > > > > > diff -pru a/common/init.c b/common/init.c > > > --- a/common/init.c 2024-05-15 12:33:38.000000000 +0200 > > > +++ b/common/init.c 2025-06-27 12:35:33.543235132 +0200 > > > @@ -29,6 +29,10 @@ > > > > > > #include > > > > > > +#if defined(__linux__) > > > +# include > > > +#endif > > > + > > > #ifdef HAVE_W32_SYSTEM > > > # if _WIN32_WINNT < 0x0600 > > > # define _WIN32_WINNT 0x0600 /* Required for > > > SetProcessDEPPolicy. */ > > > @@ -131,6 +135,29 @@ writestring_via_estream (int mode, const > > > void > > > early_system_init (void) > > > { > > > +#if defined(__linux__) > > > + > > > +/* 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 > > > > There is additional documentation of PR_SET_L1D_FLUSH at > > https://docs.kernel.org/admin-guide/hw-vuln/l1d_flush.html > > > > There's few limitations that might be interesting from gnupg point > > of > > view: > > - "The kernel command line allows to control the L1D flush > > mitigations > > at boot time with the option ?l1d_flush=?. > > on | Enables the prctl interface, applications trying to use > > the prctl() > > will fail with an error if l1d_flush is not enabled > > By default the mechanism is disabled." > > - "NOTE : The opt-in of a task for L1D flushing works only when > > the > > task?s > > affinity is limited to cores running in non-SMT mode. If a > > task > > which > > requested L1D flushing is scheduled on a SMT-enabled core the > > kernel > > sends a SIGBUS to the task." > > > > Is it really good idea to just blindly enable this like done > > here? Is crashing on SIGBUS acceptable behavior? > > > > I see that there was some heated discussion on this setting in > > linux > > kernel mailing list when there was first attempt to introduce this > > to kernel [1]. Which makes me wonder if changing this setting is > > good > > idea at all. > > > > -Jussi > > > > [1] https://lore.kernel.org/lkml/CAHk-=wgXf_wQ9zrJKv2Hy4EpEbLuqty-C > > jb > > s2u00gm7XcYHBfw at mail.gmail.com/ > > > > > + > > > +#endif /* __linux__ */ > > > } > > > > > > > > > > > > On Thu, 03/07/2025 at 09.24 +0200, Werner Koch wrote: > > > > Hi! > > > > > > > > I and other already explained that the way you propose the > > > > patches is > > > > not acceptable: > > > > > > > > - No autoconf macros and possibly tests to decide whether to > > > > use > > > > the > > > > feature. > > > > > > > > - No proper ChangeLog (see gnupg/doc/HACKING) > > > > > > > > > > > > > > > > Shalom-Salam, > > > > > > > > Werner > > > > > > > > > > _______________________________________________ > > > Gnupg-devel mailing list > > > Gnupg-devel at gnupg.org > > > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From guido at trentalancia.com Sun Jul 6 22:03:56 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Sun, 06 Jul 2025 22:03:56 +0200 Subject: [PATCH gnupg v5] Disable CPU speculation-related misfeatures In-Reply-To: <1751831452.25372.4.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> Message-ID: <1751832236.25372.6.camel@trentalancia.com> Same as v4, but avoiding possible build failures on non-linux systems. common: Disable CPU speculation-related misfeatures * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPU speculation-related misfeatures which are in fact vulnerabilities causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-06 18:24:18.564538076 +0200 @@ -29,6 +29,10 @@ #include +#if defined(__linux__) +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -132,6 +136,29 @@ writestring_via_estream (int mode, const void early_system_init (void) { +#if defined(__linux__) + +/* 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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0); +#endif + +#endif /* __linux__ */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,6 +1323,15 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl() +case "${host}" in + *-*-linux*) + AC_CHECK_HEADERS([sys/prctl.h]) + ;; +esac + # # Checks for typedefs, structures, and compiler characteristics. # On Sun, 06/07/2025 at 21.50 +0200, Guido Trentalancia via Gnupg-devel wrote: > The following new v4 version has been created taking into account > more > recent discussions on the L1 Data Cache vulnerability. It should > cater > to the needs of most users, while it can also be configured for > special > cases... > > common: Disable CPU speculation-related misfeatures > > * configure.ac: add a new L1D Cache flushing option > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > and check for sys/prctl.h > > * common/init.c (early_system_init): Disable CPU > speculation-related misfeatures which are in fact > vulnerabilities causing data leaks: > > - Speculative Store Bypass (always disabled) > - Indirect Branch Speculation (always disabled) > - Flush L1D Cache on context switch out of the > task (use the --enable-l1d-cache-flushing > configure option to mitigate the vulnerability) > > For further information see the kernel documentation: > Documentation/userspace-api/spec_ctrl.rst > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > Signed-off-by: Guido Trentalancia > > diff -pru a/common/init.c b/common/init.c > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > +++ b/common/init.c 2025-07-06 18:24:18.564538076 +0200 > @@ -29,6 +29,10 @@ > > #include > > +#if defined(__linux__) > +# include > +#endif > + > #ifdef HAVE_W32_SYSTEM > # if _WIN32_WINNT < 0x0600 > # define _WIN32_WINNT 0x0600 /* Required for > SetProcessDEPPolicy. */ > @@ -132,6 +136,29 @@ writestring_via_estream (int mode, const > void > early_system_init (void) > { > +#if defined(__linux__) > + > +/* 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 > + > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, > 0, 0); > +#endif > + > +#endif /* __linux__ */ > } > > > diff -pru a/configure.ac b/configure.ac > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > +++ b/configure.ac 2025-07-06 21:34:17.915056552 +0200 > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > AC_MSG_RESULT($selinux_support) > > > +# Fix security vulnerability CVE-2020-0550 by enabling > +# Level 1 Data Cache flushing on context switch. > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > switch]) > +AC_ARG_ENABLE(l1d-cache-flushing, > + AS_HELP_STRING([--enable-l1d-cache-flushing], > + [enable L1D cache flushing]), > + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) > +AC_MSG_RESULT($l1d_cache_flushing) > + > + > AC_MSG_CHECKING([whether to allocate extra secure memory]) > AC_ARG_ENABLE(large-secmem, > AS_HELP_STRING([--enable-large-secmem], > @@ -1313,13 +1323,23 @@ fi > > > # > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > +# > +if test "$l1d_cache_flushing" = yes ; then > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > + [Define to enable Layer 1 Data Cache flushing]) > +fi > + > + > +# > # Checks for header files. > # > AC_MSG_NOTICE([checking for header files]) > AC_CHECK_HEADERS([unistd.h langinfo.h termio.h locale.h \ > pwd.h inttypes.h signal.h sys/select.h sys/time.h > \ > stdint.h signal.h termios.h \ > - ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) > + ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h \ > + sys/prctl.h]) > > > # > > On Sun, 06/07/2025 at 17.10 +0200, Guido Trentalancia via > Gnupg-devel wrote: > > Please note that Level 1 Data Cache flushing is disabled. > > > > So, at the moment the corresponding vulnerability CVE-2020-0550 is > > not > > being addressed. > > > > That specific part can be enabled at a later time with an > > additional > > patch, for example through a specific autoconf configure option > > (say > > -- > > enable-l1d-cache-flushing or --enable-fix-CVE-2020-0550). > > > > Guido > > > > On Sat, 05/07/2025 at 14.37 +0300, Jussi Kivilinna wrote: > > > On 04/07/2025 17:00, Guido Trentalancia via Gnupg-devel wrote: > > > > I have reformatted the commit log according to the gnupg coding > > > > style > > > > as in gnupg/doc/HACKING and created a v3 patch which follows. > > > > > > > > common: Disable CPU speculation-related misfeatures > > > > > > > > * common/init.c (early_system_init): 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 > > > > > > > > diff -pru a/common/init.c b/common/init.c > > > > --- a/common/init.c 2024-05-15 12:33:38.000000000 +0200 > > > > +++ b/common/init.c 2025-06-27 12:35:33.543235132 +0200 > > > > @@ -29,6 +29,10 @@ > > > > > > > > #include > > > > > > > > +#if defined(__linux__) > > > > +# include > > > > +#endif > > > > + > > > > #ifdef HAVE_W32_SYSTEM > > > > # if _WIN32_WINNT < 0x0600 > > > > # define _WIN32_WINNT 0x0600 /* Required for > > > > SetProcessDEPPolicy. */ > > > > @@ -131,6 +135,29 @@ writestring_via_estream (int mode, const > > > > void > > > > early_system_init (void) > > > > { > > > > +#if defined(__linux__) > > > > + > > > > +/* 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 > > > > > > There is additional documentation of PR_SET_L1D_FLUSH at > > > https://docs.kernel.org/admin-guide/hw-vuln/l1d_flush.html > > > > > > There's few limitations that might be interesting from gnupg > > > point > > > of > > > view: > > > - "The kernel command line allows to control the L1D flush > > > mitigations > > > at boot time with the option ?l1d_flush=?. > > > on | Enables the prctl interface, applications trying to > > > use > > > the prctl() > > > will fail with an error if l1d_flush is not enabled > > > By default the mechanism is disabled." > > > - "NOTE : The opt-in of a task for L1D flushing works only when > > > the > > > task?s > > > affinity is limited to cores running in non-SMT mode. If a > > > task > > > which > > > requested L1D flushing is scheduled on a SMT-enabled core > > > the > > > kernel > > > sends a SIGBUS to the task." > > > > > > Is it really good idea to just blindly enable this like done > > > here? Is crashing on SIGBUS acceptable behavior? > > > > > > I see that there was some heated discussion on this setting in > > > linux > > > kernel mailing list when there was first attempt to introduce > > > this > > > to kernel [1]. Which makes me wonder if changing this setting is > > > good > > > idea at all. > > > > > > -Jussi > > > > > > [1] https://lore.kernel.org/lkml/CAHk-=wgXf_wQ9zrJKv2Hy4EpEbLuqty > > > -C > > > jb > > > s2u00gm7XcYHBfw at mail.gmail.com/ > > > > > > > + > > > > +#endif /* __linux__ */ > > > > } > > > > > > > > > > > > > > > > On Thu, 03/07/2025 at 09.24 +0200, Werner Koch wrote: > > > > > Hi! > > > > > > > > > > I and other already explained that the way you propose the > > > > > patches is > > > > > not acceptable: > > > > > > > > > > - No autoconf macros and possibly tests to decide whether to > > > > > use > > > > > the > > > > > feature. > > > > > > > > > > - No proper ChangeLog (see gnupg/doc/HACKING) > > > > > > > > > > > > > > > > > > > > Shalom-Salam, > > > > > > > > > > Werner > > > > > > > > > > > > > _______________________________________________ > > > > Gnupg-devel mailing list > > > > Gnupg-devel at gnupg.org > > > > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > > > > > > > > > _______________________________________________ > > Gnupg-devel mailing list > > Gnupg-devel at gnupg.org > > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From jcb62281 at gmail.com Mon Jul 7 02:00:25 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 6 Jul 2025 19:00:25 -0500 Subject: [PATCH gnupg v5] Disable CPU speculation-related misfeatures In-Reply-To: <1751832236.25372.6.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <1751832236.25372.6.camel@trentalancia.com> Message-ID: <66c9be4c-0d4e-4ae0-88bb-ef5e34db6c1a@gmail.com> On 7/6/25 15:03, Guido Trentalancia via Gnupg-devel wrote: > [...] > diff -pru a/common/init.c b/common/init.c > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > +++ b/common/init.c 2025-07-06 18:24:18.564538076 +0200 > [...] > @@ -132,6 +136,29 @@ writestring_via_estream (int mode, const > void > early_system_init (void) > { > +#if defined(__linux__) > + > +/* 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 > + > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0); My understanding is that this prctl(2) call raises SIGBUS unless the kernel was given a boot option to enable this workaround.? If a library is going to do this behind the main program's back, that library *needs* to be prepared to catch a SIGBUS at this point. > +#endif > + > +#endif /* __linux__ */ > } > > > diff -pru a/configure.ac b/configure.ac > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > AC_MSG_RESULT($selinux_support) > > > +# Fix security vulnerability CVE-2020-0550 by enabling > +# Level 1 Data Cache flushing on context switch. > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) This message is worded very badly:? the configure script is *not* checking whether context switches flush L1; it is checking whether the configuration option to *request* that context switches flush L1 has been given. A better way to word this would be "[whether L1 data cache should be flushed on context switch]". > +AC_ARG_ENABLE(l1d-cache-flushing, > + AS_HELP_STRING([--enable-l1d-cache-flushing], > + [enable L1D cache flushing]), > + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) > +AC_MSG_RESULT($l1d_cache_flushing) > + > + > AC_MSG_CHECKING([whether to allocate extra secure memory]) > AC_ARG_ENABLE(large-secmem, > AS_HELP_STRING([--enable-large-secmem], > @@ -1313,6 +1323,15 @@ fi > > > # > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > +# > +if test "$l1d_cache_flushing" = yes ; then > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > + [Define to enable Layer 1 Data Cache flushing]) Again, this *enables* nothing; it causes the program to *request* the L1 cache be flushed on context switch. > +fi > + > + > +# > # Checks for header files. > # > AC_MSG_NOTICE([checking for header files]) > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) > > > +# See whether libc supports the prctl() > +case "${host}" in > + *-*-linux*) > + AC_CHECK_HEADERS([sys/prctl.h]) > + ;; > +esac > + > # > # Checks for typedefs, structures, and compiler characteristics. > # > [...] Overall, I am still unconvinced of the appropriateness of this patch.? As I understand, these leaks only matter in multi-tenant systems, or if Mallory otherwise has access to your machine, in which case you have bigger problems if your private key is on such a system. -- Jacob From wk at gnupg.org Mon Jul 7 18:36:19 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Jul 2025 18:36:19 +0200 Subject: [PATCH gnupg v4] Disable CPU speculation-related misfeatures In-Reply-To: <1751831452.25372.4.camel@trentalancia.com> (Guido Trentalancia via Gnupg-devel's message of "Sun, 06 Jul 2025 21:50:52 +0200") References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> Message-ID: <875xg42c1o.fsf@jacob.g10code.de> Hi! On Sun, 6 Jul 2025 21:50, Guido Trentalancia said: > common: Disable CPU speculation-related misfeatures I would prefer to keep the subject clear of an opinion. > +#if defined(__linux__) > +# include > +#endif Good. You now provide configure tests. Please also add a general one which checks for this header. > +#if defined(__linux__) And use that here ;-) > AC_CHECK_HEADERS([unistd.h langinfo.h termio.h locale.h \ > pwd.h inttypes.h signal.h sys/select.h sys/time.h \ > stdint.h signal.h termios.h \ > - ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) > + ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h \ > + sys/prctl.h]) Hey, you already got that macro. Thus you can replace the above with #if defined(HAVE_SYS_PRCTL_H) && defined(__linux__) and we are good. The ifdef __linux__ here is so that we cater for OSes which have such a header for different purposes. Using the standard configure test along with a ifdef in the code is a good compromise between readibility and regualar autoconf style. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From guido at trentalancia.com Mon Jul 7 19:17:54 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Mon, 07 Jul 2025 19:17:54 +0200 Subject: [PATCH gnupg v6] Disable CPU speculation-related misfeatures In-Reply-To: <875xg42c1o.fsf@jacob.g10code.de> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> Message-ID: <1751908674.7090.8.camel@trentalancia.com> On Mon, 07/07/2025 alle 18.36 +0200, Werner Koch wrote: > Hi! > > On Sun, 6 Jul 2025 21:50, Guido Trentalancia said: > > > common: Disable CPU speculation-related misfeatures > > I would prefer to keep the subject clear of an opinion. It's not an opinion, it's a fact. The wording is taken from the official Linux kernel documentation, however I agree it's probably too delicate, the correct wording is "security vulnerabilities". > > +#if defined(__linux__) > > +# include > > +#endif > > Good. You now provide configure tests. Please also add a general > one > which checks for this header. A general check for sys/prctl.h is not needed, as such header file is only used on Linux-specific code and it can therefore break things on non-Linux systems. > > +#if defined(__linux__) > > And use that here ;-) > > > AC_CHECK_HEADERS([unistd.h langinfo.h termio.h locale.h \ > > pwd.h inttypes.h signal.h sys/select.h > > sys/time.h \ > > stdint.h signal.h termios.h \ > > - ucred.h sys/ucred.h sys/sysmacros.h > > sys/mkdev.h]) > > + ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h > > \ > > + sys/prctl.h]) > > Hey, you already got that macro. Thus you can replace the above with > > #if defined(HAVE_SYS_PRCTL_H) && defined(__linux__) I can replace that, in reversed order. Please see the v6 patch below, my last attempt at fixing this... > and we are good. The ifdef __linux__ here is so that we cater for > OSes > which have such a header for different purposes. Using the standard > configure test along with a ifdef in the code is a good compromise > between readibility and regualar autoconf style. common: Disable CPU speculation-related security vulnerabilities (CVE-2018-3639 aka Spectre variant 4, CVE-2017-5715 and optionally CVE-2020-0550) * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPU speculation-related misfeatures which are in fact vulnerabilities causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 @@ -29,6 +29,10 @@ #include +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -132,6 +136,29 @@ writestring_via_estream (int mode, const void early_system_init (void) { +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) + +/* Disable CPU speculation-related security vulnerabilities + * causing data leaks: see the Linux 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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0); +#endif + +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,6 +1323,15 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl() +case "${host}" in + *-*-linux*) + AC_CHECK_HEADERS([sys/prctl.h]) + ;; +esac + # # Checks for typedefs, structures, and compiler characteristics. # From guido at trentalancia.com Tue Jul 8 13:05:00 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Tue, 08 Jul 2025 13:05:00 +0200 Subject: [PATCH gnupg v7] Disable CPU speculation-related misfeatures In-Reply-To: <1751908674.7090.8.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> Message-ID: <1751972700.857.4.camel@trentalancia.com> In the following v7 patch I have improved the commit log and source code comments, with a better explaination of how to fix CVE-2020-0550 (L1 Data Cache flush). common: Disable CPU speculative execution security vulnerabilities (CVE-2018-3639 aka Spectre variant 4, CVE-2017-5715 and optionally CVE-2020-0550) * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPU speculative execution security vulnerabilities potentially causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option and l1d_flush=on on the boot command line to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 @@ -29,6 +29,10 @@ #include +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -132,6 +136,32 @@ writestring_via_estream (int mode, const void early_system_init (void) { +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) + +/* Disable CPU speculative execution security vulnerabilities + * causing data leaks: see the Linux kernel documentation + * Documentation/userspace-api/spec_ctrl.rst + * + * - Speculative Store Bypass (CVE-2018-3639, always + * disabled) + * - Indirect Branch Speculation (CVE-2017-5715, always + * disabled) + * - Flush L1D Cache on context switch out of the task (it + * requires the l1d_flush=on kernel boot parameter) + */ +#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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0); +#endif + +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,6 +1323,15 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl() +case "${host}" in + *-*-linux*) + AC_CHECK_HEADERS([sys/prctl.h]) + ;; +esac + # # Checks for typedefs, structures, and compiler characteristics. # On Mon, 07/07/2025 at 19.17 +0200, Guido Trentalancia via Gnupg-devel wrote: > On Mon, 07/07/2025 alle 18.36 +0200, Werner Koch wrote: > > Hi! > > > > On Sun, 6 Jul 2025 21:50, Guido Trentalancia said: > > > > > common: Disable CPU speculation-related misfeatures > > > > I would prefer to keep the subject clear of an opinion. > > It's not an opinion, it's a fact. > > The wording is taken from the official Linux kernel documentation, > however I agree it's probably too delicate, the correct wording is > "security vulnerabilities". > > > > +#if defined(__linux__) > > > +# include > > > +#endif > > > > Good. You now provide configure tests. Please also add a general > > one > > which checks for this header. > > A general check for sys/prctl.h is not needed, as such header file is > only used on Linux-specific code and it can therefore break things on > non-Linux systems. > > > > +#if defined(__linux__) > > > > And use that here ;-) > > > > > AC_CHECK_HEADERS([unistd.h langinfo.h termio.h locale.h \ > > > pwd.h inttypes.h signal.h sys/select.h > > > sys/time.h \ > > > stdint.h signal.h termios.h \ > > > - ucred.h sys/ucred.h sys/sysmacros.h > > > sys/mkdev.h]) > > > + ucred.h sys/ucred.h sys/sysmacros.h > > > sys/mkdev.h > > > \ > > > + sys/prctl.h]) > > > > Hey, you already got that macro. Thus you can replace the above > > with > > > > #if defined(HAVE_SYS_PRCTL_H) && defined(__linux__) > > I can replace that, in reversed order. Please see the v6 patch below, > my last attempt at fixing this... > > > and we are good. The ifdef __linux__ here is so that we cater for > > OSes > > which have such a header for different purposes. Using the > > standard > > configure test along with a ifdef in the code is a good compromise > > between readibility and regualar autoconf style. > > common: Disable CPU speculation-related security > vulnerabilities (CVE-2018-3639 aka Spectre variant 4, > CVE-2017-5715 and optionally CVE-2020-0550) > > * configure.ac: add a new L1D Cache flushing option > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > and check for sys/prctl.h on Linux systems > > * common/init.c (early_system_init): Disable CPU > speculation-related misfeatures which are in fact > vulnerabilities causing data leaks: > > - Speculative Store Bypass (always disabled) > - Indirect Branch Speculation (always disabled) > - Flush L1D Cache on context switch out of the > task (use the --enable-l1d-cache-flushing > configure option to mitigate the vulnerability) > > For further information see the kernel documentation: > Documentation/userspace-api/spec_ctrl.rst > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > Signed-off-by: Guido Trentalancia > > diff -pru a/common/init.c b/common/init.c > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 > @@ -29,6 +29,10 @@ > > #include > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > +# include > +#endif > + > #ifdef HAVE_W32_SYSTEM > # if _WIN32_WINNT < 0x0600 > # define _WIN32_WINNT 0x0600 /* Required for > SetProcessDEPPolicy. */ > @@ -132,6 +136,29 @@ writestring_via_estream (int mode, const > void > early_system_init (void) > { > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > + > +/* Disable CPU speculation-related security vulnerabilities > + * causing data leaks: see the Linux 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 > + > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, > 0, 0); > +#endif > + > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > } > > > diff -pru a/configure.ac b/configure.ac > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > AC_MSG_RESULT($selinux_support) > > > +# Fix security vulnerability CVE-2020-0550 by enabling > +# Level 1 Data Cache flushing on context switch. > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > switch]) > +AC_ARG_ENABLE(l1d-cache-flushing, > + AS_HELP_STRING([--enable-l1d-cache-flushing], > + [enable L1D cache flushing]), > + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) > +AC_MSG_RESULT($l1d_cache_flushing) > + > + > AC_MSG_CHECKING([whether to allocate extra secure memory]) > AC_ARG_ENABLE(large-secmem, > AS_HELP_STRING([--enable-large-secmem], > @@ -1313,6 +1323,15 @@ fi > > > # > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > +# > +if test "$l1d_cache_flushing" = yes ; then > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > + [Define to enable Layer 1 Data Cache flushing]) > +fi > + > + > +# > # Checks for header files. > # > AC_MSG_NOTICE([checking for header files]) > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) > > > +# See whether libc supports the prctl() > +case "${host}" in > + *-*-linux*) > + AC_CHECK_HEADERS([sys/prctl.h]) > + ;; > +esac > + > # > # Checks for typedefs, structures, and compiler characteristics. > # > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From guido at trentalancia.com Tue Jul 8 16:05:58 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Tue, 08 Jul 2025 16:05:58 +0200 Subject: [PATCH gnupg v8] Disable CPU speculation-related misfeatures In-Reply-To: <1751972700.857.4.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> Message-ID: <1751983558.11004.3.camel@trentalancia.com> I have now further improved the documentation of how to use L1 Data Cache flushing, this should answer the question raised by Jussi Kivilinna regarding the SIGBUS error. A new v8 patch has been created. common: Disable CPU speculative execution security vulnerabilities (CVE-2018-3639 aka Spectre variant 4, CVE-2017-5715 and optionally CVE-2020-0550) * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPU speculative execution security vulnerabilities potentially causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option and "nosmt l1d_flush=on" on the boot command line to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 @@ -29,6 +29,10 @@ #include +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -132,6 +136,32 @@ writestring_via_estream (int mode, const void early_system_init (void) { +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) + +/* Disable CPU speculative execution security vulnerabilities + * causing data leaks: see the Linux kernel documentation + * Documentation/userspace-api/spec_ctrl.rst + * + * - Speculative Store Bypass (CVE-2018-3639, always + * disabled) + * - Indirect Branch Speculation (CVE-2017-5715, always + * disabled) + * - Flush L1D Cache on context switch out of the task (it + * requires the "nosmt l1d_flush=on" kernel boot parameter) + */ +#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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0); +#endif + +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,6 +1323,15 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl() +case "${host}" in + *-*-linux*) + AC_CHECK_HEADERS([sys/prctl.h]) + ;; +esac + # # Checks for typedefs, structures, and compiler characteristics. # On Tue, 08/07/2025 at 13.05 +0200, Guido Trentalancia via Gnupg-devel wrote: > In the following v7 patch I have improved the commit log and source > code comments, with a better explaination of how to fix CVE-2020-0550 > (L1 Data Cache flush). > > common: Disable CPU speculative execution security > vulnerabilities (CVE-2018-3639 aka Spectre variant 4, > CVE-2017-5715 and optionally CVE-2020-0550) > > * configure.ac: add a new L1D Cache flushing option > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > and check for sys/prctl.h on Linux systems > > * common/init.c (early_system_init): Disable CPU > speculative execution security vulnerabilities > potentially causing data leaks: > > - Speculative Store Bypass (always disabled) > - Indirect Branch Speculation (always disabled) > - Flush L1D Cache on context switch out of the > task (use the --enable-l1d-cache-flushing > configure option and l1d_flush=on on the boot > command line to mitigate the vulnerability) > > For further information see the kernel documentation: > Documentation/userspace-api/spec_ctrl.rst > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > Signed-off-by: Guido Trentalancia > > diff -pru a/common/init.c b/common/init.c > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 > @@ -29,6 +29,10 @@ > > #include > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > +# include > +#endif > + > #ifdef HAVE_W32_SYSTEM > # if _WIN32_WINNT < 0x0600 > # define _WIN32_WINNT 0x0600 /* Required for > SetProcessDEPPolicy. */ > @@ -132,6 +136,32 @@ writestring_via_estream (int mode, const > void > early_system_init (void) > { > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > + > +/* Disable CPU speculative execution security vulnerabilities > + * causing data leaks: see the Linux kernel documentation > + * Documentation/userspace-api/spec_ctrl.rst > + * > + * - Speculative Store Bypass (CVE-2018-3639, always > + * disabled) > + * - Indirect Branch Speculation (CVE-2017-5715, always > + * disabled) > + * - Flush L1D Cache on context switch out of the task (it > + * requires the l1d_flush=on kernel boot parameter) > + */ > +#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 > + > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, > 0, 0); > +#endif > + > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > } > > > diff -pru a/configure.ac b/configure.ac > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > AC_MSG_RESULT($selinux_support) > > > +# Fix security vulnerability CVE-2020-0550 by enabling > +# Level 1 Data Cache flushing on context switch. > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > switch]) > +AC_ARG_ENABLE(l1d-cache-flushing, > + AS_HELP_STRING([--enable-l1d-cache-flushing], > + [enable L1D cache flushing]), > + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) > +AC_MSG_RESULT($l1d_cache_flushing) > + > + > AC_MSG_CHECKING([whether to allocate extra secure memory]) > AC_ARG_ENABLE(large-secmem, > AS_HELP_STRING([--enable-large-secmem], > @@ -1313,6 +1323,15 @@ fi > > > # > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > +# > +if test "$l1d_cache_flushing" = yes ; then > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > + [Define to enable Layer 1 Data Cache flushing]) > +fi > + > + > +# > # Checks for header files. > # > AC_MSG_NOTICE([checking for header files]) > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) > > > +# See whether libc supports the prctl() > +case "${host}" in > + *-*-linux*) > + AC_CHECK_HEADERS([sys/prctl.h]) > + ;; > +esac > + > # > # Checks for typedefs, structures, and compiler characteristics. > # > > On Mon, 07/07/2025 at 19.17 +0200, Guido Trentalancia via > Gnupg-devel wrote: > > On Mon, 07/07/2025 alle 18.36 +0200, Werner Koch wrote: > > > Hi! > > > > > > On Sun, 6 Jul 2025 21:50, Guido Trentalancia said: > > > > > > > common: Disable CPU speculation-related misfeatures > > > > > > I would prefer to keep the subject clear of an opinion. > > > > It's not an opinion, it's a fact. > > > > The wording is taken from the official Linux kernel documentation, > > however I agree it's probably too delicate, the correct wording is > > "security vulnerabilities". > > > > > > +#if defined(__linux__) > > > > +# include > > > > +#endif > > > > > > Good. You now provide configure tests. Please also add a > > > general > > > one > > > which checks for this header. > > > > A general check for sys/prctl.h is not needed, as such header file > > is > > only used on Linux-specific code and it can therefore break things > > on > > non-Linux systems. > > > > > > +#if defined(__linux__) > > > > > > And use that here ;-) > > > > > > > AC_CHECK_HEADERS([unistd.h langinfo.h termio.h locale.h \ > > > > pwd.h inttypes.h signal.h sys/select.h > > > > sys/time.h \ > > > > stdint.h signal.h termios.h \ > > > > - ucred.h sys/ucred.h sys/sysmacros.h > > > > sys/mkdev.h]) > > > > + ucred.h sys/ucred.h sys/sysmacros.h > > > > sys/mkdev.h > > > > \ > > > > + sys/prctl.h]) > > > > > > Hey, you already got that macro. Thus you can replace the above > > > with > > > > > > #if defined(HAVE_SYS_PRCTL_H) && defined(__linux__) > > > > I can replace that, in reversed order. Please see the v6 patch > > below, > > my last attempt at fixing this... > > > > > and we are good. The ifdef __linux__ here is so that we cater > > > for > > > OSes > > > which have such a header for different purposes. Using the > > > standard > > > configure test along with a ifdef in the code is a good > > > compromise > > > between readibility and regualar autoconf style. > > > > common: Disable CPU speculation-related security > > vulnerabilities (CVE-2018-3639 aka Spectre variant 4, > > CVE-2017-5715 and optionally CVE-2020-0550) > > > > * configure.ac: add a new L1D Cache flushing option > > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > > and check for sys/prctl.h on Linux systems > > > > * common/init.c (early_system_init): Disable CPU > > speculation-related misfeatures which are in fact > > vulnerabilities causing data leaks: > > > > - Speculative Store Bypass (always disabled) > > - Indirect Branch Speculation (always disabled) > > - Flush L1D Cache on context switch out of the > > task (use the --enable-l1d-cache-flushing > > configure option to mitigate the vulnerability) > > > > For further information see the kernel documentation: > > Documentation/userspace-api/spec_ctrl.rst > > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > > > Signed-off-by: Guido Trentalancia > > > > diff -pru a/common/init.c b/common/init.c > > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > > +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 > > @@ -29,6 +29,10 @@ > > > > #include > > > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > +# include > > +#endif > > + > > #ifdef HAVE_W32_SYSTEM > > # if _WIN32_WINNT < 0x0600 > > # define _WIN32_WINNT 0x0600 /* Required for > > SetProcessDEPPolicy. */ > > @@ -132,6 +136,29 @@ writestring_via_estream (int mode, const > > void > > early_system_init (void) > > { > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > + > > +/* Disable CPU speculation-related security vulnerabilities > > + * causing data leaks: see the Linux 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 > > + > > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > > PR_SPEC_ENABLE, > > 0, 0); > > +#endif > > + > > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > > } > > > > > > diff -pru a/configure.ac b/configure.ac > > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > > +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 > > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > > AC_MSG_RESULT($selinux_support) > > > > > > +# Fix security vulnerability CVE-2020-0550 by enabling > > +# Level 1 Data Cache flushing on context switch. > > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > > switch]) > > +AC_ARG_ENABLE(l1d-cache-flushing, > > + AS_HELP_STRING([--enable-l1d-cache-flushing], > > + [enable L1D cache flushing]), > > + l1d_cache_flushing=$enableval, > > l1d_cache_flushing=no) > > +AC_MSG_RESULT($l1d_cache_flushing) > > + > > + > > AC_MSG_CHECKING([whether to allocate extra secure memory]) > > AC_ARG_ENABLE(large-secmem, > > AS_HELP_STRING([--enable-large-secmem], > > @@ -1313,6 +1323,15 @@ fi > > > > > > # > > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > > +# > > +if test "$l1d_cache_flushing" = yes ; then > > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > > + [Define to enable Layer 1 Data Cache flushing]) > > +fi > > + > > + > > +# > > # Checks for header files. > > # > > AC_MSG_NOTICE([checking for header files]) > > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > > ucred.h sys/ucred.h sys/sysmacros.h > > sys/mkdev.h]) > > > > > > +# See whether libc supports the prctl() > > +case "${host}" in > > + *-*-linux*) > > + AC_CHECK_HEADERS([sys/prctl.h]) > > + ;; > > +esac > > + > > # > > # Checks for typedefs, structures, and compiler characteristics. > > # > > > > _______________________________________________ > > Gnupg-devel mailing list > > Gnupg-devel at gnupg.org > > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From guido at trentalancia.com Tue Jul 8 18:26:36 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Tue, 08 Jul 2025 18:26:36 +0200 Subject: [PATCH gnupg v9] Disable CPU speculation-related misfeatures In-Reply-To: <1751983558.11004.3.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> Message-ID: <1751991996.6941.1.camel@trentalancia.com> Error reporting and handling has been added to create a v9 patch that follows... common: Disable CPU speculative execution security vulnerabilities (CVE-2018-3639 aka Spectre variant 4, CVE-2017-5715 and optionally CVE-2020-0550) * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPU speculative execution security vulnerabilities potentially causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option and "nosmt l1d_flush=on" on the boot command line to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-08 18:14:12.246994230 +0200 @@ -29,6 +29,14 @@ #include +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) +# include +#endif + +#if defined(ENABLE_L1D_CACHE_FLUSH) +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -128,10 +136,52 @@ writestring_via_estream (int mode, const } +void sigbus_handler(int signo) +{ + if (signo == SIGBUS) + { + log_info ("Warning: Level 1 Data Cache flushing requires the \"nosmt\" boot parameter.\n"); + } +} + + /* This function should be the first called after main. */ void early_system_init (void) { +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) + +/* Disable CPU speculative execution security vulnerabilities + * causing data leaks: see the Linux kernel documentation + * Documentation/userspace-api/spec_ctrl.rst + * + * - Speculative Store Bypass (CVE-2018-3639, always + * disabled) + * - Indirect Branch Speculation (CVE-2017-5715, always + * disabled) + * - Flush L1D Cache on context switch out of the task (it + * requires the "nosmt l1d_flush=on" kernel boot parameter) + */ +#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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + if (signal(SIGBUS, sigbus_handler) == SIG_ERR) + { + log_info ("Warning: cannot catch the SIGBUS signal.\n"); + } + if (prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0) < 0) + { + log_info ("Warning: Level 1 Data Cache flushing requires the \"l1d_flush=on\" boot parameter.\n"); + } +#endif + +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-08 17:31:51.757997407 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,6 +1323,15 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl() +case "${host}" in + *-*-linux*) + AC_CHECK_HEADERS([sys/prctl.h]) + ;; +esac + # # Checks for typedefs, structures, and compiler characteristics. # On Tue, 08/07/2025 at 16.05 +0200, Guido Trentalancia via Gnupg-devel wrote: > I have now further improved the documentation of how to use L1 Data > Cache flushing, this should answer the question raised by Jussi > Kivilinna regarding the SIGBUS error. A new v8 patch has been > created. > > common: Disable CPU speculative execution security > vulnerabilities (CVE-2018-3639 aka Spectre variant 4, > CVE-2017-5715 and optionally CVE-2020-0550) > > * configure.ac: add a new L1D Cache flushing option > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > and check for sys/prctl.h on Linux systems > > * common/init.c (early_system_init): Disable CPU > speculative execution security vulnerabilities > potentially causing data leaks: > > - Speculative Store Bypass (always disabled) > - Indirect Branch Speculation (always disabled) > - Flush L1D Cache on context switch out of the > task (use the --enable-l1d-cache-flushing > configure option and "nosmt l1d_flush=on" on the > boot command line to mitigate the vulnerability) > > For further information see the kernel documentation: > Documentation/userspace-api/spec_ctrl.rst > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > Signed-off-by: Guido Trentalancia > > diff -pru a/common/init.c b/common/init.c > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 > @@ -29,6 +29,10 @@ > > #include > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > +# include > +#endif > + > #ifdef HAVE_W32_SYSTEM > # if _WIN32_WINNT < 0x0600 > # define _WIN32_WINNT 0x0600 /* Required for > SetProcessDEPPolicy. */ > @@ -132,6 +136,32 @@ writestring_via_estream (int mode, const > void > early_system_init (void) > { > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > + > +/* Disable CPU speculative execution security vulnerabilities > + * causing data leaks: see the Linux kernel documentation > + * Documentation/userspace-api/spec_ctrl.rst > + * > + * - Speculative Store Bypass (CVE-2018-3639, always > + * disabled) > + * - Indirect Branch Speculation (CVE-2017-5715, always > + * disabled) > + * - Flush L1D Cache on context switch out of the task (it > + * requires the "nosmt l1d_flush=on" kernel boot parameter) > + */ > +#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 > + > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, > 0, 0); > +#endif > + > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > } > > > diff -pru a/configure.ac b/configure.ac > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > AC_MSG_RESULT($selinux_support) > > > +# Fix security vulnerability CVE-2020-0550 by enabling > +# Level 1 Data Cache flushing on context switch. > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > switch]) > +AC_ARG_ENABLE(l1d-cache-flushing, > + AS_HELP_STRING([--enable-l1d-cache-flushing], > + [enable L1D cache flushing]), > + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) > +AC_MSG_RESULT($l1d_cache_flushing) > + > + > AC_MSG_CHECKING([whether to allocate extra secure memory]) > AC_ARG_ENABLE(large-secmem, > AS_HELP_STRING([--enable-large-secmem], > @@ -1313,6 +1323,15 @@ fi > > > # > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > +# > +if test "$l1d_cache_flushing" = yes ; then > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > + [Define to enable Layer 1 Data Cache flushing]) > +fi > + > + > +# > # Checks for header files. > # > AC_MSG_NOTICE([checking for header files]) > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) > > > +# See whether libc supports the prctl() > +case "${host}" in > + *-*-linux*) > + AC_CHECK_HEADERS([sys/prctl.h]) > + ;; > +esac > + > # > # Checks for typedefs, structures, and compiler characteristics. > # > > On Tue, 08/07/2025 at 13.05 +0200, Guido Trentalancia via > Gnupg-devel wrote: > > In the following v7 patch I have improved the commit log and source > > code comments, with a better explaination of how to fix CVE-2020- > > 0550 > > (L1 Data Cache flush). > > > > common: Disable CPU speculative execution security > > vulnerabilities (CVE-2018-3639 aka Spectre variant 4, > > CVE-2017-5715 and optionally CVE-2020-0550) > > > > * configure.ac: add a new L1D Cache flushing option > > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > > and check for sys/prctl.h on Linux systems > > > > * common/init.c (early_system_init): Disable CPU > > speculative execution security vulnerabilities > > potentially causing data leaks: > > > > - Speculative Store Bypass (always disabled) > > - Indirect Branch Speculation (always disabled) > > - Flush L1D Cache on context switch out of the > > task (use the --enable-l1d-cache-flushing > > configure option and l1d_flush=on on the boot > > command line to mitigate the vulnerability) > > > > For further information see the kernel documentation: > > Documentation/userspace-api/spec_ctrl.rst > > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > > > Signed-off-by: Guido Trentalancia > > > > diff -pru a/common/init.c b/common/init.c > > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > > +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 > > @@ -29,6 +29,10 @@ > > > > #include > > > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > +# include > > +#endif > > + > > #ifdef HAVE_W32_SYSTEM > > # if _WIN32_WINNT < 0x0600 > > # define _WIN32_WINNT 0x0600 /* Required for > > SetProcessDEPPolicy. */ > > @@ -132,6 +136,32 @@ writestring_via_estream (int mode, const > > void > > early_system_init (void) > > { > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > + > > +/* Disable CPU speculative execution security vulnerabilities > > + * causing data leaks: see the Linux kernel documentation > > + * Documentation/userspace-api/spec_ctrl.rst > > + * > > + * - Speculative Store Bypass (CVE-2018-3639, always > > + * disabled) > > + * - Indirect Branch Speculation (CVE-2017-5715, always > > + * disabled) > > + * - Flush L1D Cache on context switch out of the task (it > > + * requires the l1d_flush=on kernel boot parameter) > > + */ > > +#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 > > + > > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > > PR_SPEC_ENABLE, > > 0, 0); > > +#endif > > + > > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > > } > > > > > > diff -pru a/configure.ac b/configure.ac > > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > > +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 > > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > > AC_MSG_RESULT($selinux_support) > > > > > > +# Fix security vulnerability CVE-2020-0550 by enabling > > +# Level 1 Data Cache flushing on context switch. > > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > > switch]) > > +AC_ARG_ENABLE(l1d-cache-flushing, > > + AS_HELP_STRING([--enable-l1d-cache-flushing], > > + [enable L1D cache flushing]), > > + l1d_cache_flushing=$enableval, > > l1d_cache_flushing=no) > > +AC_MSG_RESULT($l1d_cache_flushing) > > + > > + > > AC_MSG_CHECKING([whether to allocate extra secure memory]) > > AC_ARG_ENABLE(large-secmem, > > AS_HELP_STRING([--enable-large-secmem], > > @@ -1313,6 +1323,15 @@ fi > > > > > > # > > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > > +# > > +if test "$l1d_cache_flushing" = yes ; then > > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > > + [Define to enable Layer 1 Data Cache flushing]) > > +fi > > + > > + > > +# > > # Checks for header files. > > # > > AC_MSG_NOTICE([checking for header files]) > > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > > ucred.h sys/ucred.h sys/sysmacros.h > > sys/mkdev.h]) > > > > > > +# See whether libc supports the prctl() > > +case "${host}" in > > + *-*-linux*) > > + AC_CHECK_HEADERS([sys/prctl.h]) > > + ;; > > +esac > > + > > # > > # Checks for typedefs, structures, and compiler characteristics. > > # > > > > On Mon, 07/07/2025 at 19.17 +0200, Guido Trentalancia via > > Gnupg-devel wrote: > > > On Mon, 07/07/2025 alle 18.36 +0200, Werner Koch wrote: > > > > Hi! > > > > > > > > On Sun, 6 Jul 2025 21:50, Guido Trentalancia said: > > > > > > > > > common: Disable CPU speculation-related misfeatures > > > > > > > > I would prefer to keep the subject clear of an opinion. > > > > > > It's not an opinion, it's a fact. > > > > > > The wording is taken from the official Linux kernel > > > documentation, > > > however I agree it's probably too delicate, the correct wording > > > is > > > "security vulnerabilities". > > > > > > > > +#if defined(__linux__) > > > > > +# include > > > > > +#endif > > > > > > > > Good. You now provide configure tests. Please also add a > > > > general > > > > one > > > > which checks for this header. > > > > > > A general check for sys/prctl.h is not needed, as such header > > > file > > > is > > > only used on Linux-specific code and it can therefore break > > > things > > > on > > > non-Linux systems. > > > > > > > > +#if defined(__linux__) > > > > > > > > And use that here ;-) > > > > > > > > > AC_CHECK_HEADERS([unistd.h langinfo.h termio.h locale.h \ > > > > > pwd.h inttypes.h signal.h sys/select.h > > > > > sys/time.h \ > > > > > stdint.h signal.h termios.h \ > > > > > - ucred.h sys/ucred.h sys/sysmacros.h > > > > > sys/mkdev.h]) > > > > > + ucred.h sys/ucred.h sys/sysmacros.h > > > > > sys/mkdev.h > > > > > \ > > > > > + sys/prctl.h]) > > > > > > > > Hey, you already got that macro. Thus you can replace the > > > > above > > > > with > > > > > > > > #if defined(HAVE_SYS_PRCTL_H) && defined(__linux__) > > > > > > I can replace that, in reversed order. Please see the v6 patch > > > below, > > > my last attempt at fixing this... > > > > > > > and we are good. The ifdef __linux__ here is so that we cater > > > > for > > > > OSes > > > > which have such a header for different purposes. Using the > > > > standard > > > > configure test along with a ifdef in the code is a good > > > > compromise > > > > between readibility and regualar autoconf style. > > > > > > common: Disable CPU speculation-related security > > > vulnerabilities (CVE-2018-3639 aka Spectre variant 4, > > > CVE-2017-5715 and optionally CVE-2020-0550) > > > > > > * configure.ac: add a new L1D Cache flushing option > > > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > > > and check for sys/prctl.h on Linux systems > > > > > > * common/init.c (early_system_init): Disable CPU > > > speculation-related misfeatures which are in fact > > > vulnerabilities causing data leaks: > > > > > > - Speculative Store Bypass (always disabled) > > > - Indirect Branch Speculation (always disabled) > > > - Flush L1D Cache on context switch out of the > > > task (use the --enable-l1d-cache-flushing > > > configure option to mitigate the vulnerability) > > > > > > For further information see the kernel documentation: > > > Documentation/userspace-api/spec_ctrl.rst > > > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > > > > > Signed-off-by: Guido Trentalancia > > > > > > diff -pru a/common/init.c b/common/init.c > > > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > > > +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 > > > @@ -29,6 +29,10 @@ > > > > > > #include > > > > > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > > +# include > > > +#endif > > > + > > > #ifdef HAVE_W32_SYSTEM > > > # if _WIN32_WINNT < 0x0600 > > > # define _WIN32_WINNT 0x0600 /* Required for > > > SetProcessDEPPolicy. */ > > > @@ -132,6 +136,29 @@ writestring_via_estream (int mode, const > > > void > > > early_system_init (void) > > > { > > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > > + > > > +/* Disable CPU speculation-related security vulnerabilities > > > + * causing data leaks: see the Linux 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 > > > + > > > +#if defined(ENABLE_L1D_CACHE_FLUSH) && > > > defined(PR_SPEC_L1D_FLUSH) > > > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > > > PR_SPEC_ENABLE, > > > 0, 0); > > > +#endif > > > + > > > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > > > } > > > > > > > > > diff -pru a/configure.ac b/configure.ac > > > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > > > +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 > > > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > > > AC_MSG_RESULT($selinux_support) > > > > > > > > > +# Fix security vulnerability CVE-2020-0550 by enabling > > > +# Level 1 Data Cache flushing on context switch. > > > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on > > > context > > > switch]) > > > +AC_ARG_ENABLE(l1d-cache-flushing, > > > + AS_HELP_STRING([--enable-l1d-cache-flushing], > > > + [enable L1D cache flushing]), > > > + l1d_cache_flushing=$enableval, > > > l1d_cache_flushing=no) > > > +AC_MSG_RESULT($l1d_cache_flushing) > > > + > > > + > > > AC_MSG_CHECKING([whether to allocate extra secure memory]) > > > AC_ARG_ENABLE(large-secmem, > > > AS_HELP_STRING([--enable-large-secmem], > > > @@ -1313,6 +1323,15 @@ fi > > > > > > > > > # > > > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > > > +# > > > +if test "$l1d_cache_flushing" = yes ; then > > > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > > > + [Define to enable Layer 1 Data Cache flushing]) > > > +fi > > > + > > > + > > > +# > > > # Checks for header files. > > > # > > > AC_MSG_NOTICE([checking for header files]) > > > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > > > ucred.h sys/ucred.h sys/sysmacros.h > > > sys/mkdev.h]) > > > > > > > > > +# See whether libc supports the prctl() > > > +case "${host}" in > > > + *-*-linux*) > > > + AC_CHECK_HEADERS([sys/prctl.h]) > > > + ;; > > > +esac > > > + > > > # > > > # Checks for typedefs, structures, and compiler characteristics. > > > # > > > > > > _______________________________________________ > > > Gnupg-devel mailing list > > > Gnupg-devel at gnupg.org > > > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > > > _______________________________________________ > > Gnupg-devel mailing list > > Gnupg-devel at gnupg.org > > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From guido at trentalancia.com Tue Jul 8 21:38:29 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Tue, 08 Jul 2025 21:38:29 +0200 Subject: [PATCH gnupg v10] Disable CPU speculation-related misfeatures In-Reply-To: <1751991996.6941.1.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> Message-ID: <1752003509.25437.3.camel@trentalancia.com> The following new v10 patch has been created to fix a missing #ifdef and header file check for the case of L1D cache flushing. common: Disable CPU speculative execution security vulnerabilities (CVE-2018-3639 aka Spectre variant 4, CVE-2017-5715 and optionally CVE-2020-0550) * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPU speculative execution security vulnerabilities potentially causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option and "nosmt l1d_flush=on" on the boot command line to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-08 21:29:23.071406450 +0200 @@ -29,6 +29,14 @@ #include +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) +# include +#endif + +#if defined(ENABLE_L1D_CACHE_FLUSH) +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -128,10 +136,54 @@ writestring_via_estream (int mode, const } +#ifdef ENABLE_L1D_CACHE_FLUSH +void sigbus_handler(int signo) +{ + if (signo == SIGBUS) + { + log_info ("Warning: Level 1 Data Cache flushing requires the \"nosmt\" boot parameter.\n"); + } +} +#endif + + /* This function should be the first called after main. */ void early_system_init (void) { +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) + +/* Disable CPU speculative execution security vulnerabilities + * causing data leaks: see the Linux kernel documentation + * Documentation/userspace-api/spec_ctrl.rst + * + * - Speculative Store Bypass (CVE-2018-3639, always + * disabled) + * - Indirect Branch Speculation (CVE-2017-5715, always + * disabled) + * - Flush L1D Cache on context switch out of the task (it + * requires the "nosmt l1d_flush=on" kernel boot parameter) + */ +#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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + if (signal(SIGBUS, sigbus_handler) == SIG_ERR) + { + log_info ("Warning: cannot catch the SIGBUS signal.\n"); + } + if (prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0) < 0) + { + log_info ("Warning: Level 1 Data Cache flushing requires the \"l1d_flush=on\" boot parameter.\n"); + } +#endif + +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,6 +1323,16 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) + AC_CHECK_HEADERS([signal.h]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) @@ -1322,6 +1342,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl() +case "${host}" in + *-*-linux*) + AC_CHECK_HEADERS([sys/prctl.h]) + ;; +esac + # # Checks for typedefs, structures, and compiler characteristics. # On Tue, 08/07/2025 at 18.26 +0200, Guido Trentalancia via Gnupg-devel wrote: > Error reporting and handling has been added to create a v9 patch that > follows... > > common: Disable CPU speculative execution security > vulnerabilities (CVE-2018-3639 aka Spectre variant 4, > CVE-2017-5715 and optionally CVE-2020-0550) > > * configure.ac: add a new L1D Cache flushing option > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > and check for sys/prctl.h on Linux systems > > * common/init.c (early_system_init): Disable CPU > speculative execution security vulnerabilities > potentially causing data leaks: > > - Speculative Store Bypass (always disabled) > - Indirect Branch Speculation (always disabled) > - Flush L1D Cache on context switch out of the > task (use the --enable-l1d-cache-flushing > configure option and "nosmt l1d_flush=on" on the > boot command line to mitigate the vulnerability) > > For further information see the kernel documentation: > Documentation/userspace-api/spec_ctrl.rst > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > Signed-off-by: Guido Trentalancia > > diff -pru a/common/init.c b/common/init.c > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > +++ b/common/init.c 2025-07-08 18:14:12.246994230 +0200 > @@ -29,6 +29,14 @@ > > #include > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > +# include > +#endif > + > +#if defined(ENABLE_L1D_CACHE_FLUSH) > +# include > +#endif > + > #ifdef HAVE_W32_SYSTEM > # if _WIN32_WINNT < 0x0600 > # define _WIN32_WINNT 0x0600 /* Required for > SetProcessDEPPolicy. */ > @@ -128,10 +136,52 @@ writestring_via_estream (int mode, const > } > > > +void sigbus_handler(int signo) > +{ > + if (signo == SIGBUS) > + { > + log_info ("Warning: Level 1 Data Cache flushing requires the > \"nosmt\" boot parameter.\n"); > + } > +} > + > + > /* This function should be the first called after main. */ > void > early_system_init (void) > { > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > + > +/* Disable CPU speculative execution security vulnerabilities > + * causing data leaks: see the Linux kernel documentation > + * Documentation/userspace-api/spec_ctrl.rst > + * > + * - Speculative Store Bypass (CVE-2018-3639, always > + * disabled) > + * - Indirect Branch Speculation (CVE-2017-5715, always > + * disabled) > + * - Flush L1D Cache on context switch out of the task (it > + * requires the "nosmt l1d_flush=on" kernel boot parameter) > + */ > +#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 > + > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > + if (signal(SIGBUS, sigbus_handler) == SIG_ERR) > + { > + log_info ("Warning: cannot catch the SIGBUS signal.\n"); > + } > + if (prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > PR_SPEC_ENABLE, 0, 0) < 0) > + { > + log_info ("Warning: Level 1 Data Cache flushing requires the > \"l1d_flush=on\" boot parameter.\n"); > + } > +#endif > + > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > } > > > diff -pru a/configure.ac b/configure.ac > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > +++ b/configure.ac 2025-07-08 17:31:51.757997407 +0200 > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > AC_MSG_RESULT($selinux_support) > > > +# Fix security vulnerability CVE-2020-0550 by enabling > +# Level 1 Data Cache flushing on context switch. > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > switch]) > +AC_ARG_ENABLE(l1d-cache-flushing, > + AS_HELP_STRING([--enable-l1d-cache-flushing], > + [enable L1D cache flushing]), > + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) > +AC_MSG_RESULT($l1d_cache_flushing) > + > + > AC_MSG_CHECKING([whether to allocate extra secure memory]) > AC_ARG_ENABLE(large-secmem, > AS_HELP_STRING([--enable-large-secmem], > @@ -1313,6 +1323,15 @@ fi > > > # > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > +# > +if test "$l1d_cache_flushing" = yes ; then > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > + [Define to enable Layer 1 Data Cache flushing]) > +fi > + > + > +# > # Checks for header files. > # > AC_MSG_NOTICE([checking for header files]) > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) > > > +# See whether libc supports the prctl() > +case "${host}" in > + *-*-linux*) > + AC_CHECK_HEADERS([sys/prctl.h]) > + ;; > +esac > + > # > # Checks for typedefs, structures, and compiler characteristics. > # > > On Tue, 08/07/2025 at 16.05 +0200, Guido Trentalancia via > Gnupg-devel wrote: > > I have now further improved the documentation of how to use L1 Data > > Cache flushing, this should answer the question raised by Jussi > > Kivilinna regarding the SIGBUS error. A new v8 patch has been > > created. > > > > common: Disable CPU speculative execution security > > vulnerabilities (CVE-2018-3639 aka Spectre variant 4, > > CVE-2017-5715 and optionally CVE-2020-0550) > > > > * configure.ac: add a new L1D Cache flushing option > > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > > and check for sys/prctl.h on Linux systems > > > > * common/init.c (early_system_init): Disable CPU > > speculative execution security vulnerabilities > > potentially causing data leaks: > > > > - Speculative Store Bypass (always disabled) > > - Indirect Branch Speculation (always disabled) > > - Flush L1D Cache on context switch out of the > > task (use the --enable-l1d-cache-flushing > > configure option and "nosmt l1d_flush=on" on the > > boot command line to mitigate the vulnerability) > > > > For further information see the kernel documentation: > > Documentation/userspace-api/spec_ctrl.rst > > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > > > Signed-off-by: Guido Trentalancia > > > > diff -pru a/common/init.c b/common/init.c > > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > > +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 > > @@ -29,6 +29,10 @@ > > > > #include > > > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > +# include > > +#endif > > + > > #ifdef HAVE_W32_SYSTEM > > # if _WIN32_WINNT < 0x0600 > > # define _WIN32_WINNT 0x0600 /* Required for > > SetProcessDEPPolicy. */ > > @@ -132,6 +136,32 @@ writestring_via_estream (int mode, const > > void > > early_system_init (void) > > { > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > + > > +/* Disable CPU speculative execution security vulnerabilities > > + * causing data leaks: see the Linux kernel documentation > > + * Documentation/userspace-api/spec_ctrl.rst > > + * > > + * - Speculative Store Bypass (CVE-2018-3639, always > > + * disabled) > > + * - Indirect Branch Speculation (CVE-2017-5715, always > > + * disabled) > > + * - Flush L1D Cache on context switch out of the task (it > > + * requires the "nosmt l1d_flush=on" kernel boot parameter) > > + */ > > +#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 > > + > > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > > PR_SPEC_ENABLE, > > 0, 0); > > +#endif > > + > > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > > } > > > > > > diff -pru a/configure.ac b/configure.ac > > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > > +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 > > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > > AC_MSG_RESULT($selinux_support) > > > > > > +# Fix security vulnerability CVE-2020-0550 by enabling > > +# Level 1 Data Cache flushing on context switch. > > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > > switch]) > > +AC_ARG_ENABLE(l1d-cache-flushing, > > + AS_HELP_STRING([--enable-l1d-cache-flushing], > > + [enable L1D cache flushing]), > > + l1d_cache_flushing=$enableval, > > l1d_cache_flushing=no) > > +AC_MSG_RESULT($l1d_cache_flushing) > > + > > + > > AC_MSG_CHECKING([whether to allocate extra secure memory]) > > AC_ARG_ENABLE(large-secmem, > > AS_HELP_STRING([--enable-large-secmem], > > @@ -1313,6 +1323,15 @@ fi > > > > > > # > > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > > +# > > +if test "$l1d_cache_flushing" = yes ; then > > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > > + [Define to enable Layer 1 Data Cache flushing]) > > +fi > > + > > + > > +# > > # Checks for header files. > > # > > AC_MSG_NOTICE([checking for header files]) > > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > > ucred.h sys/ucred.h sys/sysmacros.h > > sys/mkdev.h]) > > > > > > +# See whether libc supports the prctl() > > +case "${host}" in > > + *-*-linux*) > > + AC_CHECK_HEADERS([sys/prctl.h]) > > + ;; > > +esac > > + > > # > > # Checks for typedefs, structures, and compiler characteristics. > > # > > > > On Tue, 08/07/2025 at 13.05 +0200, Guido Trentalancia via > > Gnupg-devel wrote: > > > In the following v7 patch I have improved the commit log and > > > source > > > code comments, with a better explaination of how to fix CVE-2020- > > > 0550 > > > (L1 Data Cache flush). > > > > > > common: Disable CPU speculative execution security > > > vulnerabilities (CVE-2018-3639 aka Spectre variant 4, > > > CVE-2017-5715 and optionally CVE-2020-0550) > > > > > > * configure.ac: add a new L1D Cache flushing option > > > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > > > and check for sys/prctl.h on Linux systems > > > > > > * common/init.c (early_system_init): Disable CPU > > > speculative execution security vulnerabilities > > > potentially causing data leaks: > > > > > > - Speculative Store Bypass (always disabled) > > > - Indirect Branch Speculation (always disabled) > > > - Flush L1D Cache on context switch out of the > > > task (use the --enable-l1d-cache-flushing > > > configure option and l1d_flush=on on the boot > > > command line to mitigate the vulnerability) > > > > > > For further information see the kernel documentation: > > > Documentation/userspace-api/spec_ctrl.rst > > > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > > > > > Signed-off-by: Guido Trentalancia > > > > > > diff -pru a/common/init.c b/common/init.c > > > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > > > +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 > > > @@ -29,6 +29,10 @@ > > > > > > #include > > > > > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > > +# include > > > +#endif > > > + > > > #ifdef HAVE_W32_SYSTEM > > > # if _WIN32_WINNT < 0x0600 > > > # define _WIN32_WINNT 0x0600 /* Required for > > > SetProcessDEPPolicy. */ > > > @@ -132,6 +136,32 @@ writestring_via_estream (int mode, const > > > void > > > early_system_init (void) > > > { > > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > > + > > > +/* Disable CPU speculative execution security vulnerabilities > > > + * causing data leaks: see the Linux kernel documentation > > > + * Documentation/userspace-api/spec_ctrl.rst > > > + * > > > + * - Speculative Store Bypass (CVE-2018-3639, always > > > + * disabled) > > > + * - Indirect Branch Speculation (CVE-2017-5715, always > > > + * disabled) > > > + * - Flush L1D Cache on context switch out of the task (it > > > + * requires the l1d_flush=on kernel boot parameter) > > > + */ > > > +#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 > > > + > > > +#if defined(ENABLE_L1D_CACHE_FLUSH) && > > > defined(PR_SPEC_L1D_FLUSH) > > > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > > > PR_SPEC_ENABLE, > > > 0, 0); > > > +#endif > > > + > > > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > > > } > > > > > > > > > diff -pru a/configure.ac b/configure.ac > > > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > > > +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 > > > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > > > AC_MSG_RESULT($selinux_support) > > > > > > > > > +# Fix security vulnerability CVE-2020-0550 by enabling > > > +# Level 1 Data Cache flushing on context switch. > > > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on > > > context > > > switch]) > > > +AC_ARG_ENABLE(l1d-cache-flushing, > > > + AS_HELP_STRING([--enable-l1d-cache-flushing], > > > + [enable L1D cache flushing]), > > > + l1d_cache_flushing=$enableval, > > > l1d_cache_flushing=no) > > > +AC_MSG_RESULT($l1d_cache_flushing) > > > + > > > + > > > AC_MSG_CHECKING([whether to allocate extra secure memory]) > > > AC_ARG_ENABLE(large-secmem, > > > AS_HELP_STRING([--enable-large-secmem], > > > @@ -1313,6 +1323,15 @@ fi > > > > > > > > > # > > > +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) > > > +# > > > +if test "$l1d_cache_flushing" = yes ; then > > > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > > > + [Define to enable Layer 1 Data Cache flushing]) > > > +fi > > > + > > > + > > > +# > > > # Checks for header files. > > > # > > > AC_MSG_NOTICE([checking for header files]) > > > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > > > ucred.h sys/ucred.h sys/sysmacros.h > > > sys/mkdev.h]) > > > > > > > > > +# See whether libc supports the prctl() > > > +case "${host}" in > > > + *-*-linux*) > > > + AC_CHECK_HEADERS([sys/prctl.h]) > > > + ;; > > > +esac > > > + > > > # > > > # Checks for typedefs, structures, and compiler characteristics. > > > # > > > > > > On Mon, 07/07/2025 at 19.17 +0200, Guido Trentalancia via > > > Gnupg-devel wrote: > > > > On Mon, 07/07/2025 alle 18.36 +0200, Werner Koch wrote: > > > > > Hi! > > > > > > > > > > On Sun, 6 Jul 2025 21:50, Guido Trentalancia said: > > > > > > > > > > > common: Disable CPU speculation-related misfeatures > > > > > > > > > > I would prefer to keep the subject clear of an opinion. > > > > > > > > It's not an opinion, it's a fact. > > > > > > > > The wording is taken from the official Linux kernel > > > > documentation, > > > > however I agree it's probably too delicate, the correct wording > > > > is > > > > "security vulnerabilities". > > > > > > > > > > +#if defined(__linux__) > > > > > > +# include > > > > > > +#endif > > > > > > > > > > Good. You now provide configure tests. Please also add a > > > > > general > > > > > one > > > > > which checks for this header. > > > > > > > > A general check for sys/prctl.h is not needed, as such header > > > > file > > > > is > > > > only used on Linux-specific code and it can therefore break > > > > things > > > > on > > > > non-Linux systems. > > > > > > > > > > +#if defined(__linux__) > > > > > > > > > > And use that here ;-) > > > > > > > > > > > AC_CHECK_HEADERS([unistd.h langinfo.h termio.h locale.h \ > > > > > > pwd.h inttypes.h signal.h sys/select.h > > > > > > sys/time.h \ > > > > > > stdint.h signal.h termios.h \ > > > > > > - ucred.h sys/ucred.h sys/sysmacros.h > > > > > > sys/mkdev.h]) > > > > > > + ucred.h sys/ucred.h sys/sysmacros.h > > > > > > sys/mkdev.h > > > > > > \ > > > > > > + sys/prctl.h]) > > > > > > > > > > Hey, you already got that macro. Thus you can replace the > > > > > above > > > > > with > > > > > > > > > > #if defined(HAVE_SYS_PRCTL_H) && defined(__linux__) > > > > > > > > I can replace that, in reversed order. Please see the v6 patch > > > > below, > > > > my last attempt at fixing this... > > > > > > > > > and we are good. The ifdef __linux__ here is so that we > > > > > cater > > > > > for > > > > > OSes > > > > > which have such a header for different purposes. Using the > > > > > standard > > > > > configure test along with a ifdef in the code is a good > > > > > compromise > > > > > between readibility and regualar autoconf style. > > > > > > > > common: Disable CPU speculation-related security > > > > vulnerabilities (CVE-2018-3639 aka Spectre variant 4, > > > > CVE-2017-5715 and optionally CVE-2020-0550) > > > > > > > > * configure.ac: add a new L1D Cache flushing option > > > > (--enable-l1d-cache-flushing) to fix CVE-2020-0550 > > > > and check for sys/prctl.h on Linux systems > > > > > > > > * common/init.c (early_system_init): Disable CPU > > > > speculation-related misfeatures which are in fact > > > > vulnerabilities causing data leaks: > > > > > > > > - Speculative Store Bypass (always disabled) > > > > - Indirect Branch Speculation (always disabled) > > > > - Flush L1D Cache on context switch out of the > > > > task (use the --enable-l1d-cache-flushing > > > > configure option to mitigate the vulnerability) > > > > > > > > For further information see the kernel documentation: > > > > Documentation/userspace-api/spec_ctrl.rst > > > > Documentation/admin-guide/hw-vuln/l1d_flush.rst > > > > > > > > Signed-off-by: Guido Trentalancia > > > > > > > > diff -pru a/common/init.c b/common/init.c > > > > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > > > > +++ b/common/init.c 2025-07-07 19:02:08.478853360 +0200 > > > > @@ -29,6 +29,10 @@ > > > > > > > > #include > > > > > > > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > > > +# include > > > > +#endif > > > > + > > > > #ifdef HAVE_W32_SYSTEM > > > > # if _WIN32_WINNT < 0x0600 > > > > # define _WIN32_WINNT 0x0600 /* Required for > > > > SetProcessDEPPolicy. */ > > > > @@ -132,6 +136,29 @@ writestring_via_estream (int mode, const > > > > void > > > > early_system_init (void) > > > > { > > > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > > > + > > > > +/* Disable CPU speculation-related security vulnerabilities > > > > + * causing data leaks: see the Linux 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 > > > > + > > > > +#if defined(ENABLE_L1D_CACHE_FLUSH) && > > > > defined(PR_SPEC_L1D_FLUSH) > > > > + prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > > > > PR_SPEC_ENABLE, > > > > 0, 0); > > > > +#endif > > > > + > > > > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > > > > } > > > > > > > > > > > > diff -pru a/configure.ac b/configure.ac > > > > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > > > > +++ b/configure.ac 2025-07-06 21:56:51.219048292 +0200 > > > > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > > > > AC_MSG_RESULT($selinux_support) > > > > > > > > > > > > +# Fix security vulnerability CVE-2020-0550 by enabling > > > > +# Level 1 Data Cache flushing on context switch. > > > > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on > > > > context > > > > switch]) > > > > +AC_ARG_ENABLE(l1d-cache-flushing, > > > > + AS_HELP_STRING([--enable-l1d-cache-flushing], > > > > + [enable L1D cache flushing]), > > > > + l1d_cache_flushing=$enableval, > > > > l1d_cache_flushing=no) > > > > +AC_MSG_RESULT($l1d_cache_flushing) > > > > + > > > > + > > > > AC_MSG_CHECKING([whether to allocate extra secure memory]) > > > > AC_ARG_ENABLE(large-secmem, > > > > AS_HELP_STRING([--enable-large-secmem], > > > > @@ -1313,6 +1323,15 @@ fi > > > > > > > > > > > > # > > > > +# Level 1 Data Cache flushing on context switch (CVE-2020- > > > > 0550) > > > > +# > > > > +if test "$l1d_cache_flushing" = yes ; then > > > > + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, > > > > + [Define to enable Layer 1 Data Cache flushing]) > > > > +fi > > > > + > > > > + > > > > +# > > > > # Checks for header files. > > > > # > > > > AC_MSG_NOTICE([checking for header files]) > > > > @@ -1322,6 +1341,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te > > > > ucred.h sys/ucred.h sys/sysmacros.h > > > > sys/mkdev.h]) > > > > > > > > > > > > +# See whether libc supports the prctl() > > > > +case "${host}" in > > > > + *-*-linux*) > > > > + AC_CHECK_HEADERS([sys/prctl.h]) > > > > + ;; > > > > +esac > > > > + > > > > # > > > > # Checks for typedefs, structures, and compiler > > > > characteristics. > > > > # > > > > > > > > _______________________________________________ > > > > Gnupg-devel mailing list > > > > Gnupg-devel at gnupg.org > > > > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > > > > > _______________________________________________ > > > Gnupg-devel mailing list > > > Gnupg-devel at gnupg.org > > > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > > > _______________________________________________ > > Gnupg-devel mailing list > > Gnupg-devel at gnupg.org > > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From jcb62281 at gmail.com Wed Jul 9 03:02:29 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Tue, 8 Jul 2025 20:02:29 -0500 Subject: [PATCH gnupg v10] Disable CPU speculation-related misfeatures In-Reply-To: <1752003509.25437.3.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> Message-ID: On 7/8/25 14:38, Guido Trentalancia via Gnupg-devel wrote: > The following new v10 patch has been created to fix a missing #ifdef > and header file check for the case of L1D cache flushing. > [...] Two major issues, further explained inline below: ??? - You are installing the signal handler incorrectly; this will interfere with other possible uses of SIGBUS. ??? - Your message from configure when testing the option to request L1 cache flushes is misleading. Further, none of this actually *fixes* anything; these are *workarounds* for widespread hardware bugs. Also, have you actually tested this on a machine where the request for L1 cache flushes raises SIGBUS? > > diff -pru a/common/init.c b/common/init.c > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > +++ b/common/init.c 2025-07-08 21:29:23.071406450 +0200 > [...] > /* This function should be the first called after main. */ > void > early_system_init (void) > { > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > + > +/* Disable CPU speculative execution security vulnerabilities > + * causing data leaks: see the Linux kernel documentation > + * Documentation/userspace-api/spec_ctrl.rst > + * > + * - Speculative Store Bypass (CVE-2018-3639, always > + * disabled) > + * - Indirect Branch Speculation (CVE-2017-5715, always > + * disabled) > + * - Flush L1D Cache on context switch out of the task (it > + * requires the "nosmt l1d_flush=on" kernel boot parameter) > + */ > +#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 > + > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > + if (signal(SIGBUS, sigbus_handler) == SIG_ERR) > + { > + log_info ("Warning: cannot catch the SIGBUS signal.\n"); > + } You cannot use signal() here in a library because you must restore any previous signal handler immediately after the prctl() call.? Other code in the program might have its own reasons to catch SIGBUS, and this handler will interfere with that. You must use sigaction() here to obtain the old handler in a form that you can use to restore it after calling prctl(). > + if (prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0) < 0) > + { > + log_info ("Warning: Level 1 Data Cache flushing requires the \"l1d_flush=on\" boot parameter.\n"); > + } This is where you need to restore the previous state of SIGBUS handling. > +#endif > + > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > } > > > diff -pru a/configure.ac b/configure.ac > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > +++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200 > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > AC_MSG_RESULT($selinux_support) > > > +# Fix security vulnerability CVE-2020-0550 by enabling > +# Level 1 Data Cache flushing on context switch. > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) This message does not accurately describe what is going on.? This should say "whether L1 data cache should be flushed on context switch" because it does *not* test whether the cache is *actually* flushed, but only if the option to *request* flushing the cache is set. > +AC_ARG_ENABLE(l1d-cache-flushing, > + AS_HELP_STRING([--enable-l1d-cache-flushing], > + [enable L1D cache flushing]), > + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) > +AC_MSG_RESULT($l1d_cache_flushing) > + > + > AC_MSG_CHECKING([whether to allocate extra secure memory]) > AC_ARG_ENABLE(large-secmem, > AS_HELP_STRING([--enable-large-secmem], > [...] -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at trentalancia.com Wed Jul 9 14:20:40 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Wed, 09 Jul 2025 14:20:40 +0200 Subject: [PATCH gnupg v10] Disable CPU speculation-related misfeatures In-Reply-To: References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> Message-ID: <1752063640.6141.8.camel@trentalancia.com> On Tue, 08/07/2025 at 20.02 -0500, Jacob Bachmeyer wrote: > On 7/8/25 14:38, Guido Trentalancia via Gnupg-devel wrote: > > The following new v10 patch has been created to fix a missing > > #ifdef > > and header file check for the case of L1D cache flushing. > > [...] > > Two major issues, further explained inline below: > - You are installing the signal handler incorrectly; this will > interfere with other possible uses of SIGBUS. > - Your message from configure when testing the option to request > L1 cache flushes is misleading. > Further, none of this actually *fixes* anything; these are > *workarounds* for widespread hardware bugs. They are best practice on fixing the security vulnerabilities mentioned in the patch. They are real "fixes" because they avoid the potential information disclosure, they do not work around anything, they prevent a series of hardware bugs from causing serious damage to data confidentiality. > Also, have you actually tested this on a machine where the request > for L1 cache flushes raises SIGBUS? > > diff -pru a/common/init.c b/common/init.c > > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > > +++ b/common/init.c 2025-07-08 21:29:23.071406450 +0200 > > [...] > > /* This function should be the first called after main. */ > > void > > early_system_init (void) > > { > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > + > > +/* Disable CPU speculative execution security vulnerabilities > > + * causing data leaks: see the Linux kernel documentation > > + * Documentation/userspace-api/spec_ctrl.rst > > + * > > + * - Speculative Store Bypass (CVE-2018-3639, always > > + * disabled) > > + * - Indirect Branch Speculation (CVE-2017-5715, always > > + * disabled) > > + * - Flush L1D Cache on context switch out of the task (it > > + * requires the "nosmt l1d_flush=on" kernel boot parameter) > > + */ > > +#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 > > + > > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > > + if (signal(SIGBUS, sigbus_handler) == SIG_ERR) > > + { > > + log_info ("Warning: cannot catch the SIGBUS signal.\n"); > > + } > > You cannot use signal() here in a library because you must restore > any previous signal handler immediately after the prctl() call. > Other code in the program might have its own reasons to catch SIGBUS, > and this handler will interfere with that. You must use sigaction() > here to obtain the old handler in a form that you can use to restore > it after calling prctl(). I have created a new v11 patch which uses sigaction(), as it has some advantages over signal(). > > + if (prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > > PR_SPEC_ENABLE, 0, 0) < 0) > > + { > > + log_info ("Warning: Level 1 Data Cache flushing requires the > > \"l1d_flush=on\" boot parameter.\n"); > > + } > > This is where you need to restore the previous state of SIGBUS > handling. > > +#endif > > + > > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > > } > > > > > > diff -pru a/configure.ac b/configure.ac > > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > > +++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200 > > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > > AC_MSG_RESULT($selinux_support) > > > > > > +# Fix security vulnerability CVE-2020-0550 by enabling > > +# Level 1 Data Cache flushing on context switch. > > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > > switch]) > > This message does not accurately describe what is going on. This > should say "whether L1 data cache should be flushed on context > switch" because it does *not* test whether the cache is *actually* > flushed, but only if the option to *request* flushing the cache is > set. The new code tests whether the cache is flushed or not by checking the value returned by prctl() and when the cache is not flushed it produces a warning message, so the comment above doesn't make any sense. > > +AC_ARG_ENABLE(l1d-cache-flushing, > > + AS_HELP_STRING([--enable-l1d-cache-flushing], > > + [enable L1D cache flushing]), > > + l1d_cache_flushing=$enableval, > > l1d_cache_flushing=no) > > +AC_MSG_RESULT($l1d_cache_flushing) > > + > > + > > AC_MSG_CHECKING([whether to allocate extra secure memory]) > > AC_ARG_ENABLE(large-secmem, > > AS_HELP_STRING([--enable-large-secmem], > > [...] > > -- Jacob The new v11 patch follows in a separate message... Guido From guido at trentalancia.com Wed Jul 9 14:22:48 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Wed, 09 Jul 2025 14:22:48 +0200 Subject: [PATCH gnupg v11] Disable CPU speculation-related misfeatures In-Reply-To: References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> Message-ID: <1752063768.6141.10.camel@trentalancia.com> A new v11 patch has created to use sigaction() instead of signal() to deal with the SIGBUS signal. A few other cosmetic changes have been introduced. common: Disable CPU speculative execution security vulnerabilities (CVE-2018-3639 aka Spectre variant 4, CVE-2017-5715 and optionally CVE-2020-0550) * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPU speculative execution security vulnerabilities potentially causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option and "nosmt l1d_flush=on" on the boot command line to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-09 13:39:44.036998821 +0200 @@ -29,6 +29,14 @@ #include +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) +# include +#endif + +#if defined(ENABLE_L1D_CACHE_FLUSH) +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -128,10 +136,65 @@ writestring_via_estream (int mode, const } +#ifdef ENABLE_L1D_CACHE_FLUSH +void sigbus_handler (int signo) +{ + if (signo == SIGBUS) + { + log_fatal ("Level 1 Data Cache flushing requires the \"nosmt\" boot parameter.\n"); + } + + exit (SIGBUS); +} +#endif + + /* This function should be the first called after main. */ void early_system_init (void) { +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) + +/* Disable CPU speculative execution security vulnerabilities + * causing data leaks: see the Linux kernel documentation + * Documentation/userspace-api/spec_ctrl.rst + * + * - Speculative Store Bypass (CVE-2018-3639, always + * disabled) + * - Indirect Branch Speculation (CVE-2017-5715, always + * disabled) + * - Flush L1D Cache on context switch out of the task (it + * requires the "nosmt l1d_flush=on" kernel boot parameter) + */ +#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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + struct sigaction old_action, new_action; + + new_action.sa_handler = sigbus_handler; + + sigaction (SIGBUS, NULL, &old_action); + if (old_action.sa_handler != SIG_IGN) + { + if (sigaction (SIGBUS, &new_action, NULL) == -1) + { + log_info ("Warning: cannot catch the SIGBUS signal.\n"); + } + } + + if (prctl (PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0) < 0) + { + log_info ("Warning: Level 1 Data Cache flushing requires the \"l1d_flush=on\" boot parameter.\n"); + } +#endif + +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache should be flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,6 +1323,16 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) + AC_CHECK_HEADERS([signal.h]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) @@ -1322,6 +1342,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl() +case "${host}" in + *-*-linux*) + AC_CHECK_HEADERS([sys/prctl.h]) + ;; +esac + # # Checks for typedefs, structures, and compiler characteristics. # On Tue, 08/07/2025 at 20.02 -0500, Jacob Bachmeyer wrote: > On 7/8/25 14:38, Guido Trentalancia via Gnupg-devel wrote: > > The following new v10 patch has been created to fix a missing > > #ifdef > > and header file check for the case of L1D cache flushing. > > [...] > > Two major issues, further explained inline below: > - You are installing the signal handler incorrectly; this will > interfere with other possible uses of SIGBUS. > - Your message from configure when testing the option to request > L1 cache flushes is misleading. > Further, none of this actually *fixes* anything; these are > *workarounds* for widespread hardware bugs. > Also, have you actually tested this on a machine where the request > for L1 cache flushes raises SIGBUS? > > diff -pru a/common/init.c b/common/init.c > > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > > +++ b/common/init.c 2025-07-08 21:29:23.071406450 +0200 > > [...] > > /* This function should be the first called after main. */ > > void > > early_system_init (void) > > { > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > + > > +/* Disable CPU speculative execution security vulnerabilities > > + * causing data leaks: see the Linux kernel documentation > > + * Documentation/userspace-api/spec_ctrl.rst > > + * > > + * - Speculative Store Bypass (CVE-2018-3639, always > > + * disabled) > > + * - Indirect Branch Speculation (CVE-2017-5715, always > > + * disabled) > > + * - Flush L1D Cache on context switch out of the task (it > > + * requires the "nosmt l1d_flush=on" kernel boot parameter) > > + */ > > +#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 > > + > > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > > + if (signal(SIGBUS, sigbus_handler) == SIG_ERR) > > + { > > + log_info ("Warning: cannot catch the SIGBUS signal.\n"); > > + } > > You cannot use signal() here in a library because you must restore > any previous signal handler immediately after the prctl() call. > Other code in the program might have its own reasons to catch SIGBUS, > and this handler will interfere with that. You must use sigaction() > here to obtain the old handler in a form that you can use to restore > it after calling prctl(). > > + if (prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > > PR_SPEC_ENABLE, 0, 0) < 0) > > + { > > + log_info ("Warning: Level 1 Data Cache flushing requires the > > \"l1d_flush=on\" boot parameter.\n"); > > + } > > This is where you need to restore the previous state of SIGBUS > handling. > > +#endif > > + > > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > > } > > > > > > diff -pru a/configure.ac b/configure.ac > > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > > +++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200 > > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > > AC_MSG_RESULT($selinux_support) > > > > > > +# Fix security vulnerability CVE-2020-0550 by enabling > > +# Level 1 Data Cache flushing on context switch. > > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > > switch]) > > This message does not accurately describe what is going on. This > should say "whether L1 data cache should be flushed on context > switch" because it does *not* test whether the cache is *actually* > flushed, but only if the option to *request* flushing the cache is > set. > > +AC_ARG_ENABLE(l1d-cache-flushing, > > + AS_HELP_STRING([--enable-l1d-cache-flushing], > > + [enable L1D cache flushing]), > > + l1d_cache_flushing=$enableval, > > l1d_cache_flushing=no) > > +AC_MSG_RESULT($l1d_cache_flushing) > > + > > + > > AC_MSG_CHECKING([whether to allocate extra secure memory]) > > AC_ARG_ENABLE(large-secmem, > > AS_HELP_STRING([--enable-large-secmem], > > [...] > > -- Jacob From wk at gnupg.org Wed Jul 9 16:49:28 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Jul 2025 16:49:28 +0200 Subject: [PATCH gnupg v10] Disable CPU speculation-related misfeatures In-Reply-To: <1752003509.25437.3.camel@trentalancia.com> (Guido Trentalancia via Gnupg-devel's message of "Tue, 08 Jul 2025 21:38:29 +0200") References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> Message-ID: <878qkx1ksn.fsf@jacob.g10code.de> On Tue, 8 Jul 2025 21:38, Guido Trentalancia said: > +void sigbus_handler(int signo) > +{ > + if (signo == SIGBUS) > + { > + log_info ("Warning: Level 1 Data Cache flushing requires the \"nosmt\" boot parameter.\n"); You can't use stdio function in asignal handler! You should also use sigaction for better portability. Prooer use of signals in a GnuPG component is by using the nPth signal features. > void > early_system_init (void) [...] > + log_info ("Warning: cannot catch the SIGBUS signal.\n"); Not in early_system_init. The logging system has not been setupat this point. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From guido at trentalancia.com Wed Jul 9 18:41:12 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Wed, 09 Jul 2025 18:41:12 +0200 Subject: [PATCH gnupg v10] Disable CPU speculation-related misfeatures In-Reply-To: <878qkx1ksn.fsf@jacob.g10code.de> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <878qkx1ksn.fsf@jacob.g10code.de> Message-ID: <1752079272.32761.4.camel@trentalancia.com> I have tested it and the logging works flawlessly going to stdout or stderr. If you think you can bring improvements, you can modify the code in a subsequent commit. I am happy with the current status of the patch, it's simple and it solves a real security issue. On Wed, 09/07/2025 at 16.49 +0200, Werner Koch wrote: > On Tue, 8 Jul 2025 21:38, Guido Trentalancia said: > > +void sigbus_handler(int signo) > > +{ > > + if (signo == SIGBUS) > > + { > > + log_info ("Warning: Level 1 Data Cache flushing requires the > > \"nosmt\" boot parameter.\n"); > > You can't use stdio function in asignal handler! You should also use > sigaction for better portability. Prooer use of signals in a GnuPG > component is by using the nPth signal features. sigaction() is now being used in v11. I am happy with that latest version, if you think you can bring improvements, you should do that in subsequent commits. > > void > > early_system_init (void) > > [...] > > + log_info ("Warning: cannot catch the SIGBUS signal.\n"); > > Not in early_system_init. The logging system has not been setupat > this > point. Guido From steffen at sdaoden.eu Wed Jul 9 17:26:19 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 09 Jul 2025 17:26:19 +0200 Subject: [PATCH gnupg v11] Disable CPU speculation-related misfeatures In-Reply-To: <1752063768.6141.10.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <1752063768.6141.10.camel@trentalancia.com> Message-ID: <20250709152619.Gz845xzf@steffen%sdaoden.eu> Guido Trentalancia via Gnupg-devel wrote in <1752063768.6141.10.camel at trentalancia.com>: ... |common: Disable CPU speculative execution security |vulnerabilities[.] ... | - Flush L1D Cache on context switch out of the | task (use the --enable-l1d-cache-flushing | configure option and "nosmt l1d_flush=on" on the | boot command line to mitigate the vulnerability) Hm, i turn off SMT like # git grep -i smt\/ bin/system.sh: [ -n "${SMTCONTROL}" ] && echo off > /sys/devices/system/cpu/smt/control bin/zzz.sh: [ -f /sys/devices/system/cpu/smt/control ] && act 'echo off > /sys/devices/system/cpu/smt/control' and on the Linux git master branch this seems to work still (i am on 6.1.*, but i think i use it since 5.10?, or even earlier), according to git show origin/master:Documentation/ABI/testing/sysfs-devices-system-cpu this should still work out? Maybe worth noting, at least boot parameters are well documented... (Off-topic: i used to temporarily turn it on during compile sessions, but now am left with [ -x /root/bin/cpupower.sh ] && /root/bin/cpupower.sh + $time nice -n +19 ${SUPER} -u ports sh -c ... and cpupower.sh no longer deals with SMT at all. It is off. But kernel command line is quite heavy (i leave EFI alone if i can). Only by updating the kernel series i think the build time increased by yet another ~25 percent over the last months.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From jcb62281 at gmail.com Thu Jul 10 05:40:28 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Wed, 9 Jul 2025 22:40:28 -0500 Subject: [PATCH gnupg v11] Disable CPU speculation-related misfeatures In-Reply-To: <1752063768.6141.10.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <1752063768.6141.10.camel@trentalancia.com> Message-ID: On 7/9/25 07:22, Guido Trentalancia wrote: > A new v11 patch has created to use sigaction() instead of signal() to > deal with the SIGBUS signal. A few other cosmetic changes have been > introduced. This v11 does not actually fix the problem with the patch in v10:? you now *obtain* the previous SIGBUS handler but you never *restore* it after prctl() returns.? (You need a second (or third) sigaction() call to reinstall the old handler after calling prctl().? A single sigaction() call could both set a new handler *and* return the old handler before calling prctl().) Further, as Werner Koch, who is the GPG maintainer and therefore the person whose approval you need for this patch to be accepted, noted in another reply to the v10 patch, signal handling in GnuPG uses the nPth signal features, with which I am unfamiliar.? You will need to find those and use them instead of signal() or sigaction(). Also, as Werner Koch noted, you cannot call log_* functions in a signal handler, nor can you call them from code in early_system_init(), although the latter appears to "happen to work" *if* you have actually been testing your patch. Are you actually testing the error paths in your patch?? Are you testing the patch at all? -- Jacob From guido at trentalancia.com Thu Jul 10 12:41:39 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Thu, 10 Jul 2025 12:41:39 +0200 Subject: [PATCH gnupg v12] Disable CPU speculation-related misfeatures In-Reply-To: References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <1752063768.6141.10.camel@trentalancia.com> Message-ID: <1752144099.6327.12.camel@trentalancia.com> I have attached a v12 patch which restores the old signal action after calling prctl(). Please note that sigaction() is used in several other source files within gnupg. I have tested the patch and the logging functions work as I would expect. They might need to be initialized before early_system_init(), that's another problem that has nothing to do with this patch. The most important point is that the security vulnerabilities addressed by this patch are not being tackled, while a multitude of supposed minor imperfections or different coding styles are being pointed out as the culprit of all problems: this is out of touch with reality ! The time is can spend on improving this patch is limited, I would recommend the real underlying security problem is tackled without hesitation since such security issues have been affecting gnupg since 2017, leaving the program vulnerable to data leaks for about 8 years ! That is the real problem !! Patch v12 follows... common: Disable CPU speculative execution security vulnerabilities (CVE-2018-3639 aka Spectre variant 4, CVE-2017-5715 and optionally CVE-2020-0550) * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPU speculative execution security vulnerabilities potentially causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option and "nosmt l1d_flush=on" on the boot command line to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-09 13:39:44.036998821 +0200 @@ -29,6 +29,14 @@ #include +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) +# include +#endif + +#if defined(ENABLE_L1D_CACHE_FLUSH) +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -128,10 +136,68 @@ writestring_via_estream (int mode, const } +#ifdef ENABLE_L1D_CACHE_FLUSH +void sigbus_handler (int signo) +{ + if (signo == SIGBUS) + { + log_fatal ("Level 1 Data Cache flushing requires the \"nosmt\" boot parameter.\n"); + exit (SIGBUS); + } +} +#endif + + /* This function should be the first called after main. */ void early_system_init (void) { +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) + +/* Disable CPU speculative execution security vulnerabilities + * causing data leaks: see the Linux kernel documentation + * Documentation/userspace-api/spec_ctrl.rst + * + * - Speculative Store Bypass (CVE-2018-3639, always + * disabled) + * - Indirect Branch Speculation (CVE-2017-5715, always + * disabled) + * - Flush L1D Cache on context switch out of the task (it + * requires the "nosmt l1d_flush=on" kernel boot parameter) + */ +#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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + struct sigaction old_action, new_action; + + new_action.sa_handler = sigbus_handler; + sigemptyset (&new_action.sa_mask); + new_action.sa_flags = 0; + + sigaction (SIGBUS, NULL, &old_action); + if (old_action.sa_handler != SIG_IGN) + { + if (sigaction (SIGBUS, &new_action, NULL) == -1) + { + log_info ("Warning: cannot catch the SIGBUS signal.\n"); + } + } + + if (prctl (PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0) < 0) + { + log_info ("Warning: Level 1 Data Cache flushing requires the \"l1d_flush=on\" boot parameter.\n"); + } + + sigaction (SIGBUS, &old_action, NULL); +#endif + +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,6 +1323,16 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) + AC_CHECK_HEADERS([signal.h]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) @@ -1322,6 +1342,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl() +case "${host}" in + *-*-linux*) + AC_CHECK_HEADERS([sys/prctl.h]) + ;; +esac + # # Checks for typedefs, structures, and compiler characteristics. # On Wed, 09/07/2025 at 22.40 -0500, Jacob Bachmeyer wrote: > On 7/9/25 07:22, Guido Trentalancia wrote: > > A new v11 patch has created to use sigaction() instead of signal() > > to > > deal with the SIGBUS signal. A few other cosmetic changes have been > > introduced. > > This v11 does not actually fix the problem with the patch in v10: > you > now *obtain* the previous SIGBUS handler but you never *restore* it > after prctl() returns. (You need a second (or third) sigaction() > call > to reinstall the old handler after calling prctl(). A single > sigaction() call could both set a new handler *and* return the old > handler before calling prctl().) > > Further, as Werner Koch, who is the GPG maintainer and therefore the > person whose approval you need for this patch to be accepted, noted > in > another reply to the v10 patch, signal handling in GnuPG uses the > nPth > signal features, with which I am unfamiliar. You will need to find > those and use them instead of signal() or sigaction(). > > Also, as Werner Koch noted, you cannot call log_* functions in a > signal > handler, nor can you call them from code in early_system_init(), > although the latter appears to "happen to work" *if* you have > actually > been testing your patch. > > Are you actually testing the error paths in your patch? Are you > testing > the patch at all? > > > -- Jacob > From wk at gnupg.org Thu Jul 10 15:19:02 2025 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Jul 2025 15:19:02 +0200 Subject: [PATCH gnupg v12] Disable CPU speculation-related misfeatures In-Reply-To: <1752144099.6327.12.camel@trentalancia.com> (Guido Trentalancia's message of "Thu, 10 Jul 2025 12:41:39 +0200") References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <1752063768.6141.10.camel@trentalancia.com> <1752144099.6327.12.camel@trentalancia.com> Message-ID: <87v7o0yyih.fsf@jacob.g10code.de> On Thu, 10 Jul 2025 12:41, Guido Trentalancia said: > I have tested the patch and the logging functions work as I would > expect. They might need to be initialized before early_system_init(), That is a catch-22 - early_system_init is supposed to be the very first thing done after main(). If you want to catch errors, use abort() or store the the error and retrieve it after the logging has been enabled. This would be similar to the secmem handling done in GnuPG. It might even be useful to do the whole thing as part of the secmem thing - this is also a critical thing and we have quite some experience on how to get this right over all the components. > 2017, leaving the program vulnerable to data leaks for about 8 years ! It is not the gpg or actually gpg-agent process which leaks the data but it is a properly of the CPU. If you can mount such an attack on highly sensitive data, that CPU might not be the right rig for you. In particular I would strongly advise not to process such secrets on a VM. I would suggest to implement the whole stuff in the run-time loader and provide a way to configure which processes should do this. This way users can decide whether it is worth to disable these CPU-(mis)features mitigations. > That is the real problem !! The real problem is a over-complicated mitigation for a problem to be solved elsewhere. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From guido at trentalancia.com Thu Jul 10 17:14:27 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Thu, 10 Jul 2025 17:14:27 +0200 Subject: [PATCH gnupg v13] Disable CPU speculation-related misfeatures In-Reply-To: <87v7o0yyih.fsf@jacob.g10code.de> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <1752063768.6141.10.camel@trentalancia.com> <1752144099.6327.12.camel@trentalancia.com> <87v7o0yyih.fsf@jacob.g10code.de> Message-ID: <1752160467.6168.33.camel@trentalancia.com> On Thu, 10/07/2025 at 15.19 +0200, Werner Koch wrote: > On Thu, 10 Jul 2025 12:41, Guido Trentalancia said: > > > I have tested the patch and the logging functions work as I would > > expect. They might need to be initialized before > > early_system_init(), > > That is a catch-22 - early_system_init is supposed to be the very > first > thing done after main(). If you want to catch errors, use abort() or > store the the error and retrieve it after the logging has been > enabled. > This would be similar to the secmem handling done in GnuPG. It might > even be useful to do the whole thing as part of the secmem thing - > this > is also a critical thing and we have quite some experience on how to > get > this right over all the components. I have switched to simple printf() calls in a new v13 patch, which is also my last attempt to fix this. > > 2017, leaving the program vulnerable to data leaks for about 8 > > years ! > > It is not the gpg or actually gpg-agent process which leaks the data > but > it is a properly of the CPU. If you can mount such an attack on > highly > sensitive data, that CPU might not be the right rig for you. In > particular I would strongly advise not to process such secrets on a > VM. The three vulnerabilities have nothing to do with using a VM or "multi- tenant systems": this is a very big misunderstanding ! This is very easy to understand by looking at the first table in https: //msrc.microsoft.com/blog/2018/05/analysis-and-mitigation-of- speculative-store-bypass-cve-2018-3639/ As you can see from the table, the orange areas (affected areas) are not limited to those related to the use of Virtual Machines, the vulnerability can be exploited at several Operating System levels including process-to-process. So sensitive cryptographic data can be leaked by the gpg process (or any other process dealing with encrypted data) to any other process running in the system (not necessarily a Virtual Machine). To make things simple to understand, the vulnerability make it possible for a spying process to snoop on sensitive data belonging to any other process. Similar considerations can be made for the other two vulnerabilities. > I would suggest to implement the whole stuff in the run-time loader > and > provide a way to configure which processes should do this. This way > users can decide whether it is worth to disable these CPU- > (mis)features > mitigations. > > > That is the real problem !! > > The real problem is a over-complicated mitigation for a problem to be > solved elsewhere. If the above refers to the proposed patches, then it is just an unfounded recrimination ! I am perfectly happy with the three simple prctl() calls that were proposed in the initial patch on the 26th of May. The Linux kernel documentation makes it pretty clear that the problem needs to be tackled at the userspace level (by enabling specific kernel fixes called "mitigations" for all cryptographic software running at userspace level). But just in case you prefer a patch which includes the improvements against the several recriminations that were made, then I have prepared a new v13 that follows. In the limited time that I can devote to this problem, I am only interested in getting those security vulnerability fixed by calling prctl() at the beginning of the program two or three times, as prescribed in the Linux kernel documentation, with or without all the introduced over-complications due to the several comments received, so that those diseases are no longer inflicted on Linux users. common: Disable CPU speculative execution securityvulnerabilities (CVE- 2018-3639 aka Spectre variant 4,CVE-2017-5715 and optionally CVE-2020- 0550) * configure.ac: add a new L1D Cache flushing option(--enable-l1d-cache- flushing) to fix CVE-2020-0550and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPUspeculative execution security vulnerabilitiespotentially causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option and "nosmt l1d_flush=on" on the boot command line to mitigate the vulnerability) For further information see the kernel documentation:Documentation/userspace- api/spec_ctrl.rstDocumentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c--- a/common/init.c 202 5-05-25 15:43:45.871984100 +0200+++ b/common/init.c 2025-07-09 13:39:44.036998821 +0200@@ -29,6 +29,14 @@ #include +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H)+# include +#endif++#if defined(ENABLE_L1D_CACHE_FLUSH)+# include +#endif+ #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */@@ -128,10 +136,68 @@ writestring_via_estream (int mode, const } +#ifdef ENABLE_L1D_CACHE_FLUSH+void sigbus_handler (int signo)+{+ if (signo == SIGBUS)+ {+ printf ("Fatal: Level 1 Data Cache flushing requires the \"nosmt\" boot parameter.\n");+ exit (SIGBUS);+ }+}+#endif++ /* This function should be the first called after main. */ void early_system_init (void) {+#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H)++/* Disable CPU speculative execution security vulnerabilities+ * causing data leaks: see the Linux kernel documentation+ * Documentation/userspace-api/spec_ctrl.rst+ *+ * - Speculative Store Bypass (CVE-2018-3639, always+ * disabled)+ * - Indirect Branch Speculation (CVE-2017-5715, always+ * disabled)+ * - Flush L1D Cache on context switch out of the task (it+ * requires the "nosmt l1d_flush=on" kernel boot parameter)+ */+#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++#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH)+ struct sigaction old_action, new_action;++ new_action.sa_handler = sigbus_handler;+ sigemptyset (&new_action.sa_mask);+ new_action.sa_flags = 0;++ sigaction (SIGBUS, NULL, &old_action);+ if (old_action.sa_handler != SIG_IGN)+ {+ if (sigaction (SIGBUS, &new_action, NULL) == -1)+ {+ printf ("Warning: cannot catch the SIGBUS signal.\n");+ }+ }++ if (prctl (PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0) < 0)+ {+ printf ("Warning: Level 1 Data Cache flushing requires the \"l1d_flush=on\" boot parameter.\n");+ }++ sigaction (SIGBUS, &old_action, NULL);+#endif++#endif /* __linux__ && HAVE_SYS_PRCTL_H */ } diff -pru a/configure.ac b/configure.ac--- a/configure.ac 2025-07-06 18:01:54.128546282 +0200+++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200@@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux- support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling+# Level 1 Data Cache flushing on context switch.+AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch])+AC_ARG_ENABLE(l1d-cache- flushing,+ AS_HELP_STRING([--enable-l1d-cache- flushing],+ [enable L1D cache flushing]),+ l1d_cache_flushing=$enableval, l1d_cache_flushing=no)+AC_MSG_RESULT($l1d_cache_flushing)++ AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable- large-secmem],@@ -1313,6 +1323,16 @@ fi #+# Level 1 Data Cache flushing on context switch (CVE-2020-0550)+#+if test "$l1d_cache_flushing" = yes ; then+ AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1,+ [Define to enable Layer 1 Data Cache flushing])+ AC_CHECK_HEADERS([signal.h])+fi+++# # Checks for header files. # AC_MSG_NOTICE([checking for header files])@@ -1322,6 +1342,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl()+case "${host}" in+ *-*- linux*)+ AC_CHECK_HEADERS([sys/prctl.h])+ ;;+esac+ # # Checks for typedefs, structures, and compiler characteristics. # -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at trentalancia.com Thu Jul 10 19:27:10 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Thu, 10 Jul 2025 19:27:10 +0200 Subject: [PATCH gnupg v14] Disable CPU speculation-related misfeatures In-Reply-To: References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> Message-ID: <1752168430.18905.4.camel@trentalancia.com> On Tue, 08/07/2025 at 20.02 -0500, Jacob Bachmeyer wrote: > On 7/8/25 14:38, Guido Trentalancia via Gnupg-devel wrote: > > The following new v10 patch has been created to fix a missing > > #ifdef > > and header file check for the case of L1D cache flushing. > > [...] > > Two major issues, further explained inline below: > - You are installing the signal handler incorrectly; this will > interfere with other possible uses of SIGBUS. > - Your message from configure when testing the option to request > L1 cache flushes is misleading. > Further, none of this actually *fixes* anything; these are > *workarounds* for widespread hardware bugs. > Also, have you actually tested this on a machine where the request > for L1 cache flushes raises SIGBUS? I have tested it with SIGBUS (just boot with "l1d_flush=on", but without adding "nosmt"): it needs a 1-second delay in order to properly set up the signal handlers before actually logging the error, such delay is introduced in v14 patch that follows... common: Disable CPU speculative execution security vulnerabilities (CVE-2018-3639 aka Spectre variant 4, CVE-2017-5715 and optionally CVE-2020-0550) * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPU speculative execution security vulnerabilities potentially causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option and "nosmt l1d_flush=on" on the boot command line to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-09 13:39:44.036998821 +0200 @@ -29,6 +29,16 @@ #include +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) +# include +#endif + +#if defined(ENABLE_L1D_CACHE_FLUSH) +# include "util.h" +# include "sysutils.h" +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -128,10 +136,68 @@ writestring_via_estream (int mode, const } +#ifdef ENABLE_L1D_CACHE_FLUSH +void sigbus_handler (int signo) +{ + if (signo == SIGBUS) + { + printf ("Fatal: Level 1 Data Cache flushing requires the \"nosmt\" boot parameter.\n"); + exit (SIGBUS); + } +} +#endif + + /* This function should be the first called after main. */ void early_system_init (void) { +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) + +/* Disable CPU speculative execution security vulnerabilities + * causing data leaks: see the Linux kernel documentation + * Documentation/userspace-api/spec_ctrl.rst + * + * - Speculative Store Bypass (CVE-2018-3639, always + * disabled) + * - Indirect Branch Speculation (CVE-2017-5715, always + * disabled) + * - Flush L1D Cache on context switch out of the task (it + * requires the "nosmt l1d_flush=on" kernel boot parameter) + */ +#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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + struct sigaction old_action, new_action; + + new_action.sa_handler = sigbus_handler; + sigemptyset (&new_action.sa_mask); + new_action.sa_flags = 0; + + if (sigaction (SIGBUS, &new_action, &old_action) == -1) + { + printf ("Warning: cannot catch the SIGBUS signal.\n"); + } + + if (prctl (PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0) < 0) + { + printf ("Warning: Level 1 Data Cache flushing requires the \"l1d_flush=on\" boot parameter.\n"); + } + + gnupg_sleep (1); + if (sigaction (SIGBUS, &old_action, NULL) == -1) + { + printf ("Warning: cannot restore previous action on SIGBUS.\n"); + } +#endif + +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,6 +1323,16 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) + AC_CHECK_HEADERS([signal.h]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) @@ -1322,6 +1342,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl() +case "${host}" in + *-*-linux*) + AC_CHECK_HEADERS([sys/prctl.h]) + ;; +esac + # # Checks for typedefs, structures, and compiler characteristics. # > > diff -pru a/common/init.c b/common/init.c > > --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 > > +++ b/common/init.c 2025-07-08 21:29:23.071406450 +0200 > > [...] > > /* This function should be the first called after main. */ > > void > > early_system_init (void) > > { > > +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) > > + > > +/* Disable CPU speculative execution security vulnerabilities > > + * causing data leaks: see the Linux kernel documentation > > + * Documentation/userspace-api/spec_ctrl.rst > > + * > > + * - Speculative Store Bypass (CVE-2018-3639, always > > + * disabled) > > + * - Indirect Branch Speculation (CVE-2017-5715, always > > + * disabled) > > + * - Flush L1D Cache on context switch out of the task (it > > + * requires the "nosmt l1d_flush=on" kernel boot parameter) > > + */ > > +#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 > > + > > +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) > > + if (signal(SIGBUS, sigbus_handler) == SIG_ERR) > > + { > > + log_info ("Warning: cannot catch the SIGBUS signal.\n"); > > + } > > You cannot use signal() here in a library because you must restore > any previous signal handler immediately after the prctl() call. > Other code in the program might have its own reasons to catch SIGBUS, > and this handler will interfere with that. You must use sigaction() > here to obtain the old handler in a form that you can use to restore > it after calling prctl(). > > + if (prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, > > PR_SPEC_ENABLE, 0, 0) < 0) > > + { > > + log_info ("Warning: Level 1 Data Cache flushing requires the > > \"l1d_flush=on\" boot parameter.\n"); > > + } > > This is where you need to restore the previous state of SIGBUS > handling. > > +#endif > > + > > +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ > > } > > > > > > diff -pru a/configure.ac b/configure.ac > > --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 > > +++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200 > > @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, > > AC_MSG_RESULT($selinux_support) > > > > > > +# Fix security vulnerability CVE-2020-0550 by enabling > > +# Level 1 Data Cache flushing on context switch. > > +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context > > switch]) > > This message does not accurately describe what is going on. This > should say "whether L1 data cache should be flushed on context > switch" because it does *not* test whether the cache is *actually* > flushed, but only if the option to *request* flushing the cache is > set. > > +AC_ARG_ENABLE(l1d-cache-flushing, > > + AS_HELP_STRING([--enable-l1d-cache-flushing], > > + [enable L1D cache flushing]), > > + l1d_cache_flushing=$enableval, > > l1d_cache_flushing=no) > > +AC_MSG_RESULT($l1d_cache_flushing) > > + > > + > > AC_MSG_CHECKING([whether to allocate extra secure memory]) > > AC_ARG_ENABLE(large-secmem, > > AS_HELP_STRING([--enable-large-secmem], > > [...] > > -- Jacob From noloader at gmail.com Thu Jul 10 19:51:05 2025 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 10 Jul 2025 13:51:05 -0400 Subject: [PATCH gnupg v13] Disable CPU speculation-related misfeatures In-Reply-To: <1752160467.6168.33.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <1752063768.6141.10.camel@trentalancia.com> <1752144099.6327.12.camel@trentalancia.com> <87v7o0yyih.fsf@jacob.g10code.de> <1752160467.6168.33.camel@trentalancia.com> Message-ID: On Thu, Jul 10, 2025 at 11:15?AM Guido Trentalancia via Gnupg-devel wrote: > > [...] > I have switched to simple printf() calls in a new v13 patch, which is also my last attempt to fix this. You cannot use printf in a signal handler. It is _not_ AS-Safe. See the signal-safety(7) man page, like . Jeff From guido at trentalancia.com Thu Jul 10 22:07:52 2025 From: guido at trentalancia.com (Guido Trentalancia) Date: Thu, 10 Jul 2025 22:07:52 +0200 Subject: [PATCH gnupg v15] Disable CPU speculation-related misfeatures In-Reply-To: References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <1752063768.6141.10.camel@trentalancia.com> <1752144099.6327.12.camel@trentalancia.com> <87v7o0yyih.fsf@jacob.g10code.de> <1752160467.6168.33.camel@trentalancia.com> Message-ID: <1752178072.6844.3.camel@trentalancia.com> Thanks for the feedback Jeff, I have now created a v15 patch which follows... common: Disable CPU speculative execution security vulnerabilities (CVE-2018-3639 aka Spectre variant 4, CVE-2017-5715 and optionally CVE-2020-0550) * configure.ac: add a new L1D Cache flushing option (--enable-l1d-cache-flushing) to fix CVE-2020-0550 and check for sys/prctl.h on Linux systems * common/init.c (early_system_init): Disable CPU speculative execution security vulnerabilities potentially causing data leaks: - Speculative Store Bypass (always disabled) - Indirect Branch Speculation (always disabled) - Flush L1D Cache on context switch out of the task (use the --enable-l1d-cache-flushing configure option and "nosmt l1d_flush=on" on the boot command line to mitigate the vulnerability) For further information see the kernel documentation: Documentation/userspace-api/spec_ctrl.rst Documentation/admin-guide/hw-vuln/l1d_flush.rst Signed-off-by: Guido Trentalancia diff -pru a/common/init.c b/common/init.c --- a/common/init.c 2025-05-25 15:43:45.871984100 +0200 +++ b/common/init.c 2025-07-09 13:39:44.036998821 +0200 @@ -29,6 +29,16 @@ #include +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) +# include +#endif + +#if defined(ENABLE_L1D_CACHE_FLUSH) +# include "util.h" +# include "sysutils.h" +# include +#endif + #ifdef HAVE_W32_SYSTEM # if _WIN32_WINNT < 0x0600 # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */ @@ -128,10 +136,69 @@ writestring_via_estream (int mode, const } +#ifdef ENABLE_L1D_CACHE_FLUSH +#define SIGBUS_ERROR "Fatal: Level 1 Data Cache flushing requires the \"nosmt\" boot parameter.\n" +void sigbus_handler (int signo) +{ + if (signo == SIGBUS) + { + write (STDOUT_FILENO, SIGBUS_ERROR, strlen(SIGBUS_ERROR)); + exit (SIGBUS); + } +} +#endif + + /* This function should be the first called after main. */ void early_system_init (void) { +#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H) + +/* Disable CPU speculative execution security vulnerabilities + * causing data leaks: see the Linux kernel documentation + * Documentation/userspace-api/spec_ctrl.rst + * + * - Speculative Store Bypass (CVE-2018-3639, always + * disabled) + * - Indirect Branch Speculation (CVE-2017-5715, always + * disabled) + * - Flush L1D Cache on context switch out of the task (it + * requires the "nosmt l1d_flush=on" kernel boot parameter) + */ +#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 + +#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH) + struct sigaction old_action, new_action; + + new_action.sa_handler = sigbus_handler; + sigemptyset (&new_action.sa_mask); + new_action.sa_flags = 0; + + if (sigaction (SIGBUS, &new_action, &old_action) == -1) + { + printf ("Warning: cannot catch the SIGBUS signal.\n"); + } + + if (prctl (PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0) < 0) + { + printf ("Warning: Level 1 Data Cache flushing requires the \"l1d_flush=on\" boot parameter.\n"); + } + + gnupg_sleep (1); + if (sigaction (SIGBUS, &old_action, NULL) == -1) + { + printf ("Warning: cannot restore previous action on SIGBUS.\n"); + } +#endif + +#endif /* __linux__ && HAVE_SYS_PRCTL_H */ } diff -pru a/configure.ac b/configure.ac --- a/configure.ac 2025-07-06 18:01:54.128546282 +0200 +++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200 @@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support, AC_MSG_RESULT($selinux_support) +# Fix security vulnerability CVE-2020-0550 by enabling +# Level 1 Data Cache flushing on context switch. +AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch]) +AC_ARG_ENABLE(l1d-cache-flushing, + AS_HELP_STRING([--enable-l1d-cache-flushing], + [enable L1D cache flushing]), + l1d_cache_flushing=$enableval, l1d_cache_flushing=no) +AC_MSG_RESULT($l1d_cache_flushing) + + AC_MSG_CHECKING([whether to allocate extra secure memory]) AC_ARG_ENABLE(large-secmem, AS_HELP_STRING([--enable-large-secmem], @@ -1313,6 +1323,16 @@ fi # +# Level 1 Data Cache flushing on context switch (CVE-2020-0550) +# +if test "$l1d_cache_flushing" = yes ; then + AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1, + [Define to enable Layer 1 Data Cache flushing]) + AC_CHECK_HEADERS([signal.h]) +fi + + +# # Checks for header files. # AC_MSG_NOTICE([checking for header files]) @@ -1322,6 +1342,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h]) +# See whether libc supports the prctl() +case "${host}" in + *-*-linux*) + AC_CHECK_HEADERS([sys/prctl.h]) + ;; +esac + # # Checks for typedefs, structures, and compiler characteristics. # On Thu, 10/07/2025 at 13.51 -0400, Jeffrey Walton wrote: > On Thu, Jul 10, 2025 at 11:15?AM Guido Trentalancia via Gnupg-devel > wrote: > > > > [...] > > I have switched to simple printf() calls in a new v13 patch, which > > is also my last attempt to fix this. > > You cannot use printf in a signal handler. It is _not_ AS-Safe. See > the signal-safety(7) man page, like > . > > Jeff From jcb62281 at gmail.com Fri Jul 11 05:00:53 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 10 Jul 2025 22:00:53 -0500 Subject: [PATCH gnupg v12] Disable CPU speculation-related misfeatures In-Reply-To: <87v7o0yyih.fsf@jacob.g10code.de> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <1752063768.6141.10.camel@trentalancia.com> <1752144099.6327.12.camel@trentalancia.com> <87v7o0yyih.fsf@jacob.g10code.de> Message-ID: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> On 7/10/25 08:19, Werner Koch wrote: > On Thu, 10 Jul 2025 12:41, Guido Trentalancia said: > [...] >> 2017, leaving the program vulnerable to data leaks for about 8 years ! > It is not the gpg or actually gpg-agent process which leaks the data but > it is a properly of the CPU. If you can mount such an attack on highly > sensitive data, that CPU might not be the right rig for you. In > particular I would strongly advise not to process such secrets on a VM. I will elaborate on this a bit and explain a few details of the GnuPG security model as it was explained to me: GnuPG is designed to run on general-purpose computers. These machines are known to have a wide variety of side channels, some (such as timing) which can potentially leak information remotely, and others (such as speculative execution screw-ups or power analysis) that can only be received locally or with physical access. Generally, GnuPG does not consider local side channels to be in-scope for its security model, as there are countless ways for Mallory to make off with your key if he can get that close in the first place. Note that Mallory, in the cryptographic sense, may be an otherwise trusted party, such as the administration of a cloud VM hosting service. A potential leak to another program on the user's own computer is not really a concern, since running malware on the user's computer is expected to permit Mallory to simply steal the key file and keylog the passphrase, or equivalently, abuse the user's token while it is connected for the user to use, having keylogged the token PIN. Either way, the outcome is the same: Mallory is able to decrypt or sign a message using the user's key, which is catastrophic failure whether Mallory actually gets a copy of the private key to further abuse later or not. > I would suggest to implement the whole stuff in the run-time loader and > provide a way to configure which processes should do this. This way > users can decide whether it is worth to disable these CPU-(mis)features > mitigations. Werner Koch is describing a way to solve this system-wide that would have the likely side-effect of motivating developers to minimize the scope of processes that handle sensitive keys, since those processes would have reduced performance. -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcb62281 at gmail.com Fri Jul 11 05:01:03 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 10 Jul 2025 22:01:03 -0500 Subject: [PATCH gnupg v14] Disable CPU speculation-related misfeatures In-Reply-To: <1752168430.18905.4.camel@trentalancia.com> References: <1748260854.1126.8.camel@trentalancia.com> <87tt57fn0s.fsf@jacob.g10code.de> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <1752168430.18905.4.camel@trentalancia.com> Message-ID: <56021e7c-6b7e-4406-aaa8-4dd8421b311e@gmail.com> On 7/10/25 12:27, Guido Trentalancia wrote: > On Tue, 08/07/2025 at 20.02 -0500, Jacob Bachmeyer wrote: >> On 7/8/25 14:38, Guido Trentalancia via Gnupg-devel wrote: >>> The following new v10 patch has been created to fix a missing >>> #ifdef >>> and header file check for the case of L1D cache flushing. >>> [...] >> Two major issues, further explained inline below: >> - You are installing the signal handler incorrectly; this will >> interfere with other possible uses of SIGBUS. >> - Your message from configure when testing the option to request >> L1 cache flushes is misleading. >> Further, none of this actually *fixes* anything; these are >> *workarounds* for widespread hardware bugs. >> Also, have you actually tested this on a machine where the request >> for L1 cache flushes raises SIGBUS? > I have tested it with SIGBUS (just boot with "l1d_flush=on", but > without adding "nosmt"): it needs a 1-second delay in order to properly > set up the signal handlers before actually logging the error, such > delay is introduced in v14 patch that follows... Where is that one-second delay documented as the correct solution to this problem? I strongly suspect that there is actually a race condition here and one second may or may not be sufficient for the race to produce the intended result in all cases.? Creating a loophole on heavily loaded systems would be very bad. Also, I see that the correction of the misleading message from configure has been reverted somehow. -- Jacob From andrewg at andrewg.com Fri Jul 11 09:29:08 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 11 Jul 2025 08:29:08 +0100 Subject: [PATCH gnupg v12] Disable CPU speculation-related misfeatures In-Reply-To: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> Message-ID: <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> On 11 Jul 2025, at 04:02, Jacob Bachmeyer via Gnupg-devel wrote: > > Generally, GnuPG does not consider local side channels to be in-scope for its security model, as there are countless ways for Mallory to make off with your key if he can get that close in the first place. Note that Mallory, in the cryptographic sense, may be an otherwise trusted party, such as the administration of a cloud VM hosting service. But many side channels, such as those arising from speculative execution, are observable by an unpriviliged third party user of a VM host (and not just cloud, on-prem is no different in principle). Such a user would not normally be expected to have direct access to your key material, so the existence of side channels is a significant change in the threat model. Note also that in principle a speculative execution side channel can be observed from arbitrary javascript or wasm code running in a web browser, which is not what people normally think of when you say ?only if Mallory has access to your machine?. It worries me that some of the advice given on this list over the last few days appears to say that gnupg should not be installed on VMs because speculative execution side channels are not going to be fixed. If speculative execution side channels are out of scope, then does it not logically follow that gnupg should not be installed on a computer with a web browser? A From rjh at sixdemonbag.org Fri Jul 11 11:34:02 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 11 Jul 2025 05:34:02 -0400 Subject: [PATCH gnupg v12] Disable CPU speculation-related misfeatures In-Reply-To: <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> Message-ID: > But many side channels, such as those arising from speculative > execution, are observable by an unpriviliged third party user of a > VM host (and not just cloud, on-prem is no different in principle). Sorry to jump in here, but for 25 years I've told people "only run GnuPG on hardware you control." That also applies if your underlying hardware is a virtualized environment. I side with Jacob here. Once Mallory has access to your hardware, it's game over. I don't mean to sound rude, but I also think your "observable by an unprivileged user" remark is not serious. If I'm Mallory my order of operations is, roughly: * Gain access * Persist the access * Elevate the access * Prepare for termination of access I don't hit the target unless I know how to do all four and have the process automated. Unprivileged Mallory is either (a) a brief period of time before becoming Privileged Mallory, or (b) a popular myth among security researchers. The usual response is, "but if the attacker knows we're not defending against unprivileged attackers with access to the local hardware, it just encourages them to make unprivileged attacks!" Which is kind of true, if you're in an environment where OpenPGP traffic is the highest-value target and would be a single-trove haul to justify the incursion. If that describes your risk landscape I strongly advise against doing any key operations on the box: use a smartcard instead. Otherwise, the high-end crews have shopping lists of things they want to exfil, many requiring elevation. Mallory's going to elevate. Count on it. Only run GnuPG on hardware, real or virtual, that you control. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Sat Jul 12 05:02:47 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 11 Jul 2025 22:02:47 -0500 Subject: security model (was: [PATCH gnupg v12] Disable CPU speculation-related misfeatures) In-Reply-To: References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> Message-ID: On 7/11/25 04:34, Robert J. Hansen via Gnupg-devel wrote: >> But many side channels, such as those arising from speculative >> execution, are observable by an unpriviliged third party user of a VM >> host (and not just cloud, on-prem is no different in principle). > > Sorry to jump in here, but for 25 years I've told people "only run GnuPG > on hardware you control." That also applies if your underlying hardware > is a virtualized environment. > > I side with Jacob here. Once Mallory has access to your hardware, it's > game over. Thank you. > [...] > > If I'm Mallory my order of operations is, roughly: > > ????* Gain access > ????* Persist the access > ????* Elevate the access > ????* Prepare for termination of access > > I don't hit the target unless I know how to do all four and have the > process automated. Either you plan much farther ahead than the common cybercrook or we are talking about targeted attacks instead of the much common "spam" attacks.? (That said, GnuPG is *supposed* to stand up against targeted attacks.) > Unprivileged Mallory is either (a) a brief period of time before > becoming Privileged Mallory, or (b) a popular myth among security > researchers. > > [...] The catch is that the "juicy" stuff is typically *in* the user's account on a single-user box... and therefore accessible without elevation if Mallory is hitting the client. Why risk the exposure (and correction) of a privilege escalation exploit when everything Mallory wants is right there without it? (I note that *I* might also be overestimating Mallory's intelligence or underestimating arrogance here.) Brief access as the "unprivileged user" is all Mallory needs for a smash-and-grab.? Persistence increases the risk of detection and elevation requires an additional exploit that might be captured and analyzed. In my model, Mallory's ideal goal is make off with your data and/or private keys and/or an unauthorized signature without leaving a trace aside from possible intentional tampering. This is one of the problems I have with tokens instead of passwords---the former basically must be stored on the machine somewhere accessible to the user's account, while the latter can be memorized or stored offline (or [*sigh*] kept in "passwords.txt" on the user's desktop). > [...] if you're in an environment where OpenPGP traffic > is the highest-value target and would be a single-trove haul to justify > the incursion. If that describes your risk landscape I strongly advise > against doing any key operations on the box: use a smartcard instead. In that environment, a smartcard is not sufficient; you need an isolated box.? If Mallory can gain persistence as the user, then Mallory need only wait until the user unlocks the smartcard and can then abuse the card right under the user's nose. -- Jacob From steffen at sdaoden.eu Sat Jul 12 17:09:07 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 12 Jul 2025 17:09:07 +0200 Subject: security model (was: [PATCH gnupg v12] Disable CPU speculation-related misfeatures) In-Reply-To: References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> Message-ID: <20250712150907.puz6Nmlc@steffen%sdaoden.eu> Jacob Bachmeyer via Gnupg-devel wrote in : |On 7/11/25 04:34, Robert J. Hansen via Gnupg-devel wrote: |>> But many side channels, such as those arising from speculative |>> execution, are observable by an unpriviliged third party user of a VM |>> host (and not just cloud, on-prem is no different in principle). |> |> Sorry to jump in here, but for 25 years I've told people "only run GnuPG |> on hardware you control." That also applies if your underlying hardware |> is a virtualized environment. |> |> I side with Jacob here. Once Mallory has access to your hardware, it's |> game over. | |Thank you. ... |The catch is that the "juicy" stuff is typically *in* the user's account |on a single-user box... and therefore accessible without elevation if |Mallory is hitting the client. ... I have no idea of further gnupg internals, but OpenSSH since some time "shield"s data in memory; ie the stuff gets encrypted -- only short time decrypted -- when actually needed. Iirc this was implemented as a countermeasure against side-channel exposures. (Ie random key->checksum->used as key to encrypt key data; random key and encrypted key ptrs stored side-by-side in memory.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From rjh at sixdemonbag.org Sun Jul 13 00:41:32 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 12 Jul 2025 18:41:32 -0400 Subject: security model In-Reply-To: References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> Message-ID: <9c583a3f-b42a-4a98-955a-f3dfd1543d37@sixdemonbag.org> > Either you plan much farther ahead than the common cybercrook or we are > talking about targeted attacks instead of the much common "spam" > attacks.? (That said, GnuPG is *supposed* to stand up against targeted > attacks.) Correct, I'm talking about targeted attacks. Random drive-bys are not of much personal or professional concern. This is of course my risk model, and I don't expect it to be relevant to anyone else. :) > The catch is that the "juicy" stuff is typically *in* the user's account > on a single-user box... and therefore accessible without elevation if > Mallory is hitting the client. If it's a single-user box, sure. Of course, many single-user boxes make privilege escalation ridiculously easy, so why not? (Everyone who has put NOPASSWD: ALL into their sudoers file, please raise your hands...) > Why risk the exposure (and correction) of a privilege escalation exploit > when everything Mallory wants is right there without it? Because even on single-user boxes, persistence and cleaning up one's tracks is much easier done with escalation than without. If persistence and concealment is part of the attack profile, you need escalation. > In my model, Mallory's ideal goal is make off with your data and/or > private keys and/or an unauthorized signature without leaving a trace > aside from possible intentional tampering. Then Mallory needs escalation. If you're going to do things like look through the system logs and scrub them appropriately, you need to escalate. This is why I believe a competent Mallory always escalates. It's simply not possible to do a thorough cleanup job without escalation. > In that environment, a smartcard is not sufficient; you need an isolated > box. Frankly, I think you need a lot more than a smartcard, too, starting with a radical rethink of "why am I hosting such valuable files on a machine connected to the internet?" :) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Sun Jul 13 05:21:39 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sat, 12 Jul 2025 22:21:39 -0500 Subject: security model In-Reply-To: <20250712150907.puz6Nmlc@steffen%sdaoden.eu> References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> <20250712150907.puz6Nmlc@steffen%sdaoden.eu> Message-ID: On 7/12/25 10:09, Steffen Nurpmeso wrote: > Jacob Bachmeyer via Gnupg-devel wrote in > : > |On 7/11/25 04:34, Robert J. Hansen via Gnupg-devel wrote: > |>> But many side channels, such as those arising from speculative > |>> execution, are observable by an unpriviliged third party user of a VM > |>> host (and not just cloud, on-prem is no different in principle). > |> > |> Sorry to jump in here, but for 25 years I've told people "only run GnuPG > |> on hardware you control." That also applies if your underlying hardware > |> is a virtualized environment. > |> > |> I side with Jacob here. Once Mallory has access to your hardware, it's > |> game over. > | > |Thank you. > ... > |The catch is that the "juicy" stuff is typically *in* the user's account > |on a single-user box... and therefore accessible without elevation if > |Mallory is hitting the client. > ... > > I have no idea of further gnupg internals, but OpenSSH since some > time "shield"s data in memory; ie the stuff gets encrypted -- only > short time decrypted -- when actually needed. Iirc this was > implemented as a countermeasure against side-channel exposures. > (Ie random key->checksum->used as key to encrypt key data; random > key and encrypted key ptrs stored side-by-side in memory.) For RSA at least, (and I think other public key cryptosystems) it is possible to "blind" the calculation such that side channels will leak a value dependent on both the private key and the random blinding factor; the latter changes with each operation, thus rendering any side channel that fails to leak the entire key in a single operation useless to an attacker. Efforts to implement blinding for all supported cryptosystems would probably be far better uses of available resources than playing side channel whack-a-mole. -- Jacob From jcb62281 at gmail.com Sun Jul 13 05:22:04 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sat, 12 Jul 2025 22:22:04 -0500 Subject: security model In-Reply-To: <9c583a3f-b42a-4a98-955a-f3dfd1543d37@sixdemonbag.org> References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> <9c583a3f-b42a-4a98-955a-f3dfd1543d37@sixdemonbag.org> Message-ID: <3e561996-df2b-4e75-9cc2-b5a4fe44a739@gmail.com> On 7/12/25 17:41, Robert J. Hansen wrote: >> Either you plan much farther ahead than the common cybercrook or we >> are talking about targeted attacks instead of the much common "spam" >> attacks.? (That said, GnuPG is *supposed* to stand up against >> targeted attacks.) > > Correct, I'm talking about targeted attacks. Random drive-bys are not > of much personal or professional concern. This is of course my risk > model, and I don't expect it to be relevant to anyone else. :) Both *should* be of concern, since a targeted attacker could certainly use "drive-by" techniques, both to evade detection and possibly your defenses, if you are so focused on targeted attacks that you miss something. >> The catch is that the "juicy" stuff is typically *in* the user's >> account on a single-user box... and therefore accessible without >> elevation if Mallory is hitting the client. > > If it's a single-user box, sure. Of course, many single-user boxes > make privilege escalation ridiculously easy, so why not? (Everyone who > has put NOPASSWD: ALL into their sudoers file, please raise your hands...) I just checked to make sure that is *not* in there...? (I would not be surprised to find that some distributions have it by default...) >> Why risk the exposure (and correction) of a privilege escalation >> exploit when everything Mallory wants is right there without it? > > Because even on single-user boxes, persistence and cleaning up one's > tracks is much easier done with escalation than without. If > persistence and concealment is part of the attack profile, you need > escalation. > >> In my model, Mallory's ideal goal is make off with your data and/or >> private keys and/or an unauthorized signature without leaving a trace >> aside from possible intentional tampering. > > Then Mallory needs escalation. If you're going to do things like look > through the system logs and scrub them appropriately, you need to > escalate. > > This is why I believe a competent Mallory always escalates. It's > simply not possible to do a thorough cleanup job without escalation. If Mallory only wants a smash-and-grab, then persistence is a needless risk.? Client exploits typically do *not* produce log entries in the first place, so there is nothing to clean up. In fact, log scrubbing might *be* an indicator of an intrusion: you full well that your browser crashed with SIGSEGV, where the hell is the segfault in the log? >> In that environment, a smartcard is not sufficient; you need an >> isolated box. > > Frankly, I think you need a lot more than a smartcard, too, starting > with a radical rethink of "why am I hosting such valuable files on a > machine connected to the internet?"? :) Consider the scenario of software release signing keys. Obviously the signature must reach a network-connected machine in order to publish it.? Mallory wants to sign a Trojan horse with your key.? You want to prevent that, or at least detect the intrusion immediately and announce that a spurious signature exists before Mallory can smear your good name. -- Jacob From rjh at sixdemonbag.org Sun Jul 13 05:42:00 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 12 Jul 2025 23:42:00 -0400 Subject: security model In-Reply-To: <3e561996-df2b-4e75-9cc2-b5a4fe44a739@gmail.com> References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> <9c583a3f-b42a-4a98-955a-f3dfd1543d37@sixdemonbag.org> <3e561996-df2b-4e75-9cc2-b5a4fe44a739@gmail.com> Message-ID: > Both *should* be of concern, since a targeted attacker could certainly > use "drive-by" techniques, both to evade detection and possibly your > defenses, if you are so focused on targeted attacks that you miss > something. Jacob, please don't tell me what should be of personal and professional concern to me. You don't know what my risk environment is. For all you know I'm part of a security operations center at their APT desk, and the drive-bys are handled by a different unit. All I said is: my area of personal and professional interest is in targeted attacks by people who know what they're doing. That said: yes, professionals and amateurs can run the same exploits. *Why* they are running the exploits, and their long-term goals in running the exploits, will differ. I'm having a hard time thinking of something that would justify a targeted attacker doing a low-skill smash and grab without persistence. If the haul is valuable enough to justify that, then isn't it also enough to do the job *well*, including keeping it under the radar and persisting? > If Mallory only wants a smash-and-grab... Professional Mallory doesn't want a smash-and-grab. Professional Mallory wants a haul. There's some trove of data that justifies the time, resources, and expense of Professional Mallory. If Professional Mallory has any choice in how to gain access, Professional Mallory will persist the access: because if this box has a top-flight haul today, who knows what it will have in six months? Professional Mallory persists. Count on it. > Client exploits typically do *not* produce log entries in the > first place, so there is nothing to clean up. Consider the simplest form of drive-by, the stolen credential. Are you telling me Mallory's connection and exfiltration aren't going to appear in SFTP logs? Or that these logs don't need scrubbing? -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun Jul 13 05:43:20 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 12 Jul 2025 23:43:20 -0400 Subject: security model In-Reply-To: References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> <20250712150907.puz6Nmlc@steffen%sdaoden.eu> Message-ID: <3ceec217-d8d1-48f3-9ca8-6861c3859395@sixdemonbag.org> > Efforts to implement blinding for all supported cryptosystems would > probably be far better uses of available resources than playing side > channel whack-a-mole. I strongly agree, for whatever it's worth. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Sun Jul 13 07:04:09 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 13 Jul 2025 00:04:09 -0500 Subject: security model In-Reply-To: References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> <9c583a3f-b42a-4a98-955a-f3dfd1543d37@sixdemonbag.org> <3e561996-df2b-4e75-9cc2-b5a4fe44a739@gmail.com> Message-ID: <340724dd-aac1-4e65-89b9-b3c0a5567c3d@gmail.com> On 7/12/25 22:42, Robert J. Hansen wrote: >> Both *should* be of concern, since a targeted attacker could >> certainly use "drive-by" techniques, both to evade detection and >> possibly your defenses, if you are so focused on targeted attacks >> that you miss something. > > Jacob, please don't tell me what should be of personal and > professional concern to me. > > You don't know what my risk environment is. For all you know I'm part > of a security operations center at their APT desk, and the drive-bys > are handled by a different unit. All I said is: my area of personal > and professional interest is in targeted attacks by people who know > what they're doing. Fair enough; my experience has all been on smaller scales.? I have never had "a different unit" that handled some of the problem.? That must be nice... > That said: yes, professionals and amateurs can run the same exploits. > *Why* they are running the exploits, and their long-term goals in > running the exploits, will differ. > > I'm having a hard time thinking of something that would justify a > targeted attacker doing a low-skill smash and grab without > persistence. If the haul is valuable enough to justify that, then > isn't it also enough to do the job *well*, including keeping it under > the radar and persisting? Persistence and evading detection are a tradeoff for the attacker. Further, Mallory may not have the goals you assume.? If Mallory is a professional, making the attack look like a low-skill smash and grab could, for example, be a strategy to avoid raising alarm at the targets that they *are* targets. >> If Mallory only wants a smash-and-grab... > > Professional Mallory doesn't want a smash-and-grab. > > Professional Mallory wants a haul. There's some trove of data that > justifies the time, resources, and expense of Professional Mallory. If > Professional Mallory has any choice in how to gain access, > Professional Mallory will persist the access: because if this box has > a top-flight haul today, who knows what it will have in six months? Logically, the box is most likely to have about the same, except that a second copy of the same haul is valueless to Mallory. Assuming Mallory is *not* trying to make a splash, keeping as quiet as possible reduces the chance of the victim realizing that tighter security is needed. In short, there is no amount of persistence that can save Mallory's access once the target becomes aware of it and gets serious about kicking Mallory out. I agree that many attackers still do not seem to understand this issue---the xz backdoor was discovered in part because of "Jia Tan" poorly balancing this tradeoff---but the attackers who *do* understand it are the ones I most worry about, precisely because of views like the one you are stating that assume they do not exist. > Professional Mallory persists. Count on it. That depends on the expected reliability of Professional Mallory's initial access.? (unless Mallory is really stupid...) If Mallory expects to get back in just as easily six months from now, why leave something that an attentive admin might notice (like "why are there two 'syslogd' files in /sbin?" or "why is /sbin/hwclock so small?") if that can be avoided because the Web app is a security dumpster fire running on a years-obsolete CakePHP version? (Those are actual examples from years ago at a past $WORK that is no longer in business, by the way.? The second "syslogd" was actually 'syslogd ' (note the space) and hwclock had been replaced with a shell script that launched a back door before running the real hwclock that had been hidden in /lib and disguised as a shared object.) >> Client exploits typically do *not* produce log entries in the first >> place, so there is nothing to clean up. > > Consider the simplest form of drive-by, the stolen credential. Are you > telling me Mallory's connection and exfiltration aren't going to > appear in SFTP logs? Or that these logs don't need scrubbing? Clients keep SFTP logs?? Are you assuming that Mallory steals the user's password and then connects to sshd on the user's box to make off with the user's files?? I would be more concerned about Mallory "cutting out the middleman" and simply making off with the user's files instead of bothering to leave an initial keylogger. (I am also not considering the case where the user is tricked into putting their system login credentials into a phishing page, admittedly.? I have never had to support users who were that naive.) I have been talking about attacks on clients, not servers, because GnuPG is most typically run on client nodes.? Indeed, as far as I know, the PGP security model is focused on clients---the boxes physically used by the users.? Servers are categorically untrusted in PGP. -- Jacob From rjh at sixdemonbag.org Sun Jul 13 07:36:28 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 13 Jul 2025 01:36:28 -0400 Subject: security model In-Reply-To: <340724dd-aac1-4e65-89b9-b3c0a5567c3d@gmail.com> References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> <9c583a3f-b42a-4a98-955a-f3dfd1543d37@sixdemonbag.org> <3e561996-df2b-4e75-9cc2-b5a4fe44a739@gmail.com> <340724dd-aac1-4e65-89b9-b3c0a5567c3d@gmail.com> Message-ID: > Fair enough; my experience has all been on smaller scales. I have > never had "a different unit" that handled some of the problem. That > must be nice... I was working in a DFIR lab environment where the company's attitude was, "you guys are responsible for any security threats that get past the rest of the corporate network and start knocking on your door." (I once delivered a lecture on new developments in mobile phone forensics and hooked up my personally-owned cellphone to show a data recovery feature. It was then I discovered a Chinese document on my phone which hadn't been there the night before: an attacker popped my phone and did an excellent job cleaning up and concealing the intrusion, but they forgot one file. The embarrassment of revealing to 100+ of your professional peers that your phone got popped the night before and you didn't notice will quickly teach you humility. :) ) > Persistence and evading detection are a tradeoff for the attacker. They are not. Often, evading detection assists in persistence by reducing the amount of evidence that might trigger a sysadmin's attention. If you mean to say persistence always increases the signature that must be concealed, there I'd mostly agree. > Further, Mallory may not have the goals you assume. If Mallory is a > professional, making the attack look like a low-skill smash and grab > could, for example, be a strategy to avoid raising alarm at the > targets that they *are* targets. I don't understand. Executing a successful high-profile exfiltration from a target which is sure to be spotted by the sysadmin ... avoids letting the sysadmin know they've been targeted? Targeted *by whom*, maybe. Changing TTP for misattribution purposes is definitely a thing. With that change, I agree. > Logically, the box is most likely to have about the same, except > that a second copy of the same haul is valueless to Mallory. Why should this be the default assumption? This is a computer, not a cuneiform tablet: data is added and removed constantly. If right now it has valuable data, it's at least as possible that in the future it will continue to receive valuable data. > In short, there is no amount of persistence that can save Mallory's > access once the target becomes aware of it and gets serious about > kicking Mallory out. Salt Typhoon would appear to be a counterexample. > If Mallory expects to get back in just as easily six months from > now, why leave something that an attentive admin might notice Great question (zero sarcasm). My answer would be, "in the example you give, the access is already a persistent access, so the persistency objective is already done for Mallory by the negligence of the sysadmin." > Clients keep SFTP logs? Are you assuming that Mallory steals the > user's password and then connects to sshd on the user's box to make > off with the user's files? Remote access, yes. > I have been talking about attacks on clients, not servers, because > GnuPG is most typically run on client nodes. Indeed, as far as I > know, the PGP security model is focused on clients---the boxes > physically used by the users. Servers are categorically untrusted > in PGP. In today's environment, you have to work really hard to even have a meaningful network perimeter. I'm unconvinced it makes much sense nowadays to talk about clean client/server distinctions at the machine level. At the app level, maybe. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From jcb62281 at gmail.com Mon Jul 14 02:03:48 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 13 Jul 2025 19:03:48 -0500 Subject: security model In-Reply-To: References: <28b1c390-60c3-4a8b-92c8-331f7f757d0c@gmail.com> <7F63A41F-4CE8-4810-9C12-612016AE5C4F@andrewg.com> <9c583a3f-b42a-4a98-955a-f3dfd1543d37@sixdemonbag.org> <3e561996-df2b-4e75-9cc2-b5a4fe44a739@gmail.com> <340724dd-aac1-4e65-89b9-b3c0a5567c3d@gmail.com> Message-ID: On 7/13/25 00:36, Robert J. Hansen wrote: > [...] >> Persistence and evading detection are a tradeoff for the attacker. > > They are not. Often, evading detection assists in persistence by > reducing the amount of evidence that might trigger a sysadmin's > attention. > > If you mean to say persistence always increases the signature that must > be concealed, there I'd mostly agree. That is the tradeoff I was referring to:? tampering the system to enable or improve persistence leaves artifacts for the sysadmin to discover. >> Further, Mallory may not have the goals you assume.? If Mallory is a >> professional, making the attack look like a low-skill smash and grab >> could, for example, be a strategy to avoid raising alarm at the >> targets that they *are* targets. > > I don't understand. Executing a successful high-profile exfiltration > from a target which is sure to be spotted by the sysadmin ... avoids > letting the sysadmin know they've been targeted? > > Targeted *by whom*, maybe. Changing TTP for misattribution purposes is > definitely a thing. With that change, I agree. That is more-or-less what I was saying:? if it looks like an opportunistic attack, the target is less likely to expect a repeat performance.? While any half-competent sysadmin is going to treat the incident as a wake-up call to tighten security, getting management to agree without evidence of an ongoing threat can be difficult. Therefore, Professional Mallory can benefit from making a targeted attack *look* like an opportunistic attack. >> Logically, the box is most likely to have about the same, except that >> a second copy of the same haul is valueless to Mallory. > > Why should this be the default assumption? This is a computer, not a > cuneiform tablet: data is added and removed constantly. If right now it > has valuable data, it's at least as possible that in the future it will > continue to receive valuable data. Not entirely the same, but the question I was getting towards is "how much additional value will Mallory expect from hitting the same target again in six months?"? Now, if the cost of coming back in six months is basically nil, Mallory's cost-benefit calculation is skewed accordingly and you can expect a return even if there is unlikely to be new data. >> In short, there is no amount of persistence that can save Mallory's >> access once the target becomes aware of it and gets serious about >> kicking Mallory out. > > Salt Typhoon would appear to be a counterexample. As far as I can tell, Salt Typhoon reliably gets kicked out; they just keep finding new targets and/or pulling off new intrusions. (I consider "backdoor found; backdoor removed" to be "Mallory kicked out" although that does *not* preclude Mallory from finding another way in... perhaps the same way that backdoor had been planted...) Salt Typhoon/GhostEmperor is also an example of why I would not expect logs to exist in the first place.? While they *do* escalate (and how), the remote filesystem access is provided by their malware instead of using system facilities that would keep logs. Malware executing in an unprivileged context could do the same with the user's files. >> If Mallory expects to get back in just as easily six months from now, >> why leave something that an attentive admin might notice > > Great question (zero sarcasm). My answer would be, "in the example you > give, the access is already a persistent access, so the persistency > objective is already done for Mallory by the negligence of the sysadmin." Or reluctance by management to allocate needed resources---apparently that server had been getting hit repeatedly since before I worked there.? I was explicitly told to *not* bother tracing how the IRC bot had gotten in, just remove it and consider the box secured.? 8-( >> Clients keep SFTP logs?? Are you assuming that Mallory steals the >> user's password and then connects to sshd on the user's box to make >> off with the user's files? > > Remote access, yes. > >> I have been talking about attacks on clients, not servers, because >> GnuPG is most typically run on client nodes.? Indeed, as far as I >> know, the PGP security model is focused on clients---the boxes >> physically used by the users. Servers are categorically untrusted in >> PGP. > > In today's environment, you have to work really hard to even have a > meaningful network perimeter. I'm unconvinced it makes much sense > nowadays to talk about clean client/server distinctions at the machine > level. At the app level, maybe. I agree that there is a serious problem with loose default configurations.? In particular, a box used with keyboard and local display probably should not be running sshd, but it seems that most distributions enable sshd by default. In other words, on my "client" boxes, there are no SFTP logs because there is no SFTP listener.? Mallory cannot exploit a service that is not running.? :-D -- Jacob From wk at gnupg.org Mon Jul 14 14:12:19 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Jul 2025 14:12:19 +0200 Subject: [Announce] GnuPG 2.5.9 released Message-ID: <875xfvynrw.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release. Version 2.5.9 which will soon lead us to the new stable 2.6 series. This release mostly fixes regression in the previous releases. The main features in the 2.6 series are improvements for 64 bit Windows and the introduction of Kyber (ML-KEM, FIPS-203) as PQC encryption algorithm. Other than PQC support the 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries. Please be aware that the 2.4 series will reach end of life in June next of year. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.5.9 (2025-07-10) ================================================ [compared to version 2.5.8] * gpg: Add the revocation reason to the sigclass of a "rev" line. Regression in 2.5.7. [T7073] * gpg: Do not show the non-standard secp256k1 curve in the menu to select the curve. It can however be specified using its name. [rG49a9171f63] * gpg: Fix regression in using the secp256k1 curve. [T7698] * dirmngr: New option --user-agent and send a default User-Agent of "GnuPG/2.6" for all HTTP requests. [T7715] Release-info: https://dev.gnupg.org/T7695 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary file server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.9.tar.bz2 (8015k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.9.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.9_20250710.exe (5521k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.9_20250710.exe.sig The source used to build this installer for 64-bit Windows is available as https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.9_20250710.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.9_20250710.tar.xz.sig This source tarball may also be used to download all required libraries at once to build a Unix version on any modern system. See the included README. Debian Packages =============== For the first time we now provide Debian style packages for a couple of Debian variants. See https://repos.gnupg.org/deb/gnupg/bookworm-devel/ or use the menu to switch to other distros/releases. If you encounter packaging problems please report them to the gnupg-devel mailing list. Windows Installer ================= A new *Beta* version of Gpg4win, our full featured Windows installer including this version of GnuPG as well as the Kleopatra GUI and a PDF has also been released. See https://gpg4win.org/version5.html Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.5.9.tar.bz2 you would use this command: gpg --verify gnupg-2.5.9.tar.bz2.sig gnupg-2.5.9.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.5.9.tar.bz2, you run the command like this: sha1sum gnupg-2.5.9.tar.bz2 and check that the output matches the next line: 701bd8fe8789a86cd2b7c27254a2ab837ee4fcfa gnupg-2.5.9.tar.bz2 1209dd1dc3cb9e33e3c7857e7f10a7b0fc8d478e gnupg-w32-2.5.9_20250710.tar.xz 0c7814a9ed67c48d0498f42f5a0eeaaf18e29f49 gnupg-w32-2.5.9_20250710.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T7695 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. A team of full-time employed developers and contractors are working exclusively on GnuPG and related software like Libgcrypt, GPGME, Kleopatra, Okular, and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. * List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: ed25519 2020-08-24 [SC] [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [SC] [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) rsa3072 2025-05-09 [SC] [expires: 2033-03-03] 3B76 1AE4 E63B F351 9CE7 D63B ECB6 64CB E133 2EEF Alexander Kulbartsch (GnuPG Release Key) brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. * Debian Package Signing Key: The new Debian style packages are signed using this key: ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the key. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Mon Jul 14 16:09:11 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Jul 2025 16:09:11 +0200 Subject: [PATCH gnupg v15] Disable CPU speculation-related misfeatures In-Reply-To: <1752178072.6844.3.camel@trentalancia.com> (Guido Trentalancia's message of "Thu, 10 Jul 2025 22:07:52 +0200") References: <1748260854.1126.8.camel@trentalancia.com> <1751021219.6405.6.camel@trentalancia.com> <87cyah91ov.fsf@jacob.g10code.de> <1751637649.6137.2.camel@trentalancia.com> <1751814607.10569.5.camel@trentalancia.com> <1751831452.25372.4.camel@trentalancia.com> <875xg42c1o.fsf@jacob.g10code.de> <1751908674.7090.8.camel@trentalancia.com> <1751972700.857.4.camel@trentalancia.com> <1751983558.11004.3.camel@trentalancia.com> <1751991996.6941.1.camel@trentalancia.com> <1752003509.25437.3.camel@trentalancia.com> <1752063768.6141.10.camel@trentalancia.com> <1752144099.6327.12.camel@trentalancia.com> <87v7o0yyih.fsf@jacob.g10code.de> <1752160467.6168.33.camel@trentalancia.com> <1752178072.6844.3.camel@trentalancia.com> Message-ID: <87ple2yid4.fsf@jacob.g10code.de> Hi! I was about to apply the patch with additionl configure option but I now noticed that: > + gnupg_sleep (1); This is a no-go: It would drop performance too hard. We often call a dozen gpg processes per second and having each one to last at least a second decreases application performance in an inaccepatble way and, rightfully, user will report a bug. Doing this in the gpg-agent _might_ acceptable (because it is a long lasting process). For gpg, gpgconf, gpgsm, gpg-connect-agent, gpg-check-pattern it is a no-go. Did you actually tried to use gnupg in a real world application (reading and sending mails to several recipients, or browsing a list of signed mails)? What about codumenting your effort and providing a patch, so that ppl can apply it if they feeel they need it? Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From Andreas.Stieger at gmx.de Thu Jul 17 23:40:20 2025 From: Andreas.Stieger at gmx.de (Andreas Stieger) Date: Thu, 17 Jul 2025 23:40:20 +0200 Subject: [PATCH gpa] fix implicit declaration of gpa_keytable_ensure Message-ID: * src/cm-piv.c: fix implicit declaration of gpa_keytable_ensure Index: gpa-0.11.0/src/cm-piv.c =================================================================== --- gpa-0.11.0.orig/src/cm-piv.c +++ gpa-0.11.0/src/cm-piv.c @@ -41,6 +41,7 @@ ?#include "gtktools.h" ?#include "convert.h" ?#include "gpa-key-details.h" +#include "keytable.h" ?#include "cm-object.h" ?#include "cm-piv.h" From wk at gnupg.org Fri Jul 18 10:22:18 2025 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Jul 2025 10:22:18 +0200 Subject: [PATCH gpa] fix implicit declaration of gpa_keytable_ensure In-Reply-To: (Andreas Stieger via Gnupg-devel's message of "Thu, 17 Jul 2025 23:40:20 +0200") References: Message-ID: <878qklx611.fsf@jacob.g10code.de> On Thu, 17 Jul 2025 23:40, Andreas Stieger said: > * src/cm-piv.c: fix implicit declaration of gpa_keytable_ensure Thanks. I applied your fix and also made GPA compile with GPGME 2.x Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From bjk at luxsci.net Sat Jul 19 03:04:07 2025 From: bjk at luxsci.net (Ben Kibbey) Date: Fri, 18 Jul 2025 18:04:07 -0700 Subject: [PATCH Libgpg-error] Add Android support for cross-compilation. Message-ID: <1752887050-230095.020040723.f56J1485g2765381@rs6161.luxsci.com> Hi all, Wanted to be sure this wouldn't break anything and is the better option rather than adding the lock-obj-pub to syscfg. diff --git a/configure.ac b/configure.ac index 83a52a4..55e881d 100644 --- a/configure.ac +++ b/configure.ac @@ -633,7 +633,7 @@ if test x"$gl_use_threads" = xno; then AC_MSG_NOTICE([generated src/lock-obj-pub.native.h for $host]) elif test x$cross_compiling = xyes; then case $host in - *-*-gnu* | *-*-linux-gnu* | *-*-linux-musl*) + *-*-gnu* | *-*-linux-gnu* | *-*-linux-musl* | *linux-androideabi*) AC_CHECK_TOOL(OBJDUMP, [objdump]) if test -n "$OBJDUMP"; then lock_obj_h_generated=yes -- Ben Kibbey From pierre.labastie at neuf.fr Mon Jul 28 11:23:59 2025 From: pierre.labastie at neuf.fr (Pierre Labastie) Date: Mon, 28 Jul 2025 11:23:59 +0200 Subject: [Bug report] [gpgme]: build may fail if gnupg is not installed Message-ID: <9470dbbf01eefe2477237a90f767aa5db0d0af7c.camel@neuf.fr> Dear developers, I'm one of the editors of the "linux from scratch" project. I'm sorry if this is duplicate, but a search for "gpgme build fail" didn't lead to anything similar to the following: When building gpgme, the presence of gnupg on the system is not tested, but the build fails if it is not installed, when trying to execute: $(TESTS_ENVIRONMENT) $(GPG) --batch --no-permission-warning \ --import $(top_srcdir)/tests/gpg/pubdemo.asc in tests/gpg/Makefile.am. There is an obvious workaround, which is to pass "--disable-gpg-test" to configure, but this is nowhere documented. Some similar instructions using gpg ($(GPG)) have a "-" at the beginning, which prevents the build from failing (the error is "ignored"), but not all such instructions. Shouldn't all the instructions using gpg be protected similarly? It seems the "-" was removed at commit a5b040cc57c, without anything in the commit message explaining why (this may have been discussed elsewhere then, I have not checked). So it may just be an accidental removal... If you need me to send a patch, I can do that. Regards Pierre From devm23k73ju29h3r at dolce-energy.com Mon Jul 28 22:02:49 2025 From: devm23k73ju29h3r at dolce-energy.com (JL) Date: Mon, 28 Jul 2025 22:02:49 +0200 Subject: 8bit mime support? (linked to thunderbird issue) Message-ID: Hi, I wanted to open a ticket on GPGME because thunderbird team says they can't encode email using 8bit mime because of GPGME not handling correctly 8 bit content https://bugzilla.mozilla.org/show_bug.cgi?id=1966019 8bit RFC is 30 year old, using base64 to "keep compatibility with old not maintained server/client" is energy/storage/network inefficient. the thunderbird teams introduce workaround instead of working with GPG team to have the issue fixed.... seems that non gpg email are 8bit mime on thunderbird for the main message, base64 for the attachements would be nice to have the issue fixed so that base64 mime could be dropped, but don't know what is the issue they faced... maybe someone can participate on the thunderbird ticket so that the subject can go on? thanks and regards From steffen at sdaoden.eu Mon Jul 28 23:59:19 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 28 Jul 2025 23:59:19 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: References: Message-ID: <20250728215919.fPT7hycU@steffen%sdaoden.eu> JL wrote in : |I wanted to open a ticket on GPGME because thunderbird team says they |can't encode email using 8bit mime because of GPGME not handling |correctly 8 bit content | |https://bugzilla.mozilla.org/show_bug.cgi?id=1966019 | |8bit RFC is 30 year old, using base64 to "keep compatibility with old |not maintained server/client" is energy/storage/network inefficient. 8bit brings you nowhere because of line endings for example, which must be normalized. This cannot be expressed in 8-bit. Also, during fly, for example mailing-lists, message reencodings happen. (For example Mantis seems to enforce 8-bit *at times*, mailman(2) is notorious for base64.) Sometimes you need to use encoding anyway, for example overlong lines, ^From_ lines (really SHOULD), control characters... So content-transfer-encodings like base64 and quoted-printable will not go away in the future, no matter what. The question to me is why it disturbs you in practice, beyond a possible mind itching -- the latter i can understand, but actually, over time, turned into a complete SMTPUTF8 and other such stuff well heavy disliker. (I concur that Unicode for email local-part's must be done somehow, but that is it; and message/global definetely not, for me.) My reasoning finally was and is that the email content representation can never be an end-user thing, despite sensational representations during engineer congresses. The email headers become a more and more crowded mess (look for example out Outlook.com header content), and certain parts of the actual content will also always require "utilities" (image etc viewer). So in fact there is nothing plain text except for possibly (and lesser and lesser so) a single text/plain part. And for that alone, why all the hassle? If you look at the email in a MUA, you will see the content as desired, if you store the part somewhere on the disk it will have been converted also. I presume all that, say. So why does it have to be 8-bit? |the thunderbird teams introduce workaround instead of working with GPG |team to have the issue fixed.... seems that non gpg email are 8bit mime |on thunderbird for the main message, base64 for the attachements | |would be nice to have the issue fixed so that base64 mime could be |dropped, but don't know what is the issue they faced... maybe someone |can participate on the thunderbird ticket so that the subject can go on? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From devm23k73ju29h3r at dolce-energy.com Tue Jul 29 09:47:39 2025 From: devm23k73ju29h3r at dolce-energy.com (JL) Date: Tue, 29 Jul 2025 09:47:39 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <20250728215919.fPT7hycU@steffen%sdaoden.eu> References: <20250728215919.fPT7hycU@steffen%sdaoden.eu> Message-ID: <5f128210-e6f3-40a5-af14-3547769edc8f@dolce-energy.com> Hi, replying inline Le 28/07/2025 ? 23:59, Steffen Nurpmeso a ?crit?: > JL wrote in > : > |I wanted to open a ticket on GPGME because thunderbird team says they > |can't encode email using 8bit mime because of GPGME not handling > |correctly 8 bit content > | > |https://bugzilla.mozilla.org/show_bug.cgi?id=1966019 > | > |8bit RFC is 30 year old, using base64 to "keep compatibility with old > |not maintained server/client" is energy/storage/network inefficient. > > 8bit brings you nowhere because of line endings for example, which > must be normalized. This cannot be expressed in 8-bit. ah... so '\n', '\r' and '\r\n' are not 8 bit on my text files ;). There is no need to "normalize" because after all it's only 8bit wide or aligned (see later for 7bits) > Also, during fly, for example mailing-lists, message reencodings > happen. (For example Mantis seems to enforce 8-bit *at times*, > mailman(2) is notorious for base64.) don?t care if some stupid software have bandwidth to loose... as long it's not mine. If a SA is old enough and don't care about it's storage to still use mailman and enforce base64... well, fine, but it has to worry about security of it's server... because a software that enforce base64 just to "correct" some bug (afterall, base64 was only created to go through 7bit servers) > Sometimes you need to use encoding anyway, for example overlong > lines, ^From_ lines (really SHOULD), control characters... > So content-transfer-encodings like base64 and quoted-printable > will not go away in the future, no matter what. > > > The question to me is why it disturbs you in practice, beyond > a possible mind itching -- the latter i can understand, but > actually, over time, turned into a complete SMTPUTF8 and other > such stuff well heavy disliker. > (I concur that Unicode for email local-part's must be done > somehow, but that is it; and message/global definetely not, for > me.) because I've work duties, and amongst them, be sure that I've proof that the documents where not modified and that I sent the documents to the clients, such documents takes spaces and are base64 encoded with NO REASON because they are BINARY, that the header have some base64, well fine, the overhead won't be too much because the content is small, but because of some gpgme bug, thunderbird enforce base64 and then even on binary content. If the message is sent unsigned, without GPG, then the 8bitMime is used it distrub me in practice because * local stored emails are taking much more space in base64, * because I often have to keep the same data in multiple format : original on disk, to be able to access it, one copy on disk in eml format for legal purpose, in "source format" also..... this takes lot of space, if you add the base64 overhead... it count in GB overhead for... nothing... * that it consume network data, that I've limited data (I use cellphone sharing, because I move a lot and can't have an fixed point connection) * that I often have to split the message into part, and the base64 makes more parts because of it's overhead, so it create more work * because I can't use "cloud" storage, because they are not legal proof. (not mentionning the fact that I've to keep the data on the network drive for 10 years, that it'll be accessed once, and that it have to have a 24/24 7/7 power consumption and instant storage access for something that can stay on a backup mass storage.... and that MIGHT be asked) * and it distrub me because thunderbird has to change 8bit mime to base64 just because of some gpg bug... > > My reasoning finally was and is that the email content > representation can never be an end-user thing, despite > sensational representations during engineer congresses. > The email headers become a more and more crowded mess (look for > example out Outlook.com header content), and certain parts of the > actual content will also always require "utilities" (image etc > viewer). > So in fact there is nothing plain text except for possibly (and > lesser and lesser so) a single text/plain part. > And for that alone, why all the hassle? because 8bit mime, is not for plaintext... it's, as the 'MIME' says, attachement, and attachements are... 8bit data, not "text" > > If you look at the email in a MUA, you will see the content as > desired, if you store the part somewhere on the disk it will have > been converted also. I presume all that, say. you presume, because in fact, the clients are just transfering the eml as is, store them as is, and just be able to handle all the cases, like a text editor handle '\r\n' dos endofline, '\n' unix endofline... they just "detect" what is used, decode them. > > So why does it have to be 8-bit? because all what you said, is somewhat false, even headers could be 8 bit without issue, keeping appart some stupid unmaintained MTA/client/webmail that rely on some old RFC. WHY? because the data transfered on network is 8bit boundary, 7bit was already not so widely used when I first used my dad computer 38 years ago, and there was no internet at this time in France, 4 years latter when 14,4kbps modem appeared, it was already 8bit ....? ok there was at this time some 7bit (already old) computers... and ebdict IBM "supercomputer".... are they still working? doubt it... so why do we still ENFORCE 7bit ascii for something that is no-where more used? do you know a single 7bit CPU still there????? if you can handle 8bits, you can handle 7bits... so leave the oldies rest in peace and move forward. base64, 7bit ascii, EBDICT, base32... quoted printable... are just oldies... they had their use, they are now just no more needed and belongs to history... you still use the old 5"1/4 floppy disk? now it's just energy inefficient, storage inefficient, network inefficient... and like keeping able to speek with a 1rst century english people... it's fun to read and not understand, but... it's no use best regards > > |the thunderbird teams introduce workaround instead of working with GPG > |team to have the issue fixed.... seems that non gpg email are 8bit mime > |on thunderbird for the main message, base64 for the attachements > | > |would be nice to have the issue fixed so that base64 mime could be > |dropped, but don't know what is the issue they faced... maybe someone > |can participate on the thunderbird ticket so that the subject can go on? > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > | > |During summer's humble, here's David Leonard's grumble > | > |The black bear, The black bear, > |blithely holds his own holds himself at leisure > |beating it, up and down tossing over his ups and downs with pleasure > | > |Farewell, dear collar bear > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Jul 29 18:33:43 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 29 Jul 2025 18:33:43 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <5f128210-e6f3-40a5-af14-3547769edc8f@dolce-energy.com> References: <20250728215919.fPT7hycU@steffen%sdaoden.eu> <5f128210-e6f3-40a5-af14-3547769edc8f@dolce-energy.com> Message-ID: <20250729163343.vhb0POXw@steffen%sdaoden.eu> bonjour, JL wrote in <5f128210-e6f3-40a5-af14-3547769edc8f at dolce-energy.com>: |Le 28/07/2025 ? 23:59, Steffen Nurpmeso a ?crit?: |> JL wrote in |> : |>|I wanted to open a ticket on GPGME because thunderbird team says they |>|can't encode email using 8bit mime because of GPGME not handling |>|correctly 8 bit content |>| |>|https://bugzilla.mozilla.org/show_bug.cgi?id=1966019 |>| |>|8bit RFC is 30 year old, using base64 to "keep compatibility with old |>|not maintained server/client" is energy/storage/network inefficient. |> |> 8bit brings you nowhere because of line endings for example, which |> must be normalized. This cannot be expressed in 8-bit. |ah... so '\n', '\r' and '\r\n' are not 8 bit on my text files ;). There |is no need to "normalize" because after all it's only 8bit wide or |aligned (see later for 7bits) |> Also, during fly, for example mailing-lists, message reencodings |> happen. (For example Mantis seems to enforce 8-bit *at times*, |> mailman(2) is notorious for base64.) |don?t care if some stupid software have bandwidth to loose... as long |it's not mine. If a SA is old enough and don't care about it's storage |to still use mailman and enforce base64... well, fine, but it has to |worry about security of it's server... because a software that enforce |base64 just to "correct" some bug (afterall, base64 was only created to |go through 7bit servers) |> Sometimes you need to use encoding anyway, for example overlong |> lines, ^From_ lines (really SHOULD), control characters... |> So content-transfer-encodings like base64 and quoted-printable |> will not go away in the future, no matter what. |> |> |> The question to me is why it disturbs you in practice, beyond |> a possible mind itching -- the latter i can understand, but |> actually, over time, turned into a complete SMTPUTF8 and other |> such stuff well heavy disliker. |> (I concur that Unicode for email local-part's must be done |> somehow, but that is it; and message/global definetely not, for |> me.) | |because I've work duties, and amongst them, be sure that I've proof that |the documents where not modified and that I sent the documents to the |clients, such documents takes spaces and are base64 encoded with NO |REASON because they are BINARY, | |that the header have some base64, well fine, the overhead won't be too |much because the content is small, but because of some gpgme bug, |thunderbird enforce base64 and then even on binary content. If the |message is sent unsigned, without GPG, then the 8bitMime is used | |it distrub me in practice because | | * local stored emails are taking much more space in base64, | * because I often have to keep the same data in multiple format : | original on disk, to be able to access it, one copy on disk in eml | format for legal purpose, in "source format" also..... this takes | lot of space, if you add the base64 overhead... it count in GB | overhead for... nothing... | * that it consume network data, that I've limited data (I use | cellphone sharing, because I move a lot and can't have an fixed | point connection) | * that I often have to split the message into part, and the base64 | makes more parts because of it's overhead, so it create more work | * because I can't use "cloud" storage, because they are not legal | proof. (not mentionning the fact that I've to keep the data on the | network drive for 10 years, that it'll be accessed once, and that it | have to have a 24/24 7/7 power consumption and instant storage | access for something that can stay on a backup mass storage.... and | that MIGHT be asked) | * and it distrub me because thunderbird has to change 8bit mime to | base64 just because of some gpg bug... | |> My reasoning finally was and is that the email content |> representation can never be an end-user thing, despite |> sensational representations during engineer congresses. |> The email headers become a more and more crowded mess (look for |> example out Outlook.com header content), and certain parts of the |> actual content will also always require "utilities" (image etc |> viewer). |> So in fact there is nothing plain text except for possibly (and |> lesser and lesser so) a single text/plain part. |> And for that alone, why all the hassle? |because 8bit mime, is not for plaintext... it's, as the 'MIME' says, |attachement, and attachements are... 8bit data, not "text" I see you meant it "beyond GPG", but in general. Here: as above, certain characters are not allowed in email protocols, and, as far as i see that, i do not think that will change. So "anything binary", it will need an encoding. |> If you look at the email in a MUA, you will see the content as |> desired, if you store the part somewhere on the disk it will have |> been converted also. I presume all that, say. |you presume, because in fact, the clients are just transfering the eml |as is, store them as is, and just be able to handle all the cases, like |a text editor handle '\r\n' dos endofline, '\n' unix endofline... they |just "detect" what is used, decode them. |> |> So why does it have to be 8-bit? | |because all what you said, is somewhat false, even headers could be 8 |bit without issue, keeping appart some stupid unmaintained |MTA/client/webmail that rely on some old RFC. | |WHY? because the data transfered on network is 8bit boundary, 7bit was |already not so widely used when I first used my dad computer 38 years |ago, and there was no internet at this time in France, 4 years latter |when 14,4kbps modem appeared, it was already 8bit ....? ok there was at |this time some 7bit (already old) computers... and ebdict IBM |"supercomputer".... are they still working? doubt it... Fun fact. The MUA i maintain still sends (in the released version) anything 8-bit over SMTP .. without using the according SMTP extension. It does so for way over twenty years, and the program was a bit famous by then (long before i took maintainership). I never saw nor heard complaints. |so why do we still ENFORCE 7bit ascii for something that is no-where |more used? do you know a single 7bit CPU still there????? | |if you can handle 8bits, you can handle 7bits... so leave the oldies |rest in peace and move forward. | |base64, 7bit ascii, EBDICT, base32... quoted printable... are just |oldies... they had their use, they are now just no more needed and |belongs to history... you still use the old 5"1/4 floppy disk? Certain people do the latter. And i think you overcomplain a bit, because for example the terrible but omnipresent XML and JSON do not support the full spectrum too, you need a different kind of encoding to pass data through them. (There are certain SMTP extensions to send binary data though.) As i love (an unconstrained) email i find it unfair to only complain on the very old (and misused) lady email, when those "new" protocols/formats fail to deliver what you want? |now it's just energy inefficient, storage inefficient, network |inefficient... and like keeping able to speek with a 1rst century |english people... it's fun to read and not understand, but... it's no use I know such wall hammerings. I will have no remaining intellectual teeths when i die, and it could be i end with only "More Light!", in famous company thus. |best regards Ciao, |>|the thunderbird teams introduce workaround instead of working with GPG |>|team to have the issue fixed.... seems that non gpg email are 8bit mime |>|on thunderbird for the main message, base64 for the attachements |>| |>|would be nice to have the issue fixed so that base64 mime could be |>|dropped, but don't know what is the issue they faced... maybe someone |>|can participate on the thunderbird ticket so that the subject can go on? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear From rjh at sixdemonbag.org Tue Jul 29 23:10:36 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 29 Jul 2025 17:10:36 -0400 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <5f128210-e6f3-40a5-af14-3547769edc8f@dolce-energy.com> References: <20250728215919.fPT7hycU@steffen%sdaoden.eu> <5f128210-e6f3-40a5-af14-3547769edc8f@dolce-energy.com> Message-ID: <1adacefc-5d3e-4c6d-8021-e4c5c92dd910@sixdemonbag.org> > don?t care if some stupid software have bandwidth to loose... The cold reality is there exists antique software and obsolete workflows, and the moment new software starts breaking them do you know who gets blamed? The new software's maintainer who is doing things the right way. PGP 2.6 dates from 1991, has been obsolete for 30 years at this point, has long been eclipsed by multiple generations of newer standards (RFC2440, RFC2440bis, RFC4880, RFC4880bis, now LibrePGP), but GnuPG still supports it because whenever Werner even makes noise about ending PGP 2.6 support there's a sea of people screaming. RFCs 2015 and 3156 are *the only* standards for using OpenPGP in email: inline-PGP was never a standard and always had deep faults. But as the former FAQ maintainer, let me tell you the most obnoxious emails I received were from people outraged the FAQ changed to officially bless RFC-conformant emails and advise against inline-PGP. And this was over a *documentation change*. I'm glad your software and workflow supports the latest and greatest. I really am. I wish more people did. But they don't, and that's why maintainers have to support old and broken behaviors, even at the cost of some bandwidth. > so why do we still ENFORCE 7bit ascii for something that is no-where > more used? do you know a single 7bit CPU still there????? For quite some time PGP-Basics, a Yahoo! Groups mailing list devoted to helping newbies learn OpenPGP, could not support PGP/MIME because Y!Gs mailing list software insisted on munging text attachments. So yeah, old and broken things still exist everywhere. > base64, 7bit ascii, EBDICT, base32... quoted printable... are just > oldies... they had their use, they are now just no more needed and > belongs to history... you still use the old 5"1/4 floppy disk? Friend, the United States nuclear arsenal runs on 8" floppies. No, I'm not kidding. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From devm23k73ju29h3r at dolce-energy.com Wed Jul 30 00:42:36 2025 From: devm23k73ju29h3r at dolce-energy.com (JL) Date: Wed, 30 Jul 2025 00:42:36 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <1adacefc-5d3e-4c6d-8021-e4c5c92dd910@sixdemonbag.org> References: <20250728215919.fPT7hycU@steffen%sdaoden.eu> <5f128210-e6f3-40a5-af14-3547769edc8f@dolce-energy.com> <1adacefc-5d3e-4c6d-8021-e4c5c92dd910@sixdemonbag.org> Message-ID: Le 29/07/2025 ? 23:10, Robert J. Hansen via Gnupg-devel a ?crit?: >> don?t care if some stupid software have bandwidth to loose... > > The cold reality is there exists antique software and obsolete > workflows, and the moment new software starts breaking them do you > know who gets blamed? The new software's maintainer who is doing > things the right way. > > PGP 2.6 dates from 1991, has been obsolete for 30 years at this point, > has long been eclipsed by multiple generations of newer standards > (RFC2440, RFC2440bis, RFC4880, RFC4880bis, now LibrePGP), but GnuPG > still supports it because whenever Werner even makes noise about > ending PGP 2.6 support there's a sea of people screaming. > > RFCs 2015 and 3156 are *the only* standards for using OpenPGP in > email: inline-PGP was never a standard and always had deep faults. But > as the former FAQ maintainer, let me tell you the most obnoxious > emails I received were from people outraged the FAQ changed to > officially bless RFC-conformant emails and advise against inline-PGP. > > And this was over a *documentation change*. > > I'm glad your software and workflow supports the latest and greatest. > I really am. I wish more people did. > > But they don't, and that's why maintainers have to support old and > broken behaviors, even at the cost of some bandwidth. yes but that don't means that because of some GPG bug, I can't send 8bit MIME attachment in a signed message.... Yes there will always be people that fear to change, scream, yell, when you touch a single bit of a 10TB file... ok... I don't care speaking with them... if you never move forward because people are stupid, you'll never move forward, because the only 2 things that might be infinite is the universe and stupidity... you know how the things advance? by ignoring the one that yell and scream, you just make it, activate it by default... and they don't even notice that they are using it! don't say "put an end" : once nobody use it, they will move. I'm sure that theses people didn't even noticed that they get UTF-8 encoded emails... Sadely, because people are listening to theses people, most people are dropping emails to go on whatsapp... NICE! because nobody move, people says "I can't send a video by email, so I now use whatsapp, I don't care if it's proprietary, closed, fake privacy, and a jail, I can send my video!" so... if people get scrambled emails, because they use obsolete software, they surely not speak with lot of people, because I doubt their software will display a utf-8 smiley.... if people can't read, I just say "well, you're email client is too old... it don't meet today standards" and that's it... I move... if they finish by having 90% of their contacts says the same, they will finish to move. You have to support oldies, that don?t means that you have to make oldies the default.... > >> so why do we still ENFORCE 7bit ascii for something that is no-where >> more used? do you know a single 7bit CPU still there????? > > For quite some time PGP-Basics, a Yahoo! Groups mailing list devoted > to helping newbies learn OpenPGP, could not support PGP/MIME because > Y!Gs mailing list software insisted on munging text attachments. So > yeah, old and broken things still exist everywhere. and there are lot of other free/open source mailing list provider... so they just had to move... that's always the same.... you know why whatsapp is so popular? because it's stupid people that force other to use it... so since you don't want to go out of the "circle" you end giving up... and the decadence is there. I don't remember who said that you don't have to blame the 10% bad people, but the 90% good people that let them do. > >> base64, 7bit ascii, EBDICT, base32... quoted printable... are just >> oldies... they had their use, they are now just no more needed and >> belongs to history... you still use the old 5"1/4 floppy disk? > > Friend, the United States nuclear arsenal runs on 8" floppies. > > No, I'm not kidding. well, they will have thought times.... I wonder how their arsenal will respond to some sub-sonic nuclear weapon... surely... they will have their 8" floppy inserted the time the other knock the door... From devm23k73ju29h3r at dolce-energy.com Wed Jul 30 01:07:54 2025 From: devm23k73ju29h3r at dolce-energy.com (JL) Date: Wed, 30 Jul 2025 01:07:54 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <20250729163343.vhb0POXw@steffen%sdaoden.eu> References: <20250728215919.fPT7hycU@steffen%sdaoden.eu> <5f128210-e6f3-40a5-af14-3547769edc8f@dolce-energy.com> <20250729163343.vhb0POXw@steffen%sdaoden.eu> Message-ID: Le 29/07/2025 ? 18:33, Steffen Nurpmeso a ?crit?: > bonjour, :) Buona notte, > > > > I see you meant it "beyond GPG", but in general. > Here: as above, certain characters are not allowed in email > protocols, and, as far as i see that, i do not think that will > change. So "anything binary", it will need an encoding. there is a difference between a 33%-37% overhead because ALL is encoded, and 2 to 10 characters that have to be escaped... > > > Fun fact. The MUA i maintain still sends (in the released > version) anything 8-bit over SMTP .. without using the according > SMTP extension. It does so for way over twenty years, and the > program was a bit famous by then (long before i took > maintainership). I never saw nor heard complaints. exactly... because the real fact is that email client are all supporting 8bit MIME and UTF-8, that's why I'm sad to see still base64 in thunderbird because they had some strange issue with gpgME..... In fact, now, 99,9999999999% of server found on the internet are just handling char as 8bit, and they don't even notice that it's data... nobody do a "char & 0xEF" on every Byte he get to be sure to use ASCII table... that's why other ISO-8859-15 like encoding works. > > |so why do we still ENFORCE 7bit ascii for something that is no-where > |more used? do you know a single 7bit CPU still there????? > | > |if you can handle 8bits, you can handle 7bits... so leave the oldies > |rest in peace and move forward. > | > |base64, 7bit ascii, EBDICT, base32... quoted printable... are just > |oldies... they had their use, they are now just no more needed and > |belongs to history... you still use the old 5"1/4 floppy disk? > > Certain people do the latter. > And i think you overcomplain a bit, because for example the > terrible but omnipresent XML and JSON do not support the full > spectrum too, you need a different kind of encoding to pass data > through them. (There are certain SMTP extensions to send binary > data though.) As i love (an unconstrained) email i find it unfair > to only complain on the very old (and misused) lady email, when > those "new" protocols/formats fail to deliver what you want? I don't complain about the old lady, I only see that the old lady will be abandoned because the people behind it are frozen... yes xml did suck a lot enforcing base64 (even if in a way having binary data in something that want to be human readable..... is somewhat stupid) they could have just made some tag saying "binary data start" and "binary data end" and let the "unicode compatible text editor" display an hex dump if it wants anyway, that's not the mater, the matter is that there is a bug somewhere maybe in Thunderbird, maybe in gpgME, that prevented Thunderbird to encode the attachments in 8bit MIME.... and I won't say that Thunderbird's developpers reaction is the right one, since they preferred to do a workaround instead of having the bug fixed best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Wed Jul 30 08:39:28 2025 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Wed, 30 Jul 2025 08:39:28 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: References: <20250729163343.vhb0POXw@steffen%sdaoden.eu> Message-ID: <2186997.9o76ZdvQCi@daneel> On Mittwoch, 30. Juli 2025 01:07:54 Mitteleurop?ische Sommerzeit JL wrote: > exactly... because the real fact is that email client are all supporting > 8bit MIME and UTF-8, that's why I'm sad to see still base64 in > thunderbird because they had some strange issue with gpgME..... Is there a bug report for gpgme for this issue on dev.gnupg.org? Because if there isn't one then I have to assume that there is no issue in gpgme. We cannot fix issues we don't know anything about. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Jul 30 14:57:02 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jul 2025 14:57:02 +0200 Subject: [Bug report] [gpgme]: build may fail if gnupg is not installed In-Reply-To: <9470dbbf01eefe2477237a90f767aa5db0d0af7c.camel@neuf.fr> (Pierre Labastie via Gnupg-devel's message of "Mon, 28 Jul 2025 11:23:59 +0200") References: <9470dbbf01eefe2477237a90f767aa5db0d0af7c.camel@neuf.fr> Message-ID: <87qzxxsuox.fsf@jacob.g10code.de> Hi! On Mon, 28 Jul 2025 11:23, Pierre Labastie said: > When building gpgme, the presence of gnupg on the system is not tested, Well, it is pretty pointless to build gpgme w/o an installed GnuPG. You would not be able to run even the most basic checks. > There is an obvious workaround, which is to pass "--disable-gpg-test" > to configure, but this is nowhere documented. Hmm, ./configure --help shows: [...] --disable-gpgconf-test disable GPGCONF regression test --disable-gpg-test disable GPG regression test --disable-gpgsm-test disable GPGSM regression test --disable-g13-test disable G13 regression test [...] > It seems the "-" was removed at commit a5b040cc57c, without anything in I guess I remove this because ignoring this or other recipe is not a good idea. It may also be some leftover from former tests or so. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 30 15:05:29 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jul 2025 15:05:29 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: (JL's message of "Mon, 28 Jul 2025 22:02:49 +0200") References: Message-ID: <87ms8lsuau.fsf@jacob.g10code.de> On Mon, 28 Jul 2025 22:02, JL said: > I wanted to open a ticket on GPGME because thunderbird team says they > can't encode email using 8bit mime because of GPGME not handling TB is again using GPGME? Did they finally drop their own implementation and turned back to Enigmail or made the (gpgme based) optional GnuPG support finally working? We encode TB of binary data using gpgme without any problems. So what is this about? Your are using the legacy in-line format for signed PGP messages? *Stop doing this!* Use PGP/MIME - this is the only sane way to sign messages since the mid 90ies. And you won't run into any encoding problems because MIME (e.g. its 8 bit support) does this for you. MIME is the right layer for encoding stuff. *PGP cares about signing and encryption - another layer on top of it. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From pierre.labastie at neuf.fr Wed Jul 30 16:00:49 2025 From: pierre.labastie at neuf.fr (Pierre Labastie) Date: Wed, 30 Jul 2025 16:00:49 +0200 Subject: [Bug report] [gpgme]: build may fail if gnupg is not installed In-Reply-To: <87qzxxsuox.fsf@jacob.g10code.de> References: <9470dbbf01eefe2477237a90f767aa5db0d0af7c.camel@neuf.fr> <87qzxxsuox.fsf@jacob.g10code.de> Message-ID: On Wed, 2025-07-30 at 14:57 +0200, Werner Koch wrote: > Hi! > > On Mon, 28 Jul 2025 11:23, Pierre Labastie said: > > > When building gpgme, the presence of gnupg on the system is not > > tested, > > Well, it is pretty pointless to build gpgme w/o an installed GnuPG.? > You > would not be able to run even the most basic checks. Thanks for the advice. If other editors agree, we'll recommend GnuPG for building gpgme. > > > There is an obvious workaround, which is to pass "--disable-gpg- > > test" > > to configure, but this is nowhere documented. > > Hmm, ./configure --help shows: > > ? [...] > ? --disable-gpgconf-test? disable GPGCONF regression test > ? --disable-gpg-test????? disable GPG regression test > ? --disable-gpgsm-test??? disable GPGSM regression test > ? --disable-g13-test????? disable G13 regression test Yes, I meant it is not documented either that: - GnuPG is required for the build to succeed (even if not running the tests) without the switch - or that the switch removes the need for GnuPG. But I agree it is a minor point Thanks for the answer Pierre From KaiE at kuix.de Wed Jul 30 16:21:04 2025 From: KaiE at kuix.de (Kai Engert) Date: Wed, 30 Jul 2025 16:21:04 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <87ms8lsuau.fsf@jacob.g10code.de> References: <87ms8lsuau.fsf@jacob.g10code.de> Message-ID: <26dbacd9-5672-4080-aa8d-3be243f10c02@kuix.de> On 7/30/25 15:05, Werner Koch via Gnupg-devel wrote: > On Mon, 28 Jul 2025 22:02, JL said: > >> I wanted to open a ticket on GPGME because thunderbird team says they >> can't encode email using 8bit mime because of GPGME not handling > > TB is again using GPGME? Did they finally drop their own implementation > and turned back to Enigmail or made the (gpgme based) optional GnuPG > support finally working? TB offers support for GPGME+GnuPG as an optional configuration mechanism, to allow the use of private keys that cannot be accessed using TB's internal library, e.g. smartcard keys, or Qubes OS split GPG keys. By default, TB doesn't use GnuPG nor GPGME. Kai From devm23k73ju29h3r at dolce-energy.com Wed Jul 30 20:35:45 2025 From: devm23k73ju29h3r at dolce-energy.com (JL) Date: Wed, 30 Jul 2025 20:35:45 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <87ms8lsuau.fsf@jacob.g10code.de> References: <87ms8lsuau.fsf@jacob.g10code.de> Message-ID: <67e83ba3-46b3-4268-8235-68ae9a8b947b@dolce-energy.com> Le 30/07/2025 ? 15:05, Werner Koch a ?crit?: > On Mon, 28 Jul 2025 22:02, JL said: > >> I wanted to open a ticket on GPGME because thunderbird team says they >> can't encode email using 8bit mime because of GPGME not handling > TB is again using GPGME? Did they finally drop their own implementation > and turned back to Enigmail or made the (gpgme based) optional GnuPG > support finally working? of course not ;) they still have their builtin openPGP, I've another open ticket on this : https://bugzilla.mozilla.org/show_bug.cgi?id=1977346 for some reason, it's possible to use gpg, but they take only one key (the?"sign and certificate type", not the "cipher") but for the 8bit mime issue, the code state gpgME..... https://searchfox.org/comm-central/rev/73897d5732eac86ed38bd521ca6f4610a4411186/mail/extensions/openpgp/content/ui/enigmailMsgComposeOverlay.js#1309-1326 yes would be really nice if they could drop their builtin openPGP, because it's brocken as hell.... they re-invent the wheel, having to implement gpg-agent like to secure the keys (right now the default behavior is "protecting with the master password" but the master password is never asked to be set, so the default behavior is... storing the key unprotected... O_o! they are adding some protection, by keeping the key password, but again, this is key duplication, and since there is no agent, you have to enter the password each time you access a ciphered message. > We encode TB of binary data using gpgme without any problems. So what > is this about? Your are using the legacy in-line format for signed PGP > messages? *Stop doing this!* Use PGP/MIME - this is the only sane way > to sign messages since the mid 90ies. And you won't run into any > encoding problems because MIME (e.g. its 8 bit support) does this for > you. MIME is the right layer for encoding stuff. *PGP cares about > signing and encryption - another layer on top of it. here what I get when sending a signed message : This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------O0jQavEJzad0tdgqdlXTuPu2 Content-Type: multipart/mixed; boundary="------------FWDnkJ83p73oQajQk66iKNQY"; protected-headers="v1" From: XXXXXXX Reply-To: XXXXX To: YYYYYY Message-ID:<8176a3b2-bafa-4339-8776-7768e72a0333 at dolce-energy.com> Subject: ZZZZZZ --------------FWDnkJ83p73oQajQk66iKNQY Content-Type: multipart/mixed; boundary="------------0P7Lzttz257BGejWVIjUJ380" --------------0P7Lzttz257BGejWVIjUJ380 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Zg0KDQo= --------------0P7Lzttz257BGejWVIjUJ380 Content-Type: application/pgp-keys; name="OpenPGP_0xC732933F7F1D313F.asc" Content-Disposition: attachment; filename="OpenPGP_0xC732933F7F1D313F.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- <......> -----END PGP PUBLIC KEY BLOCK----- --------------0P7Lzttz257BGejWVIjUJ380-- --------------FWDnkJ83p73oQajQk66iKNQY-- --------------O0jQavEJzad0tdgqdlXTuPu2 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- -----END PGP SIGNATURE----- --------------O0jQavEJzad0tdgqdlXTuPu2-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewg at andrewg.com Wed Jul 30 21:34:22 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 30 Jul 2025 20:34:22 +0100 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <67e83ba3-46b3-4268-8235-68ae9a8b947b@dolce-energy.com> References: <87ms8lsuau.fsf@jacob.g10code.de> <67e83ba3-46b3-4268-8235-68ae9a8b947b@dolce-energy.com> Message-ID: <26123D2E-D6A5-412A-BC9F-5E14FDCF170C@andrewg.com> On 30 Jul 2025, at 19:35, JL wrote: > > here what I get when sending a signed message : > > > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --------------O0jQavEJzad0tdgqdlXTuPu2 > Content-Type: multipart/mixed; boundary="------------FWDnkJ83p73oQajQk66iKNQY"; > protected-headers="v1" > From: XXXXXXX > Reply-To: XXXXX > To: YYYYYY > Message-ID: <8176a3b2-bafa-4339-8776-7768e72a0333 at dolce-energy.com> > Subject: ZZZZZZ > Yes, and here?s what I get when printing to PDF: %PDF-1.3 %????????? 3 0 obj << /Filter /FlateDecode /Length 364 >> stream &????k_L1lc?`?V?????.)????????HZ?}??!?5Y?CZ?"??1?m?F?gv:??B?G?Y?? ?+ From lists at sapience.com Wed Jul 30 21:37:02 2025 From: lists at sapience.com (Genes Lists) Date: Wed, 30 Jul 2025 15:37:02 -0400 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <67e83ba3-46b3-4268-8235-68ae9a8b947b@dolce-energy.com> References: <87ms8lsuau.fsf@jacob.g10code.de> <67e83ba3-46b3-4268-8235-68ae9a8b947b@dolce-energy.com> Message-ID: On Wed, 2025-07-30 at 20:35 +0200, JL wrote: > > Le 30/07/2025 ? 15:05, Werner Koch a ?crit?: > ? ... > > On Mon, 28 Jul 2025 22:02, JL said:... .. > > > I wanted to open a ticket on GPGME because thunderbird team say ... Agree TB has some "issues" around this topic. However, I am curious if you have considered simply moving away from TB to something less "broken"? Is that an option for you? -- Gene -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part URL: From devm23k73ju29h3r at dolce-energy.com Thu Jul 31 23:28:51 2025 From: devm23k73ju29h3r at dolce-energy.com (JL) Date: Thu, 31 Jul 2025 23:28:51 +0200 Subject: 8bit mime support? (linked to thunderbird issue) In-Reply-To: <26123D2E-D6A5-412A-BC9F-5E14FDCF170C@andrewg.com> References: <87ms8lsuau.fsf@jacob.g10code.de> <67e83ba3-46b3-4268-8235-68ae9a8b947b@dolce-energy.com> <26123D2E-D6A5-412A-BC9F-5E14FDCF170C@andrewg.com> Message-ID: Le 30/07/2025 ? 21:34, Andrew Gallagher a ?crit?: > On 30 Jul 2025, at 19:35, JL wrote: >> here what I get when sending a signed message : >> >> >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) >> --------------O0jQavEJzad0tdgqdlXTuPu2 >> Content-Type: multipart/mixed; boundary="------------FWDnkJ83p73oQajQk66iKNQY"; >> protected-headers="v1" >> From: XXXXXXX >> Reply-To: XXXXX >> To: YYYYYY >> Message-ID: <8176a3b2-bafa-4339-8776-7768e72a0333 at dolce-energy.com> >> Subject: ZZZZZZ >> > Yes, and here?s what I get when printing to PDF: > > %PDF-1.3 > %????????? > 3 0 obj > << /Filter /FlateDecode /Length 364 >> > stream > &????k_L1lc?`?V?????.)????????HZ?}??!?5Y?CZ?"??1?m?F?gv:??B?G?Y?? > ?+ ]O???H????????`?[ > ?????;??fs??j?@??p=?_?6?@B??sR???2fnM???M????3g:k??&????"??Y?B{?/5U??u??2Q?X????b???(M?UoN?????f?7??_?%???O?`p?!??dc?D? > r???????1?a??&?g??? > endstream > endobj > 1 0 obj > > > What?s the problem? Emails and PDFs may *contain* plaintext, but they aren?t raw plaintext, and never have been. The fact that one particular encoding of emails happens to look very similar to plaintext IFF you are using a language that only requires US-ASCII characters is a historical curiosity. Email encodings are completely transparent to the end user if you use an actual email program and not a text editor. > > My honest and heartfelt advice is to please stop worrying about it, it?s been a solved problem for several decades now. If you have limited disk space, base64 compresses really efficiently. Please don?t read your emails in vim, you?ll only generate excess cortisol and shorten your lifespan. > > A well it does compress, however you can't compress it on the imap server, and to be frank, you gain about 50% average compared to the base64 eml, you finish with about 2% overhead on a jpeg file (that? that's still waste of disk space... you only solve the matter of disc space "somehow", and the bandwidth matter, server storage matter? and after? is there ".emlz" format? email reader that know how to handle them? what the point of a zipped email if to open it you have to decompress it, and then open it through a email reader? I also have to compress it by hand, one after another... nice! (even if I can script it for encoding, for reading I need to it one email after another) don't worry! you gain disc space and loose your life doing it... non even counting how you perform search once it's out of the mail application? and the fact that to open a single email it'll takes 10s just to decompress it... and the power consumption, CPU consumption... well! really, I should not worry about it! the solution is as worst as the base64... why not cipher it? like this you'll never be able to find it again and you'll just loose space! and the "Emails and PDFs may *contain* plaintext" => great..... and? does theses software know about the boundary="------------FWDnkJ83p73oQajQk66iKNQY" (example) ? why are they processing the text contained? it's nonsense! and a bug (not counting it's also a security issue, since you can perform code injection using the fact it will try to interpret the data)(now I understand how some people done virus using jpeg file at a time, if the email client might do something because in the jpeg there is injected ASCII...) ... boundary were created to detect the end of the attachment, anything between is just... DATA! the code is rather simple : while(curr!=eof && strncmp(curr, boundary, sizeof(boundary)) curr++; if fact, wathever the encoding, there is no need to interpret the data... even if there is ascii in the attachement, the client has no need to say "oh! there is ascii there, maybe should I do some stupid thing with? or change my processing mode? oh! looks, it's some script! I should try to execute it!!" if the encoding is 8bitMIME, then there is nothing to do, just consume the data until the boundary is found... other encoding need to be decoded into memory (so you can't do a mapped file access, you need either to dump it in temporary file, or store it into memory... 2 inefficient resource access) "it's a solved problem for several decades now" ahaha... a solved problem... there is nothing solved... it's just workaround, and not a good workaround (if there are "good" workaround), no wonder we need today 16GB of ram, ryzen 7 12 cores CPU, and fiber optic 1Gbps connection to just surf the web, read some emails and type some word document... just some tests? : a 33MB random pdf file that was sent to a client, AMD Ryzen 7 5825U time to compress using 7za : 14s the base64 version, 7s the pdf version (twice the time...) and 14s overhead compared to raw access on a modern CPU (ok, not the fastest... but there is something wrong if you need a supercomputer to read emails...) base64 overhead once compressed : 2MB..... (yes, after compression, the file is bigger if gone through base64, it's 33% smaller if the raw file is compressed) and this is a SINGLE FILE, so now do it on all the emails, and all the attachments yes, really, I should not worry! I just have to change computer every 2 years and buy some storage every 6 months, change my network connection every 3 years... the solution is inefficient, resource consuming, and just to avoid doing a thing that is 30 year old... seems indeed that at this time, because they didn't had supercomputer, slow connections, they done the thing that is not and that is the only thing to do, rather than trying to say "don't worry, we solved the issue, do a workaround" it remember the ones that says "oh you need that? well I'll teach you how to need it" best regards