The file cipher/poly1305.c defines arm operations before x86 which results in illegal instructions. Reproducible: Always Steps to Reproduce: 1. i686-gentoo-linux-gnu-emerge -v libgcrypt Actual Results: /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c: Assembler messages: /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %ebp,%edx,%ebx,%edi' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %edi,%eax,%ebx,%esi' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %edx,%esi,%ebx,%eax' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %edx,%ecx,%ebx,%eax' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %ebp,%edx,%ebx,%eax' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %edi,%eax,%ebx,%ecx' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %eax,%esi,%ebx,%ecx' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %eax,%edi,%ebx,%ecx' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %edi,%edx,%ebp,%ecx' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %edi,%edx,%ebp,%ebx' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %ebp,%esi,%ebx,%ecx' /var/tmp/portage/dev-libs/libgcrypt-1.9.0/work/libgcrypt-1.9.0/cipher/poly1305.c:389: Error: no such instruction: `umlal %eax,%edx,%ebx,%ecx' lto-wrapper: fatal error: i686-gentoo-linux-gnu-gcc returned 1 exit status compilation terminated. /usr/libexec/gcc/i686-gentoo-linux-gnu/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status Expected Results: It should build and install. The configure script detects the assembler understands ARM: checking whether GCC assembler is compatible for ARM assembly implementations... yes The linked URL has the patch to fix it that I sent upstream. It will need to be backported. See also bug #766423.
Upstream is going to use a different patch to configure.ac rather than conditionalize using ARM assembly on __arm__.
I managed to get libgcrypt to compile with my own hacks, below. However, it doesn't pass runtime checks. I'm not sure where to find the upstream patches to try them out. When starting keepassxc, it crashes with: % keepassxc libgcrypt selftest: kdf (34): gcry_kdf_derive failed (1.2.643.2.2.30.0) libgcrypt selftest: kdf (34): Selftest failed Here were my hacks: 1. Clang patch to disable optimizations in jitterentropy-base.c, which I think I found in FreeBSD? 2. Override the checks for arm/aarch64 support 3. (optional, compiled but didn't help) Use GAS for assembly Patch to ebuild, libgcrypt below. --- gentoo/dev-libs/libgcrypt/libgcrypt-1.9.0.ebuild 2021-01-20 13:09:14.000000000 -0800 +++ local/dev-libs/libgcrypt/libgcrypt-1.9.0.ebuild 2021-01-22 15:07:33.405343902 -0800 @@ -21,6 +21,7 @@ PATCHES=( "${FILESDIR}"/${PN}-1.6.1-uscore.patch "${FILESDIR}"/${PN}-multilib-syspath.patch + "${FILESDIR}"/${PN}-clang.patch ) MULTILIB_CHOST_TOOLS=( @@ -39,6 +40,24 @@ # function for that, we'll have to abuse cflags for this append-cflags -Wa,--divide fi + + # The check is broken on clang on 32-bit builds. In particular, clang + # doesn't support the umlal ARM instruction, which isn't tested for. + export gcry_cv_gcc_arm_platform_as_ok=no + # Also disable for aarch64 because this check is probably broken, too. + export gcry_cv_gcc_aarch64_platform_as_ok=no + + #export CCAS=gcc + #local ccasflags=() + #for f in $(get_abi_CFLAGS); do + # if [[ ${f} = -flto=thin ]]; then + # ccasflags+=(-flto -ffat-lto-objects) + # else + # ccasflags+=("$f") + # fi + #done + #export CCASFLAGS="${ccasflags[*]}" + local myeconfargs=( CC_FOR_BUILD="$(tc-getBUILD_CC)" --enable-noexecstack libgcrypt-clang.patch: diff -ru libgcrypt-1.9.0.orig/random/jitterentropy-base.c libgcrypt-1.9.0/random/jitterentropy-base.c --- libgcrypt-1.9.0.orig/random/jitterentropy-base.c 2021-01-20 14:12:06.044768789 -0800 +++ libgcrypt-1.9.0/random/jitterentropy-base.c 2021-01-20 14:28:25.336545094 -0800 @@ -50,6 +50,11 @@ */ #undef _FORTIFY_SOURCE +#ifdef __clang__ +#pragma clang optimize off +#include "jitterentropy.h" +// clang does not undefine the __optimize__ macro +#else #pragma GCC optimize ("O0") #include "jitterentropy.h" @@ -60,6 +65,7 @@ #error "The CPU Jitter random number generator must not be compiled with optimizations. See documentation. Use the compiler switch -O0 for compiling jitterentropy-base.c." #endif #endif +#endif #define MAJVERSION 2 /* API / ABI incompatible changes, functional changes that * require consumer to be updated (as long as this number
> 3. (optional, compiled but didn't help) Use GAS for assembly I believe that this was an alternative to disabling LTO (I've been debugging this too long). Maybe the only thing I needed was -ffat-lto-objects in CCASFLAGS, which unfortunately doesn't get -m32 or -m64 added for multilib builds. It's usually unset, so libgcrypt just uses CFLAGS.
Created attachment 684696 [details, diff] arm_asm_ifdef_fix I am having the same issue. this patch fixes it for me. Even though I compile for pentium processor (x86) the configure stage detects my assembler as ARM compatible. So I dont know whether my fix is the best. Maybe the detection in the config script should be checked instead. Thats for the upstream to decide. BTW is there a bugreport created for the upstream developers? checking whether GCC assembler is compatible for ARM assembly implementations... yes checking whether GCC assembler is compatible for ARMv8/Aarch64 assembly implementations... yes checking whether GCC assembler supports for CFI directives... yes checking whether GCC assembler supports for ELF directives... yes checking for _ prefix in compiled symbols... no checking architecture and mpi assembler functions... x86
Upstream has pushed the fix commit, and they are working on a 1.9.1 release with it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d554d368f2cc68c944b92c2a64be391ca272eac1 commit d554d368f2cc68c944b92c2a64be391ca272eac1 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-01-29 13:10:07 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-01-29 13:10:07 +0000 dev-libs/libgcrypt: (security) bump to 1.9.1 This includes a critical security fix on 1.9.0 (currently masked). Note that the mask on 1.9.0 currently forces a downgrade to the safe 1.8.x series. Bug: https://bugs.gentoo.org/767814 Bug: https://bugs.gentoo.org/766213 Closes: https://bugs.gentoo.org/766423 Closes: https://bugs.gentoo.org/766429 Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/libgcrypt/Manifest | 2 +- .../libgcrypt/{libgcrypt-1.9.0.ebuild => libgcrypt-1.9.1.ebuild} | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-)
