<html><head></head><body><div>On Thu, 10/07/2025 at 15.19 +0200, Werner Koch wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Thu, 10 Jul 2025 12:41, Guido Trentalancia said:</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>I have tested the patch and the logging functions work as I would</div><div>expect. They might need to be initialized before early_system_init(),</div></blockquote><div><br></div><div>That is a catch-22 - early_system_init is supposed to be the very first</div><div>thing done after main(). If you want to catch errors, use abort() or</div><div>store the the error and retrieve it after the logging has been enabled.</div><div>This would be similar to the secmem handling done in GnuPG. It might</div><div>even be useful to do the whole thing as part of the secmem thing - this</div><div>is also a critical thing and we have quite some experience on how to get</div><div>this right over all the components.</div></blockquote><div><br></div><div>I have switched to simple printf() calls in a new v13 patch, which is also my last attempt to fix this.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>2017, leaving the program vulnerable to data leaks for about 8 years !</div></blockquote><div><br></div><div>It is not the gpg or actually gpg-agent process which leaks the data but</div><div>it is a properly of the CPU. If you can mount such an attack on highly</div><div>sensitive data, that CPU might not be the right rig for you. In</div><div>particular I would strongly advise not to process such secrets on a VM.</div></blockquote><div><br></div><div>The three vulnerabilities have nothing to do with using a VM or "multi-tenant systems": this is a very big misunderstanding !</div><div><br></div><div>This is very easy to understand by looking at the first table in <a href="https://msrc.microsoft.com/blog/2018/05/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/">https://msrc.microsoft.com/blog/2018/05/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/</a></div><div><br></div><div>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.</div><div><br></div><div>Similar considerations can be made for the other two vulnerabilities.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>I would suggest to implement the whole stuff in the run-time loader and</div><div>provide a way to configure which processes should do this. This way</div><div>users can decide whether it is worth to disable these CPU-(mis)features</div><div>mitigations.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>That is the real problem !!</div></blockquote><div><br></div><div>The real problem is a over-complicated mitigation for a problem to be</div><div>solved elsewhere.</div></blockquote><div><br></div><div>If the above refers to the proposed patches, then it is just an unfounded recrimination !</div><div><br></div><div>I am perfectly happy with the three simple prctl() calls that were proposed in the initial patch on the 26th of May.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><pre>common: Disable CPU speculative execution security</pre><pre>vulnerabilities (CVE-2018-3639 aka Spectre variant 4,</pre><pre>CVE-2017-5715 and optionally CVE-2020-0550)</pre><pre><br></pre><pre>* configure.ac: add a new L1D Cache flushing option</pre><pre>(--enable-l1d-cache-flushing) to fix CVE-2020-0550</pre><pre>and check for sys/prctl.h on Linux systems</pre><pre><br></pre><pre>* common/init.c (early_system_init): Disable CPU</pre><pre>speculative execution security vulnerabilities</pre><pre>potentially causing data leaks:</pre><pre><br></pre><pre> - Speculative Store Bypass (always disabled)</pre><pre> - Indirect Branch Speculation (always disabled)</pre><pre> - Flush L1D Cache on context switch out of the</pre><pre> task (use the --enable-l1d-cache-flushing</pre><pre> configure option and "nosmt l1d_flush=on" on the</pre><pre> boot command line to mitigate the vulnerability)</pre><pre><br></pre><pre>For further information see the kernel documentation:</pre><pre>Documentation/userspace-api/spec_ctrl.rst</pre><pre>Documentation/admin-guide/hw-vuln/l1d_flush.rst</pre><pre><br></pre><pre>Signed-off-by: Guido Trentalancia <<a href="mailto:guido@trentalancia.com">guido@trentalancia.com</a>></pre><pre><br></pre><pre>diff -pru a/common/init.c b/common/init.c</pre><pre>--- a/common/init.c 2025-05-25 15:43:45.871984100 +0200</pre><pre>+++ b/common/init.c 2025-07-09 13:39:44.036998821 +0200</pre><pre>@@ -29,6 +29,14 @@</pre><pre> </pre><pre> #include <config.h></pre><pre> </pre><pre>+#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H)</pre><pre>+# include <sys/prctl.h></pre><pre>+#endif</pre><pre>+</pre><pre>+#if defined(ENABLE_L1D_CACHE_FLUSH)</pre><pre>+# include <signal.h></pre><pre>+#endif</pre><pre>+</pre><pre> #ifdef HAVE_W32_SYSTEM</pre><pre> # if _WIN32_WINNT < 0x0600</pre><pre> # define _WIN32_WINNT 0x0600 /* Required for SetProcessDEPPolicy. */</pre><pre>@@ -128,10 +136,68 @@ writestring_via_estream (int mode, const</pre><pre> }</pre><pre> </pre><pre> </pre><pre>+#ifdef ENABLE_L1D_CACHE_FLUSH</pre><pre>+void sigbus_handler (int signo)</pre><pre>+{</pre><pre>+ if (signo == SIGBUS)</pre><pre>+ {</pre><pre>+ printf ("Fatal: Level 1 Data Cache flushing requires the \"nosmt\" boot parameter.\n");</pre><pre>+ exit (SIGBUS);</pre><pre>+ }</pre><pre>+}</pre><pre>+#endif</pre><pre>+</pre><pre>+</pre><pre> /* This function should be the first called after main. */</pre><pre> void</pre><pre> early_system_init (void)</pre><pre> {</pre><pre>+#if defined(__linux__) && defined(HAVE_SYS_PRCTL_H)</pre><pre>+</pre><pre>+/* Disable CPU speculative execution security vulnerabilities</pre><pre>+ * causing data leaks: see the Linux kernel documentation</pre><pre>+ * Documentation/userspace-api/spec_ctrl.rst</pre><pre>+ *</pre><pre>+ * - Speculative Store Bypass (CVE-2018-3639, always</pre><pre>+ * disabled)</pre><pre>+ * - Indirect Branch Speculation (CVE-2017-5715, always</pre><pre>+ * disabled)</pre><pre>+ * - Flush L1D Cache on context switch out of the task (it</pre><pre>+ * requires the "nosmt l1d_flush=on" kernel boot parameter)</pre><pre>+ */</pre><pre>+#ifdef PR_SPEC_STORE_BYPASS</pre><pre>+ prctl (PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_FORCE_DISABLE, 0, 0);</pre><pre>+#endif</pre><pre>+</pre><pre>+#ifdef PR_SPEC_INDIRECT_BRANCH</pre><pre>+ prctl (PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);</pre><pre>+#endif</pre><pre>+</pre><pre>+#if defined(ENABLE_L1D_CACHE_FLUSH) && defined(PR_SPEC_L1D_FLUSH)</pre><pre>+ struct sigaction old_action, new_action;</pre><pre>+</pre><pre>+ new_action.sa_handler = sigbus_handler;</pre><pre>+ sigemptyset (&new_action.sa_mask);</pre><pre>+ new_action.sa_flags = 0;</pre><pre>+</pre><pre>+ sigaction (SIGBUS, NULL, &old_action);</pre><pre>+ if (old_action.sa_handler != SIG_IGN)</pre><pre>+ {</pre><pre>+ if (sigaction (SIGBUS, &new_action, NULL) == -1)</pre><pre>+ {</pre><pre>+ printf ("Warning: cannot catch the SIGBUS signal.\n");</pre><pre>+ }</pre><pre>+ }</pre><pre>+</pre><pre>+ if (prctl (PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0) < 0)</pre><pre>+ {</pre><pre>+ printf ("Warning: Level 1 Data Cache flushing requires the \"l1d_flush=on\" boot parameter.\n");</pre><pre>+ }</pre><pre>+</pre><pre>+ sigaction (SIGBUS, &old_action, NULL);</pre><pre>+#endif</pre><pre>+</pre><pre>+#endif /* __linux__ && HAVE_SYS_PRCTL_H */</pre><pre> }</pre><pre> </pre><pre> </pre><pre>diff -pru a/configure.ac b/configure.ac</pre><pre>--- a/configure.ac 2025-07-06 18:01:54.128546282 +0200</pre><pre>+++ b/configure.ac 2025-07-08 21:32:32.674405293 +0200</pre><pre>@@ -244,6 +244,16 @@ AC_ARG_ENABLE(selinux-support,</pre><pre> AC_MSG_RESULT($selinux_support)</pre><pre> </pre><pre> </pre><pre>+# Fix security vulnerability CVE-2020-0550 by enabling</pre><pre>+# Level 1 Data Cache flushing on context switch.</pre><pre>+AC_MSG_CHECKING([whether Level 1 Data Cache is flushed on context switch])</pre><pre>+AC_ARG_ENABLE(l1d-cache-flushing,</pre><pre>+ AS_HELP_STRING([--enable-l1d-cache-flushing],</pre><pre>+ [enable L1D cache flushing]),</pre><pre>+ l1d_cache_flushing=$enableval, l1d_cache_flushing=no)</pre><pre>+AC_MSG_RESULT($l1d_cache_flushing)</pre><pre>+</pre><pre>+</pre><pre> AC_MSG_CHECKING([whether to allocate extra secure memory])</pre><pre> AC_ARG_ENABLE(large-secmem,</pre><pre> AS_HELP_STRING([--enable-large-secmem],</pre><pre>@@ -1313,6 +1323,16 @@ fi</pre><pre> </pre><pre> </pre><pre> #</pre><pre>+# Level 1 Data Cache flushing on context switch (CVE-2020-0550)</pre><pre>+#</pre><pre>+if test "$l1d_cache_flushing" = yes ; then</pre><pre>+ AC_DEFINE(ENABLE_L1D_CACHE_FLUSH,1,</pre><pre>+ [Define to enable Layer 1 Data Cache flushing])</pre><pre>+ AC_CHECK_HEADERS([signal.h])</pre><pre>+fi</pre><pre>+</pre><pre>+</pre><pre>+#</pre><pre> # Checks for header files.</pre><pre> #</pre><pre> AC_MSG_NOTICE([checking for header files])</pre><pre>@@ -1322,6 +1342,13 @@ AC_CHECK_HEADERS([unistd.h langinfo.h te</pre><pre> ucred.h sys/ucred.h sys/sysmacros.h sys/mkdev.h])</pre><pre> </pre><pre> </pre><pre>+# See whether libc supports the prctl()</pre><pre>+case "${host}" in</pre><pre>+ *-*-linux*)</pre><pre>+ AC_CHECK_HEADERS([sys/prctl.h])</pre><pre>+ ;;</pre><pre>+esac</pre><pre>+</pre><pre> #</pre><pre> # Checks for typedefs, structures, and compiler characteristics.</pre><pre> #</pre><pre></pre></body></html>