Hi folks,
Not sure if this is intended behaviour or not...
The use of Intel Control-flow Enforcement Technology (CET) in OpenSSL 3.0.2 is giving me issues on a VIA C3 Nehemiah based system. Turns out that while the VIA C3 Nehemiah is a i686 class x86 processor, it does not implement all the nop opcodes added in the Pentium Pro. So I get 'Illegal instruction' when trying to run OpenSSL programs due to the presence of the endbr32 instructions:
$ LD_LIBRARY_PATH=`pwd` apps/openssl version
Illegal instruction
Testing with the endbr32 generation in crypto/perlasm/x86asm.pl commented out generates a working binary:
Not sure if this is intended behaviour or not...
The use of Intel Control-flow Enforcement Technology (CET) in OpenSSL 3.0.2 is giving me issues on a VIA C3 Nehemiah based system. Turns out that while the VIA C3 Nehemiah is a i686 class x86 processor, it does not implement all the nop opcodes added in the Pentium Pro. So I get 'Illegal instruction' when trying to run OpenSSL programs due to the presence of the endbr32 instructions:
$ LD_LIBRARY_PATH=`pwd` apps/openssl version
Illegal instruction
Testing with the endbr32 generation in crypto/perlasm/x86asm.pl commented out generates a working binary:
$ LD_LIBRARY_PATH=`pwd` apps/openssl version -a
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
built on: Sat Apr 30 10:20:30 2022 UTC
platform: linux-x86
options: bn(64,32)
compiler: gcc -fPIC -pthread -m32 -Wa,--noexecstack -Wall -O3 -fomit-frame-pointer -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG
OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/lib/engines-3"
MODULESDIR: "/usr/local/lib/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0x381bf3f:0x0
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
built on: Sat Apr 30 10:20:30 2022 UTC
platform: linux-x86
options: bn(64,32)
compiler: gcc -fPIC -pthread -m32 -Wa,--noexecstack -Wall -O3 -fomit-frame-pointer -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG
OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/lib/engines-3"
MODULESDIR: "/usr/local/lib/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0x381bf3f:0x0
From a bit of experimentation it appears that the endbr32 instruction is always included in the generated x86 32-bit assembler code, even when using the 386 assembler option.
So, not sure if OpenSSL is dropping support for older 32-bit x86 processors, and the documentation hasn't caught up, or if this is just an oversight?
FWIW the gcc folks have limited generation of endbr32 instructions to at least i686 (cmov) and SSE2 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667), to limit the use of the endbr32 instruction to target systems where it is handled as a nop.
All the best,
Hamish
