Re: SIGILL in detect_arm_hwf_by_toolchain under FreeBSD arm64 on a Raspberry Pi 4B

Hello,

On 2024-07-10 12:39, Jussi Kivilinna wrote:
> Hello,
> 
> On 9.7.2024 20.49, Naram Qashat via Gcrypt-devel wrote:
>> 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:
> 
> Looking at documentation for __ARM_FEATURE_CRYPTO 
> (https://github.com/ARM-software/acle/releases/download/r2024Q2/acle-2024Q2.pdf):
> 
> "__ARM_FEATURE_CRYPTO is defined to 1 if the Armv8-A Crypto 
> instructions are supported and intrinsics targeting them are available. 
> These instructions include AES{E, D}, SHA1{C, P, M} and others. This 
> also implies __ARM_FEATURE_AES and __ARM_FEATURE_SHA2."
> 
> And as __ARM_FEATURE_AES is implied:
> 
> "__ARM_FEATURE_AES is defined to 1 if there is hardware support for the 
> Advanced SIMD AES Crypto instructions from Armv8-A ..."
> 
> Based on this, libgcrypt has been compiled using CPU target that 
> supports crypto-extensions, but actually HW does not support. Did you 
> use "-mcpu=cortex-a72" for compiler flags to select CPU type? If 
> compiler is enabling crypto-extensions for "-mcpu=cortex-a72" and 
> crypto-extensions are actually optional for Cortex-A72 then bug must be 
> in compiler... "-mcpu=cortex-a72" setting should not be selecting 
> optional crypto-extensions by default. Which compiler are you using? 
> GCC or clang or something else? Which version?

I am using -mcpu=cortex-a72 in my compiler flags. From what I've read 
recently, the Raspberry Pi 4B, despite running a Cortex-A72, the SoC 
being used done not have the crypto extensions at all. I don't think it 
is a compiler bug, but rather just the hardware excluding the feature.

I am using clang version 18.1.5 from FreeBSD's base system.

libcrypt was specifically built through FreeBSD's ports tree instead of 
the poudriere package builder, but I don't think that has anything to do 
with this as the file with the relevant function is still the same as 
upstream's 1.11.0.

Another thing I read is that code doing this should be attempting to 
catch the SIGILL signal when trying to check for the crypto extensions 
that don't exist. In a way, I agree with jhibbits that the code in 
libgcrypt needs fixing.

Thanks,
Naram Qashat

> -Jussi
> 
>> 
>> [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 
>> [email protected].
>> 
>> Thanks in advance,
>> Naram "CyberBotX" Qashat
>> 
>> _______________________________________________
>> Gcrypt-devel mailing list
>> [email protected]
>> https://lists.gnupg.org/mailman/listinfo/gcrypt-devel