I don't know if this started to happen after I updated to FreeBSD 14.1
on my RPi4B, but libgcrypt crashes with a SIGILL in
detect_arm_hwf_by_toolchain on line 527 when trying to run the assembly
code there. As a result, I cannot use gnupg either. I asked about this
in one of the FreeBSD IRC channels and this was the conversation about
it:
[07/09/2024 10:33:10 -4] <CBX-AWAY> So I build all my packages for my
RPi4 via poudriere with CPUTYPE set to cortex-a72, and now for some
reason, gpg2 crashes in libgcrypt when trying to run the asm to detect
CPU features, specifically with a SIGILL: illegal trap. Specifically it
crashes at this line:
https://fossies.org/dox/libgcrypt-1.11.0/hwf-arm_8c_source.html#l00527
[07/09/2024 10:35:01 -4] <@fuz> ouch
[07/09/2024 10:35:25 -4] <@fuz> CBX-AWAY: that's a crypto instruction,
they're optional on the A72 and the rpi4 doesn't have them
[07/09/2024 10:36:37 -4] <CBX-AWAY> That is an ouch indeed. Now I wonder
what I can do about it, if there is even anything I can do about it.
[07/09/2024 10:37:33 -4] <@fuz> not sure
[07/09/2024 10:42:05 -4] <jhibbits> Is there a compiler flag to disable
crypto?
[07/09/2024 10:42:29 -4] <@fuz> jhibbits: by default it's not enabled
[07/09/2024 10:42:37 -4] <@fuz> you have to add +crypto to enable it
[07/09/2024 10:42:40 -4] <jhibbits> ah
[07/09/2024 10:43:26 -4] <jhibbits> So libgcrypt assumes that it's
enabled, or tries to use a SIGILL handler to confirm?
[07/09/2024 10:44:15 -4] <@fuz> the code linked looks like it exercises
the assembler
[07/09/2024 10:44:22 -4] <@fuz> to check if the mnemonics are supported
[07/09/2024 10:44:54 -4] <jhibbits> That code is all sorts of wrong
[07/09/2024 10:56:42 -4] <jhibbits> OR-ing in all options supported by
the compiler, whether supported by the hardware or not, is very wrong.
[07/09/2024 10:57:33 -4] <jhibbits> CBX-AWAY: you should file a bug with
libgcrypt to fix that brokenness
[07/09/2024 10:57:38 -4] <@fuz> jhibbits: if you build for a
distribution, it makes sense to build a binary that can use all features
the compiler supports, so you can select at runtime what you need.
[07/09/2024 10:58:15 -4] <jhibbits> fuz: yes, but this is a runtime file
[07/09/2024 10:59:33 -4] <jhibbits> fuz: it's explicitly ORing in all
compiler-supported features, whether supported by the hardware (via
HW_CAP or /proc/cpuinfo, or sysctl).
[07/09/2024 10:59:42 -4] <jhibbits> It should be taking a subset of
those.
[07/09/2024 11:03:19 -4] <@fuz> ok that's weird
[07/09/2024 11:03:26 -4] <@fuz> though on freebsd we only support HW_CAP
[07/09/2024 11:03:35 -4] <@fuz> and reading the special registers
directly
[07/09/2024 11:03:46 -4] <@fuz> so idk what other data sources there are
[07/09/2024 11:04:07 -4] <jhibbits> That's all that should be needed
[07/09/2024 11:04:48 -4] <jhibbits> That detect_arm_hwf_by_toolchain()
is severely broken, and shouldn't exist.
I'm not sure what the actual fix is for this, and I cannot post this to
the GnuPG issue tracker as I don't have an account and registration
there is disabled. If it would be better for me to post this on the
issue tracker, then for my account, I'd like the handle CyberBotX, my
shown name as Naram Qashat, and my email address as
cyberb...@cyberbotx.com.
Thanks in advance,
Naram "CyberBotX" Qashat
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
