I created a branch: https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7340/

Autoconf archive has AX_TLS: https://www.gnu.org/software/autoconf-archive/ax_tls.html
Also, AX_GCC_VAR_ATTRIBUTE(tls_model) could be used: https://www.gnu.org/software/autoconf-archive/ax_gcc_var_attribute.html

Pushed the change in: rC38742196c04c: cipher:kyber: Add gcry_kem_genkey to support deterministic op.
rC4876a1a45c25: tests:kyber: Add genkey and encap KAT tests.

Use --enable-large-data-tests with configure and go out for a real long lunch

As far as I know the practice to have separate -dev packages is very common among Linux distributions.

I wonder how common this practice of splitting development material into a separate file might be? It is in place at Alpine, since the file libgpg-error-dev exists. Once the related component is instaled, these messages/strings are printed:; output filtered:

checking for GPG Error - version >= 1.49... expr: warning: '^x-L': using '^' as the first character of a basic regular expression is not portable; it is ignored  yes (1.49)

Does alpine split the development files of libgpg-error into a separate *-devel (or similar) package like most other distros? If yes, then you need to install this development package.

Thanks. Test works in my nightly builds now.

That's my badness.
I noticed by the CI at https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror

I do not have Aarch64 machine at hand so what I did was building the package with changes on the build system with previous patches and checking the correct flag are in place (previously in RHEL10, but now in Fedora):

Do you have any way to test PAC/BTI on actual HW that support these extensions?

Thanks! Verified this builds on aarch64 correctly and generates the right flags on the output:

Hardened: /builddir/build/BUILDROOT/libgcrypt-1.11.0-3.el10.aarch64/usr/lib64/libgcrypt.so.20.5.0: Overall: PASS.

This excludes 32-bit ARM assembly from Aarch64 builds:

In T7226#189443, @jukivili wrote:

This patch should fix the issue:

0001-mpi-ec-inline-reduce-register-pressure-on-32-bit-ARM.patch4 KBDownload

Tested in our build environment and indeed, just this patch does not solve the issue for aarch64.

Here's patch:

This patch should fix the issue:

Ok, so aarch64 assembly would need PAC and BTI support. As far as I have understood these, is that PAC instructions are not needed with current assembly as none of those is storing/loading LR register (all aarch64 assembly functions are leaf functions). So only BTI is needed and that is basically same modification as CET on x86.

This already shows with 9d909cb67e70fd792926ac1e2ab305b2cc96bc27 which initially added ec-inline.h. (Reproducing with old versions like this one requires cherry-picking 693ffa145378682229473b0e811a9cea7c4d307a since otherwise NEON support is disabled at configure time due to implicit functions.)

Recent changes fixed the issue for the x86_64 builds, but I see similar symptoms in the aarch64 build now. Annocheck reports the following failures:

Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: dynamic-tags test because the BTI_PLT flag is missing from the dynamic tags 
Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-dynamic-tags.html
Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: property-note test because properly formatted .note.gnu.property not found (it is needed for branch protection support) 
Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-property-note.html

I do not have aarch64 machine at hand now to investigate this further, but this sounds like orthogonal functionality to the CET on Intel.

Thank you. With this patch the IBT flags are present on the shared object and CF protection test passes.

"rijndael-vaes-avx2-i386.S" should not be build for x86-64 but until now that has not had any affect as #ifdefs in that source file result empty object file on x86-64.

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: