Re: [PATCH gnupg v3] Disable CPU speculation-related misfeatures

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 <[email protected]>
> 
> 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
> [email protected]
> https://lists.gnupg.org/mailman/listinfo/gnupg-devel


_______________________________________________
Gnupg-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-devel