dnf crashes due a SIGILL from libcrypto on our Power8 system. I guess some algorithm is built for a later generation of Power CPU/ISA. Apr 11 12:33:13 tyan-openpower-01.lab.eng.brq2.redhat.com systemd-coredump[1797459]: Process 1797453 (dnf) of user 0 terminated abnormally with signal 4/ILL, processing... Apr 11 12:33:13 tyan-openpower-01.lab.eng.brq2.redhat.com kernel: dnf[1797453]: illegal instruction (4) at 7fff9ee95424 nip 7fff9ee95424 lr 7fff9ee9633c code 1 in libcrypto.so.3.5.0[3b5424,> Apr 11 12:33:13 tyan-openpower-01.lab.eng.brq2.redhat.com kernel: dnf[1797453]: code: e8e40008 e9040010 e9240018 e9440020 e9640028 e9840030 100004c4 7dc631d2 Apr 11 12:33:13 tyan-openpower-01.lab.eng.brq2.redhat.com kernel: dnf[1797453]: code: 7de63012 f9c30000 f9e30008 7dc63214 <7da07367> 7dc03b67 102d7023 7de77367 openssl-3.5.0-2.fc43.ppc64le Reproducible: Always
Could you please report this issue upstream? Our downstream patches don't touch assembler code
ack, will do
*** Bug 2359744 has been marked as a duplicate of this bug. ***
Could you please try this build if the infrastructure wakes up https://koji.fedoraproject.org/koji/taskinfo?taskID=131563912
no more a SIGILL as far as I can tell, what change did you made?
A build without this flag "enable-ec_nistp_64_gcc_128", as proposed in https://github.com/openssl/openssl/issues/27350 If you have anyone who knows ppc64le asm, it would be great to implement a proper fix - otherwise it would stay vulnerable to side-channel attacks (fixing them introduced this issue)
FEDORA-2025-c31309a82b (openssl-3.5.0-3.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-c31309a82b
(In reply to Dmitry Belyavskiy from comment #6) > A build without this flag "enable-ec_nistp_64_gcc_128", as proposed in > https://github.com/openssl/openssl/issues/27350 for the record, we need this change only in Fedora, RHEL 9+ requires Power9 or newer, so it's safe with the new implementation > If you have anyone who knows ppc64le asm, it would be great to implement a > proper fix - otherwise it would stay vulnerable to side-channel attacks > (fixing them introduced this issue) I will ask in the community, but it will be tough as it needs both Power ISA and security expertise ... And as I am not familiar with OpenSSL code, do you think it's possible to change OpenSSL in a way that the new safe implementation would be selected during runtime when Power9+ CPU is detected and and the unsafe one for Power8 (it's EOL hw anyway)? I believe OpenSSL is generally capable of such runtime selection.
Probably this check should be made more strict: if (OPENSSL_ppccap_P & PPC_MADD300) see man openssl-env for slightly more details
FEDORA-2025-c31309a82b (openssl-3.5.0-3.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.