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 <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-Cjb
> s2u00gm7xcyh...@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
