Thank you for having a look into this!

Not for a broken compiler but for several CC versions which consumed lots of memory for unrulling stuff. iirc, this was not only gcc.

Here's patches for adding CET support to x86-64 and i386 assembly.

OpenBSD carries libgcrypt patch for CET which adds endbr64 instruction to CFI_STARTPROC() macro in "asm-common-amd64.h". We could do the same and also add endbr32 to i386 too. That would be easiest way to add required endbr instructions. OpenBSD also has patch for arm64 to add similar BTI instructions to aarch64 variant of CFI_STARTPROC.

There is -O flag munging for "tiger.o" in "cipher/Makefile.am", an old workaround for broken compiler I think. IMHO tiger.o case can and should be removed.

OpenBSD carries libgcrypt patch for CET which adds endbr64 instruction to CFI_STARTPROC() macro in "asm-common-amd64.h". We could do the same and also add endbr32 to i386 too. That would be easiest way to add required endbr instructions. OpenBSD also has patch for arm64 to add similar BTI instructions to aarch64 variant of CFI_STARTPROC.

We hereby deliver with some delay our completed version of the integration of PQC algorithms into Libgcrypt from our project. The code features the following algorithms:

Verified the fix.

Pushed the change to master. Please test.
rCbb0895bbb7c6: m4: Fix acinclude.m4 for underscore detection in the symbol.

Thank you for the report.

Thanks for the detailed analysis; we will check to tomorrow why this was changed.

In T7175#187690, @jukivili wrote:

Hm, CFI directives should not be used on WIN32 target. This patch should solve the issue for now:

0001-src-hwf-x86-disable-inline-assembly-CFI-directivies-.patch984 BDownload

Here is a fix for the issue which preserves the removal of cut:

Using clang for Windows is not tested or suggested. Thus low priority.

Thanks for testing. I pushed this fix to libgcrypt master.

Done.

Done in 1.11.0.

This diff for 1.11.0 fixes the problem for me:

The following logic from 1.11.0 acinclude.m4 cannot possibly work to detect _ at the beginning of symbol names:

The toolchain is clang / llvm and the apple ld, native build, not cross compiling.

Thank you for having a look into that. If I see right, Fedora has a real s390 hardware for builders so I can verify the fix when available.

Algo 329 and 330 are the new CSHAKE128 and CSHAKE256 digest algos. Looks that s390x only support accelerating SHA3 and SHAKE, as only SHA3 and SHAKE suffix are supported (see keccak_final_s390x()). So s390x acceleration needs to be disabled for CSHAKE algos.

Applied in: rCdc8d84383a6b: cipher:aeswrap: Fix padding length check.

I left review comments in gitlab.

We discussed this forth and back with the RedHat people at our jour-fix to explain that the Kairo fix is done at the wrong layer - this needs to be done at the protocol layer and not in the building blocks. This is not covered by our security policy and @gniibe already came up with some extra support to help at the protocol layer. There are only a few use cases where this side-channel or the Minerva one (for ECDSA) should be considered (e.g. time stamping services). Generally required protection against DoS are also pat of the mitigation.

I left review comments in gitlab. One additional concern is license for mpi-mul-cs.c, original code not having copyright information... "does not have any copyright information, assuming public domain".

Right, thats my understanding from reading of the RFC that the padding should be strictly < 8B. We can reword though.

Well, but if the padding is indeed limited to 7 bytes the fix should be applied anyway.

The report went like this

Error: OVERRUN (CWE-119):
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:303: cond_at_most: Checking "plen > 8U" implies that "plen" may be up to 8 on the false branch.
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:305: cond_between: Checking "plen" implies that "plen" is between 1 and 8 (inclusive) on the true branch.
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:309: assignment: Assigning: "i" = "0".
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:310: overrun-local: Overrunning array "t" of 16 bytes at byte offset 16 using index "8U + plen + i" (which evaluates to 16).
#  308|   
#  309|                 for (i = 0; i < 16 - (8+plen); i++)
#  310|->                 if (t[8+plen+i])
#  311|                     {
#  312|                       err = GPG_ERR_CHECKSUM;

but looking again, it is wrong as it did not reflect the end condition for the cycle, which obviously means the cycle does not run. Sorry for the noise.

Can you give a hint where there is a buffer overrun in the first patch? Padding limit might be correct but I can't see an overrun.

Thank you. Applied by : rM87061c0260bb: gpgme.m4: Set $host correctly always.

Ditto for ksba and assuan.

The gcrypt change works for me. Thanks!

In general, asking an application change is not good. Migrating to pkg-config should be an option (not requirement).
However, it's usually recommended to use libgpg-error when an application is used with libgcrypt/libksba/libassuan.

Just to clarify: I personally think it would be perfectly fine to say that AM_PATH_* is only supported when AM_PATH_GPG_ERROR is also used. Adding an invocation AM_PATH_GPG_ERROR is not a great hassle and alternatively pkg-config/pkgconf exists and works perfectly fine (and is a lot faster).

I noticed this recently too on some boxes. Thanks for the good decription. This support for pkg-config style .pc files for our config scripts seems to be a never ending story. The alternative name for libgpg-error-config does not make it easier.

Thanks for report. I've applied this change to master.

I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.

Can we close this?

Here is current version:

diff --git a/src/misc.c b/src/misc.c
index 4db2d9a4..bf50b00b 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -577,3 +577,61 @@ _gcry_divide_by_zero (void)
     gpg_err_set_errno (EDOM);
     _gcry_fatal_error (gpg_err_code_from_errno (errno), "divide by zero");
 }
+
+#ifdef HAVE_CLOCK_GETTIME
+#include <time.h>
+# if defined(CLOCK_THREAD_CPUTIME_ID) && defined(CLOCK_TAI)
+struct gcry_timedwait
+{
+  clockid_t id;
+  struct timespec ts;
+};
+
+typedef struct gcry_timedwait *gcry_timedwait_t;
+
+gcry_err_code_t
+_gcry_timedwait_init (gcry_timedwait_t tw, unsigned int flags)
+{
+  /* Possibly, it would be good to be able to select the wall clock.
+   * For now, it's CPU time by the thread.  */
+  if (flags != 0)
+    return GPG_ERR_INV_ARG;
+
+  tw->id = CLOCK_THREAD_CPUTIME_ID;
+  if (clock_gettime (tw->id, &tw->ts) < 0)
+    return gpg_err_code_from_syserror ();
+
+  return 0;
+}
+
+gcry_err_code_t
+_gcry_timedwait_finish (gcry_timedwait_t tw, struct timespec ts_r)
+{
+  struct timespec ts;
+  u32 negative;
+
+  if (clock_gettime (tw->id, &ts) < 0)
+    return gpg_err_code_from_syserror ();
+
+  ts.tv_sec -= tw->ts.tv_sec;
+  ts.tv_nsec -= tw->ts.tv_nsec;
+  negative = ((u32)ts.tv_nsec) >> 31;
+  ts.tv_sec -= negative;
+  ts.tv_nsec += (1000000000 * negative);
+
+  ts_r.tv_sec -= ts.tv_sec;
+  ts_r.tv_nsec -= ts.tv_nsec;
+  negative = ((u32)ts_r.tv_nsec) >> 31;
+  ts_r.tv_sec -= negative;
+  ts_r.tv_nsec += (1000000000 * negative);
+
+  if (ts_r.tv_sec < 0)
+    return GPG_ERR_TIME_CONFLICT;
+
+  if (clock_nanosleep (CLOCK_TAI, 0, &ts_r, &ts_r))
+    return gpg_err_code_from_syserror ();
+
+  return 0;
+}
+# endif
+#endif

API which does not require allocation internally would be better. In this case, it is allocated on stack by the caller.

I mean, something like this (for GNU/Linux):

diff --git a/src/misc.c b/src/misc.c
index 4db2d9a4..74864334 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -577,3 +577,80 @@ _gcry_divide_by_zero (void)
     gpg_err_set_errno (EDOM);
     _gcry_fatal_error (gpg_err_code_from_errno (errno), "divide by zero");
 }
+
+#ifdef HAVE_CLOCK_GETTIME
+#include <time.h>
+# if defined(CLOCK_THREAD_CPUTIME_ID) && defined(CLOCK_TAI)
+struct gcry_timedwait
+{
+  struct timespec ts;
+};
+
+typedef struct gcry_timedwait *gcry_timedwait_t;
+
+gcry_err_code_t
+_gcry_timedwait_new (gcry_timedwait_t *r_tw, unsigned int flags)
+{
+  gcry_err_code_t err;
+  gcry_timedwait_t tw;
+
+  *r_tw = NULL;
+
+  /* Possibly, it would be good to be able to select the wall clock.
+   * For now, it's CPU time by the thread.  */
+  if (flags != 0)
+    return GPG_ERR_INV_ARG;
+
+  tw = xtrymalloc (sizeof (gcry_timedwait_t));
+  if (!tw)
+    return gpg_err_code_from_syserror ();
+
+  if (clock_gettime (CLOCK_THREAD_CPUTIME_ID, &tw->ts) < 0)
+    {
+      err = gpg_err_code_from_syserror ();
+      xfree (tw);
+      return err;
+    }
+
+  *r_tw = tw;
+  return 0;
+}
+
+gcry_err_code_t
+_gcry_timedwait_release (gcry_timedwait_t tw, struct timespec ts_r)
+{
+  gcry_err_code_t err;
+  struct timespec ts;
+  u32 negative;
+
+  if (clock_gettime (CLOCK_THREAD_CPUTIME_ID, &ts) < 0)
+    {
+      err = gpg_err_code_from_syserror ();
+      xfree (tw);
+      return err;
+    }
+
+  ts.tv_sec -= tw->ts.tv_sec;
+  ts.tv_nsec -= tw->ts.tv_nsec;
+  negative = ((u32)ts.tv_nsec) >> 31;
+  ts.tv_sec -= negative;
+  ts.tv_nsec += (1000000000 * negative);
+
+  xfree (tw);
+
+  ts_r.tv_sec -= ts.tv_sec;
+  ts_r.tv_nsec -= ts.tv_nsec;
+  negative = ((u32)ts_r.tv_nsec) >> 31;
+  ts_r.tv_sec -= negative;
+  ts_r.tv_nsec += (1000000000 * negative);
+
+  if (ts_r.tv_sec < 0)
+    return GPG_ERR_TIME_CONFLICT;
+
+  if (clock_nanosleep (CLOCK_TAI, 0, &ts_r, &ts_r))
+    return gpg_err_code_from_syserror ();
+
+  return 0;
+}
+# endif
+#endif

Thank you!

Applied to both (master and 1.10 branch).

Looks good to me. __CLOBBER_CC is needed as PA-RISC has carry/borrow bits in status register for add/sub instructions.

Since I don't like to introduce hppa specific workaround in a way like pragma (and I have no time to fix compiler itself), I tried to improve the ec-nist.c for hppa so that register pressure can be lower.
Here is my solution.

Alternatively (more narrow workaround), when I add a line:

#pragma GCC optimize("O1")

before the function _gcry_mpi_ec_nist256_mod in mpi/ec-nist.c, it works for me on panama.debian.net (Debian porterbox for hppa).

No, hardware barrier is not needed here. Compiler barrier is used here to prevent optimization removing mask generation and usage in following constant-time code.

Clarification from Dave:

Thanks, I can confirm that this patch fixes the issue. I'll let Sam decide if this is how we want to handle it downstream or wait for confirmation from gcc.

A way to generated keys in the usual s-expression way has been added. This allows us to get the keygrip for the key.