[PATCH gnupg v3] Disable CPU speculation-related misfeatures

[Guido Trentalancia]

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 <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-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
> 
>