[PATCH libgcrypt] Disable CPU speculation-related misfeatures

[Werner Koch]

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
>

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250625/e2eac941/attachment.sig>