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 <gu...@trentalancia.com>
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 <config.h>
+#if defined(__linux__)
+# include <sys/prctl.h>
+#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-cjbs2u00gm7xcyh...@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@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
