[PATCH gnupg v3] Disable CPU speculation-related misfeatures
Jussi Kivilinna
jussi.kivilinna at iki.fi
Sat Jul 5 13:37:19 CEST 2025
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 <guido at 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-Cjbs2u00gm7XcYHBfw@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
More information about the Gnupg-devel
mailing list