From cyberbotx at cyberbotx.com Tue Jul 9 19:49:40 2024 From: cyberbotx at cyberbotx.com (Naram Qashat) Date: Tue, 09 Jul 2024 13:49:40 -0400 Subject: SIGILL in detect_arm_hwf_by_toolchain under FreeBSD arm64 on a Raspberry Pi 4B Message-ID: <70f021be09c407391347b40a8911e994@cyberbotx.com> 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] 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] 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] 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] ah [07/09/2024 10:43:26 -4] 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] That code is all sorts of wrong [07/09/2024 10:56:42 -4] 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] 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] fuz: yes, but this is a runtime file [07/09/2024 10:59:33 -4] 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] 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] That's all that should be needed [07/09/2024 11:04:48 -4] 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 cyberbotx at cyberbotx.com. Thanks in advance, Naram "CyberBotX" Qashat From jussi.kivilinna at iki.fi Wed Jul 10 18:39:06 2024 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Wed, 10 Jul 2024 19:39:06 +0300 Subject: SIGILL in detect_arm_hwf_by_toolchain under FreeBSD arm64 on a Raspberry Pi 4B In-Reply-To: <70f021be09c407391347b40a8911e994@cyberbotx.com> References: <70f021be09c407391347b40a8911e994@cyberbotx.com> Message-ID: <9a56b613-9c22-452c-ab1b-aa27b0b6fb47@iki.fi> 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? -Jussi > > [07/09/2024 10:33:10 -4] 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] 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] 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] ah > [07/09/2024 10:43:26 -4] 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] That code is all sorts of wrong > [07/09/2024 10:56:42 -4] 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] 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] fuz: yes, but this is a runtime file > [07/09/2024 10:59:33 -4] 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] 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] That's all that should be needed > [07/09/2024 11:04:48 -4] 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 cyberbotx at cyberbotx.com. > > Thanks in advance, > Naram "CyberBotX" Qashat > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gcrypt-devel From jussi.kivilinna at iki.fi Wed Jul 10 19:37:41 2024 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Wed, 10 Jul 2024 20:37:41 +0300 Subject: SIGILL in detect_arm_hwf_by_toolchain under FreeBSD arm64 on a Raspberry Pi 4B In-Reply-To: <9a56b613-9c22-452c-ab1b-aa27b0b6fb47@iki.fi> References: <70f021be09c407391347b40a8911e994@cyberbotx.com> <9a56b613-9c22-452c-ab1b-aa27b0b6fb47@iki.fi> Message-ID: <39237343-9290-4eed-9529-e5734ac01117@iki.fi> On 10.7.2024 19.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 found this LLVM bug, Cortex-A72 defaults are wrong there: https://github.com/llvm/llvm-project/issues/85699 Looking at GCC documentation, GCC "-mcpu=cortex-a72" does not enable crypto extensions by default. Instead one needs "-mcpu=cortex-a72+crypto" to enable CE with A72. https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html -Jussi From cyberbotx at cyberbotx.com Wed Jul 10 18:49:47 2024 From: cyberbotx at cyberbotx.com (Naram Qashat) Date: Wed, 10 Jul 2024 12:49:47 -0400 Subject: SIGILL in detect_arm_hwf_by_toolchain under FreeBSD arm64 on a Raspberry Pi 4B In-Reply-To: <9a56b613-9c22-452c-ab1b-aa27b0b6fb47@iki.fi> References: <70f021be09c407391347b40a8911e994@cyberbotx.com> <9a56b613-9c22-452c-ab1b-aa27b0b6fb47@iki.fi> Message-ID: <47864137a96a1fac06c477508022e8c3@cyberbotx.com> 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] 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] 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] 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] ah >> [07/09/2024 10:43:26 -4] 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] That code is all sorts of wrong >> [07/09/2024 10:56:42 -4] 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] 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] fuz: yes, but this is a runtime >> file >> [07/09/2024 10:59:33 -4] 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] 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] That's all that should be needed >> [07/09/2024 11:04:48 -4] 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 >> cyberbotx at cyberbotx.com. >> >> Thanks in advance, >> Naram "CyberBotX" Qashat >> >> _______________________________________________ >> Gcrypt-devel mailing list >> Gcrypt-devel at gnupg.org >> https://lists.gnupg.org/mailman/listinfo/gcrypt-devel From jussi.kivilinna at iki.fi Wed Jul 10 20:28:32 2024 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Wed, 10 Jul 2024 21:28:32 +0300 Subject: SIGILL in detect_arm_hwf_by_toolchain under FreeBSD arm64 on a Raspberry Pi 4B In-Reply-To: <47864137a96a1fac06c477508022e8c3@cyberbotx.com> References: <70f021be09c407391347b40a8911e994@cyberbotx.com> <9a56b613-9c22-452c-ab1b-aa27b0b6fb47@iki.fi> <47864137a96a1fac06c477508022e8c3@cyberbotx.com> Message-ID: On 10.7.2024 19.49, Naram Qashat via Gcrypt-devel wrote: > 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 think this LLVM issue and comments there give some background on CPU feature selection for clang on ARM: https://github.com/llvm/llvm-project/issues/90365 https://github.com/llvm/llvm-project/issues/90365#issuecomment-2117644294 > > 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. > No need for SIGILL checks, toolchain configuration (mcpu setting in this case) needs to be such that compiler does not indicate crypto-extension instruction support. Inline assembly code in "src/hwf-arm.c" is exactly for detecting these kind of configuration errors, having compiler indicate support for instruction sets that are not actually supported by target HW. Anyway, you need to use "-mcpu=cortex-a72+nocrypto" with clang when targeting build for RPi 4B. -Jussi From finalcountdown72 at googlemail.com Sat Jul 13 22:51:54 2024 From: finalcountdown72 at googlemail.com (Hendi) Date: Sat, 13 Jul 2024 22:51:54 +0200 Subject: Build system --enable options Message-ID: <75667cc0-d74e-46e3-9cb1-3ce5f2b9a066@googlemail.com> Hi, I want to build a minimal libgcrypt for a resource-starved embedded system. The configure script offers various options such as --enable-digest, --enable-kdfs, etc., however there are two problems: * It doesn't seem possible to enable nothing, as an empty string is interpreted as "everything". In particular, if I specify?--enable-kdfs="", I get all KDF algorithms. * It's impossible to build libgcrypt with only sha1 and sha256, as this causes a linking failure. With the current code base, sha512, sha3 and blake2 are mandatory. It would also be great if the KEM stuff that was added recently could be disabled with a compile-time flag, as the Poly1305/McEliece/Kyber algorithms take dozens of kilobytes in the library. Best regards, Hendi From jussi.kivilinna at iki.fi Sun Jul 28 18:50:56 2024 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sun, 28 Jul 2024 19:50:56 +0300 Subject: [PATCH 1/5] asm-common-amd64: add missing CFI directives for large memory model code Message-ID: <20240728165100.883727-1-jussi.kivilinna@iki.fi> * cipher/asm-common-amd64.h [__code_model_large__] (GET_EXTERN_POINTER): Add CFI_PUSH/CFI_POP directives. -- Signed-off-by: Jussi Kivilinna --- cipher/asm-common-amd64.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/cipher/asm-common-amd64.h b/cipher/asm-common-amd64.h index 870fef9a..3fa065e8 100644 --- a/cipher/asm-common-amd64.h +++ b/cipher/asm-common-amd64.h @@ -59,14 +59,18 @@ # ifdef __code_model_large__ # define GET_EXTERN_POINTER(name, reg) \ pushq %r15; \ + CFI_PUSH(%r15); \ pushq %r14; \ + CFI_PUSH(%r14); \ 1: leaq 1b(%rip), reg; \ movabsq $_GLOBAL_OFFSET_TABLE_-1b, %r14; \ movabsq $name at GOT, %r15; \ addq %r14, reg; \ popq %r14; \ + CFI_POP(%r14); \ movq (reg, %r15), reg; \ - popq %r15; + popq %r15; \ + CFI_POP(%r15); # else # define GET_EXTERN_POINTER(name, reg) movq name at GOTPCREL(%rip), reg # endif -- 2.43.0 From jussi.kivilinna at iki.fi Sun Jul 28 18:50:59 2024 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sun, 28 Jul 2024 19:50:59 +0300 Subject: [PATCH 4/5] Add CET support for x86-64 assembly In-Reply-To: <20240728165100.883727-1-jussi.kivilinna@iki.fi> References: <20240728165100.883727-1-jussi.kivilinna@iki.fi> Message-ID: <20240728165100.883727-4-jussi.kivilinna@iki.fi> * cipher/asm-common-amd64.h (ENDBRANCH): New. (CFI_STARTPROC): Add ENDBRANCH. [__CET__] (note.gnu.property): Add CET property section. -- GnuPG-bug-id: 7220 Signed-off-by: Jussi Kivilinna --- cipher/asm-common-amd64.h | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/cipher/asm-common-amd64.h b/cipher/asm-common-amd64.h index 3fa065e8..465ef62b 100644 --- a/cipher/asm-common-amd64.h +++ b/cipher/asm-common-amd64.h @@ -76,9 +76,15 @@ # endif #endif +#ifdef __CET__ +#define ENDBRANCH endbr64 +#else +#define ENDBRANCH /*_*/ +#endif + #ifdef HAVE_GCC_ASM_CFI_DIRECTIVES /* CFI directives to emit DWARF stack unwinding information. */ -# define CFI_STARTPROC() .cfi_startproc +# define CFI_STARTPROC() .cfi_startproc; ENDBRANCH # define CFI_ENDPROC() .cfi_endproc # define CFI_REMEMBER_STATE() .cfi_remember_state # define CFI_RESTORE_STATE() .cfi_restore_state @@ -146,7 +152,7 @@ DW_SLEB128_28BIT(rsp_offs) #else -# define CFI_STARTPROC() +# define CFI_STARTPROC() ENDBRANCH # define CFI_ENDPROC() # define CFI_REMEMBER_STATE() # define CFI_RESTORE_STATE() @@ -214,4 +220,24 @@ vpopcntb xmm16, xmm16; /* Supported only by newer AVX512 CPUs. */ \ vpxord ymm16, ymm16, ymm16; +#ifdef __CET__ +/* Generate CET property for all assembly files including this header. */ +ELF(.section .note.gnu.property,"a") +ELF(.align 8) +ELF(.long 1f - 0f) +ELF(.long 4f - 1f) +ELF(.long 5) +ELF(0:) +ELF(.byte 0x47, 0x4e, 0x55, 0) /* string "GNU" */ +ELF(1:) +ELF(.align 8) +ELF(.long 0xc0000002) +ELF(.long 3f - 2f) +ELF(2:) +ELF(.long 0x3) +ELF(3:) +ELF(.align 8) +ELF(4:) +#endif + #endif /* GCRY_ASM_COMMON_AMD64_H */ -- 2.43.0 From jussi.kivilinna at iki.fi Sun Jul 28 18:50:57 2024 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sun, 28 Jul 2024 19:50:57 +0300 Subject: [PATCH 2/5] Do not build i386 assembly on x86-64 In-Reply-To: <20240728165100.883727-1-jussi.kivilinna@iki.fi> References: <20240728165100.883727-1-jussi.kivilinna@iki.fi> Message-ID: <20240728165100.883727-2-jussi.kivilinna@iki.fi> * configure.ac: Enable building i386 "rijndael-vaes" only on i?86 host instead of x86 MPI arch ("i?86 + x86-64"). -- GnuPG-bug-id: 7220 Signed-off-by: Jussi Kivilinna --- configure.ac | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index d3dffb4b..1e182552 100644 --- a/configure.ac +++ b/configure.ac @@ -3025,6 +3025,11 @@ if test "$found" = "1" ; then AC_DEFINE(USE_AES, 1, [Defined if this module should be included]) case "${host}" in + i?86-*-*) + # Build with the VAES/AVX2 implementation + GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS rijndael-vaes-i386.lo" + GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS rijndael-vaes-avx2-i386.lo" + ;; x86_64-*-*) # Build with the assembly implementation GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS rijndael-amd64.lo" @@ -3089,10 +3094,6 @@ if test "$found" = "1" ; then # Build with the Padlock implementation GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS rijndael-padlock.lo" - - # Build with the VAES/AVX2 implementation - GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS rijndael-vaes-i386.lo" - GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS rijndael-vaes-avx2-i386.lo" ;; esac fi -- 2.43.0 From jussi.kivilinna at iki.fi Sun Jul 28 18:51:00 2024 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sun, 28 Jul 2024 19:51:00 +0300 Subject: [PATCH 5/5] Add CET support for i386 assembly In-Reply-To: <20240728165100.883727-1-jussi.kivilinna@iki.fi> References: <20240728165100.883727-1-jussi.kivilinna@iki.fi> Message-ID: <20240728165100.883727-5-jussi.kivilinna@iki.fi> * cipher/asm-common-i386.h (ENDBRANCH): New. (CFI_STARTPROC): Add ENDBRANCH. [__CET__] (note.gnu.property): Add CET property section. -- GnuPG-bug-id: 7220 Signed-off-by: Jussi Kivilinna --- cipher/asm-common-i386.h | 30 ++++++++++++++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/cipher/asm-common-i386.h b/cipher/asm-common-i386.h index d746ebc4..346a8ff2 100644 --- a/cipher/asm-common-i386.h +++ b/cipher/asm-common-i386.h @@ -59,9 +59,15 @@ movl name##@GOT(%reg), %reg; #endif +#ifdef __CET__ +#define ENDBRANCH endbr32 +#else +#define ENDBRANCH /*_*/ +#endif + #ifdef HAVE_GCC_ASM_CFI_DIRECTIVES /* CFI directives to emit DWARF stack unwinding information. */ -# define CFI_STARTPROC() .cfi_startproc +# define CFI_STARTPROC() .cfi_startproc; ENDBRANCH # define CFI_ENDPROC() .cfi_endproc # define CFI_REMEMBER_STATE() .cfi_remember_state # define CFI_RESTORE_STATE() .cfi_restore_state @@ -121,7 +127,7 @@ DW_SLEB128_28BIT(esp_offs) #else -# define CFI_STARTPROC() +# define CFI_STARTPROC() ENDBRANCH # define CFI_ENDPROC() # define CFI_REMEMBER_STATE() # define CFI_RESTORE_STATE() @@ -158,4 +164,24 @@ vpopcntb xmm7, xmm7; /* Supported only by newer AVX512 CPUs. */ \ vpxord ymm7, ymm7, ymm7; +#ifdef __CET__ +/* Generate CET property for all assembly files including this header. */ +ELF(.section .note.gnu.property,"a") +ELF(.align 4) +ELF(.long 1f - 0f) +ELF(.long 4f - 1f) +ELF(.long 5) +ELF(0:) +ELF(.byte 0x47, 0x4e, 0x55, 0) /* string "GNU" */ +ELF(1:) +ELF(.align 4) +ELF(.long 0xc0000002) +ELF(.long 3f - 2f) +ELF(2:) +ELF(.long 0x3) +ELF(3:) +ELF(.align 4) +ELF(4:) +#endif + #endif /* GCRY_ASM_COMMON_AMD64_H */ -- 2.43.0 From jussi.kivilinna at iki.fi Sun Jul 28 18:50:58 2024 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sun, 28 Jul 2024 19:50:58 +0300 Subject: [PATCH 3/5] Do not build amd64 assembly on i386 In-Reply-To: <20240728165100.883727-1-jussi.kivilinna@iki.fi> References: <20240728165100.883727-1-jussi.kivilinna@iki.fi> Message-ID: <20240728165100.883727-3-jussi.kivilinna@iki.fi> * configure.ac: Build "serpent-avx2-amd64" and "camellia-*-amd64" only on x86-64. -- GnuPG-bug-id: 7220 Signed-off-by: Jussi Kivilinna --- configure.ac | 50 +++++++++++++++++++++++++++----------------------- 1 file changed, 27 insertions(+), 23 deletions(-) diff --git a/configure.ac b/configure.ac index 1e182552..191aa38d 100644 --- a/configure.ac +++ b/configure.ac @@ -3133,14 +3133,14 @@ if test "$found" = "1" ; then x86_64-*-*) # Build with the SSE2 implementation GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS serpent-sse2-amd64.lo" + + if test x"$avx2support" = xyes ; then + # Build with the AVX2 implementation + GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS serpent-avx2-amd64.lo" + fi ;; esac - if test x"$avx2support" = xyes ; then - # Build with the AVX2 implementation - GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS serpent-avx2-amd64.lo" - fi - if test x"$avx512support" = xyes ; then # Build with the AVX512 implementation GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS serpent-avx512-x86.lo" @@ -3186,28 +3186,32 @@ if test "$found" = "1" ; then ;; esac - if test x"$avxsupport" = xyes ; then - if test x"$aesnisupport" = xyes ; then - # Build with the AES-NI/AVX implementation - GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS camellia-aesni-avx-amd64.lo" - fi - fi + case "${host}" in + x86_64-*-*) + if test x"$avxsupport" = xyes ; then + if test x"$aesnisupport" = xyes ; then + # Build with the AES-NI/AVX implementation + GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS camellia-aesni-avx-amd64.lo" + fi + fi - if test x"$avx2support" = xyes ; then - if test x"$aesnisupport" = xyes ; then - # Build with the AES-NI/AVX2 implementation - GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS camellia-aesni-avx2-amd64.lo" + if test x"$avx2support" = xyes ; then + if test x"$aesnisupport" = xyes ; then + # Build with the AES-NI/AVX2 implementation + GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS camellia-aesni-avx2-amd64.lo" - # Build with the VAES/AVX2 implementation - GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS camellia-vaes-avx2-amd64.lo" + # Build with the VAES/AVX2 implementation + GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS camellia-vaes-avx2-amd64.lo" - # Build with the GFNI/AVX2 implementation - GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS camellia-gfni-avx2-amd64.lo" + # Build with the GFNI/AVX2 implementation + GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS camellia-gfni-avx2-amd64.lo" - # Build with the GFNI/AVX512 implementation - GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS camellia-gfni-avx512-amd64.lo" - fi - fi + # Build with the GFNI/AVX512 implementation + GCRYPT_ASM_CIPHERS="$GCRYPT_ASM_CIPHERS camellia-gfni-avx512-amd64.lo" + fi + fi + ;; + esac fi LIST_MEMBER(idea, $enabled_ciphers) -- 2.43.0