[PATCH libgcrypt] Disable CPU speculation-related misfeatures

[Guido Trentalancia]

There is no profit in changing additional parts of the code, for that
only overcomplicates the underlying problem and the source code, so
further changes won't happen.

The patch is provided as it is.

Regards,

Guido

On Wed, 25/06/2025 at 18.12 +0200, Werner Koch wrote:
> On Mon, 23 Jun 2025 20:22, Guido Trentalancia said:
> > The best way to achieve protection is obviously by calling prctl()
> > during the cryptographic application startup and this is precisely
> > what
> > the gnupg patch does:
> > https://lists.gnupg.org/pipermail/gnupg-devel/2025-May/035904.html
> 
> Right.  I replied with
> 
>   If that is a misfeature it needs to be fixed at the pläce where it
> was
>   introduced and not just in a single binary.  If this code is really
>   needed it would first of all be useful in Libgcrypt only then then
> you
>   should put it into gnupg/common/init.c:early_system_init.
>   
>   Specific Linux code is in general not a good idea, if that is
> required,
>   please write a proper configure test for this feature and use a
>   dedicated macro.  A more detailed explanation of the pro and cons
> would
>   also be appreciated.
> 
> But you did not came up with a fixed patch but instead you wrote
> 
>   A test in the autoconf-generated "configure" script is not needed,
>   because the patch automatically detects whether the glibc and
> kernel
>   versions support disabling those vulnerabilities.
> 
> and refused my above advise.  If you don't want to write the
> respective
> autoconf checks you may also add a configure option to enable your
> code.
> 
> I would also suggest to use an environemnt variabale to activate the
> tests.  For example, for signature verification the whole code is
> superflous.  An envar let the admin decide whether it is worth to do
> that.
> 
> One may also want to extend ld and ld.so to process a dedicated ELF
> segment to enable linking in that code.  This way a library can
> demand
> the use of this code.
> 
> 
> 
> 
> 
> 
> 
> 
> > However it is not possible to foresee all the other applications
> > using
> > libgcrypt, so another preventive patch has been submitted so that
> > prctl() is also called by the cryptographic library and this is
> > what
> > the libgcrypt patch does:
> > https://lists.gnupg.org/pipermail/gcrypt-devel/2025-May/005856.html
> > By applying the companion libgcrypt patch we offer some kind of
> > protection to applications other than gnupg, even though the level
> > of
> > protection is not the same as if prctl() was called at application
> > startup.
> > Please note that calling prctl() twice in gnupg and then in
> > libgcrypt
> > has no side-effects.
> > The fact that other cryptographic libraries such as openssl do not
> > do
> > the same only means that they are vulnerable those cryptographic
> > information disclosure vulnerabilities.
> > Regards,
> > Guido
> > On Mon, 23/06/2025 at 19.58 +0200, Werner Koch wrote:
> > > On Mon, 23 Jun 2025 13:57, Guido Trentalancia said:
> > > > It does not change the property of the system, it only changes
> > > > the
> > > 
> > > Sorry, with "system" I meant the process with its main
> > > application
> > > and
> > > all other libraries.  Libgcrypt is a library usally linked at
> > > runtime
> > > and thus it would be surprising if it changes such process
> > > properties.
> > > 
> > > 
> > > Salam-Shalom,
> > > 
> > >    Werner
> > > 
> > 
> > _______________________________________________
> > Gcrypt-devel mailing list
> > Gcrypt-devel at gnupg.org
> > https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> > 
> 
>