Description of problem: Got a new laptop about a month ago, and strangely enough I am finding ssh <some_place_I_log_in_often> fails with "kexecdh_client: EC_KEY_generate_key failed" occasionally. Normal unencrypted networking works alright. After a while a pattern seems to emerge - it is when after I have suspended and resumed. This is very strange as suspend/resume affects hardware but ssh is a software. So my suspicion is either the network hardware or the encryption coprocessor: $ lspci | grep Network 03:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01) $ lspci | grep Enc 00:08.0 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 1537 So I tried modprobe -r those and modprobe again, but ssh still won't work. I also found once that trying to generate openssl certificates - like the kernel module signing (# openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \ -config x509.genkey -outform DER -out signing_key.x509 \ -keyout signing_key.priv ) also fails after suspend/resume. Would really appreciate help in diagnose this further, as not having ssh after a suspend/resume basically means suspend/resume is no longer useful as a way of continuing work. Version-Release number of selected component (if applicable): openssh-6.4p1-5.fc20.x86_64 kernel-3.16.3-200.local2.fc20.x86_64 (it is mostly the same as 3.16.3-200.fc20.x86_64, except with the addition of https://bugzilla.kernel.org/show_bug.cgi?id=71051#c8 ) How reproducible: Always, on this hardware. Steps to Reproduce: 1. suspend/resume 2. ssh someplace with existing authentication set-up. 3. Actual results: "kexecdh_client: EC_KEY_generate_key failed" Expected results: sucessful log-in. Additional info: Googling around, I found another person with a similar problem: https://bbs.archlinux.org/viewtopic.php?id=170869
Created attachment 944743 [details] lsmod Just in case it matters, here is lsmod output. Besides the wifi device and the encryption coprocessor (ath9k and ccp), I also wonder about the kernel random number source, but not sure how to reload that. This is probably a kernel bug, but I probably need some more ssh diagnostics to see which part.
This really looks like a kernel bug. Can you attach the output of 'cat /proc/cpuinfo' ?
Created attachment 944940 [details] cat /proc/cpuinfo cat /proc/cpuinfo The 'cpu MHz' changes slight on consecutive runs (before/after suspend): # diff -u cpuinfo1 cpuinfo2 --- cpuinfo1 2014-10-08 11:42:56.774106903 +0100 +++ cpuinfo2 2014-10-08 11:46:18.248219634 +0100 @@ -5,7 +5,7 @@ model name : AMD A4-6210 APU with AMD Radeon R3 Graphics stepping : 1 microcode : 0x7030105 -cpu MHz : 1000.000 +cpu MHz : 1200.000 cache size : 2048 KB physical id : 0 siblings : 4 @@ -59,7 +59,7 @@ model name : AMD A4-6210 APU with AMD Radeon R3 Graphics stepping : 1 microcode : 0x7030105 -cpu MHz : 1800.000 +cpu MHz : 1000.000 cache size : 2048 KB physical id : 0 siblings : 4
I also tried 'systemctl start sshd.service' as root and 'ssh localhost'; done it twice with two different results. If I have never don't sshd.service before since boot, 'systemctl start sshd.service' fails, with this repeats over and over: ------ Oct 8 11:30:43 localhost systemd: Starting OpenSSH server daemon... Oct 8 11:30:43 localhost gnome-session: Gjs-Message: JS LOG: error reading: /sys/devices/virtual/thermal/thermal_zone0/temp Oct 8 11:30:43 localhost sshd-keygen: Generating SSH2 RSA host key: [FAILED] Oct 8 11:30:43 localhost systemd: sshd.service: control process exited, code=exited status=1 Oct 8 11:30:43 localhost systemd: Failed to start OpenSSH server daemon. Oct 8 11:30:43 localhost systemd: Unit sshd.service entered failed state. Oct 8 11:30:43 localhost dbus-daemon: dbus[782]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Oct 8 11:30:43 localhost dbus[782]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Oct 8 11:30:46 localhost dbus-daemon: dbus[782]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Oct 8 11:30:46 localhost dbus[782]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Oct 8 11:30:48 localhost setroubleshoot: Plugin Exception restorecon Oct 8 11:30:48 localhost setroubleshoot: Plugin Exception restorecon_source Oct 8 11:30:48 localhost setroubleshoot: SELinux is preventing /usr/bin/bash from execute access on the file . For complete SELinux messages. run sealert -l 84ab82ab-b8f3-468b-b64b-abc4f93ace17 Oct 8 11:30:48 localhost python: SELinux is preventing /usr/bin/bash from execute access on the file . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that bash should be allowed execute access on the file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep sshd-keygen /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Oct 8 11:30:57 localhost dbus-daemon: string index out of range Oct 8 11:30:57 localhost dbus-daemon: 'list' object has no attribute 'split' holdoff time over, scheduling restart. Oct 8 11:31:25 localhost systemd: Stopping OpenSSH server daemon... Oct 8 11:31:25 localhost systemd: Starting OpenSSH server daemon... ---------- I could do /usr/sbin/sshd -D -d, but then 'ssh localhost' gives 'connection reset by peer'. If I had done 'systemctl start sshd.service' before suspend, starting/stopping the deamon also works after suspend; but then 'ssh localhost' fails with the usual "kexecdh_client: EC_KEY_generate_key failed" . So I have two observations to make: - it seems that it is key generation which stops working after suspend. If I do it before (for sshd) then the sshd deamon continues to work, at least. (I haven't tried connecting from outside yet). - at least we have eliminated the wifi network driver, since I am not going via it with 'ssh localhost', I think.
Can you try running ssh with export OPENSSL_ia32cap=~0x4000000000000000 This disables the rdrand support. Or if that does not help could you try with other OPENSSL_ia32cap values starting with OPENSSL_ia32cap=0?
(In reply to Tomas Mraz from comment #5) > Can you try running ssh with > > export OPENSSL_ia32cap=~0x4000000000000000 brilliant. This works. ---- [Hin-Tak@localhost ~]$ OPENSSL_ia32cap=~0x4000000000000000 ssh hintak@elsewhere Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-35-generic i686) ... hintak@elsewhere:~$ exit logout Connection to elsewhere closed. [Hin-Tak@localhost ~]$ ssh hintak@elsewhere kexecdh_client: EC_KEY_generate_key failed [Hin-Tak@localhost ~]$ ---- So I now have a work around, at least.
Read up on rdrand - so this is likely a hardware/kernel bug or hardware fault that needs a kernel workaround then?
Yes.
Please re-assign and/or do whatever necessarily to get this prob to the right people then...
Please attach the output of dmesg from a fresh boot, followed by the output after a suspend/resume cycle and a failed ssh login.
Created attachment 944986 [details] dmesg Here it is - my current dmesg. In my current boot session, I did start sshd before, so sshd continues to start/stop via systemctl. behavior as client is as described - ssh account@elsewhere fail with 'kexecdh_client: EC_KEY_generate_key failed', "OPENSSL_ia32cap=~0x4000000000000000 ssh account@elsewher" works. There is no extra dmesg lines from running either the client or starting/stopping the server in dmesg. It is a slightly customized kernel described in: https://bugzilla.kernel.org/show_bug.cgi?id=85421 The extra patches are radeon related; otherwise it is essentially just rebuilding the koji srpm.
(In reply to Hin-Tak Leung from comment #11) > It is a slightly customized kernel described in: > https://bugzilla.kernel.org/show_bug.cgi?id=85421 Oh, just to add to myself - using an unmod'ed fedora kernel isn't an option in this case, since my graphic card doesn't suspend/resume correctly without the patch and it stays blank, so I don't get a usable machine *at all* after suspend/resume with an unmod'ed fedora kernel. I did think about upgrading to a rawhide one, since the graphic card patch is in 3.17-rcX .
Oh, the genkey part of kernel module signing in rpmbuild --rebuild kernel srpm also fails after suspend/resume, but then I already mentioned that briefly at the beginning. I'd be happy to try any kernel patches, since I am already adding a couple of extra patches for my graphic card in rebuilding the kernel srpm. (turn around won't be fast though, since it takes just under 4 hours to do that...)
Filed upstream bug. I am fine with either upstream pushing a fix down, or the fedora people fixing it and pushing a fix up...
The error message from running the module signing key of kernel build is: Generating a 4096 bit RSA private key .Error Generating Key 48012007979840:error:0307A071:bignum routines:BN_rand_range:too many iterations:bn_rand.c:269: 48012007979840:error:04081003:rsa routines:RSA_BUILTIN_KEYGEN:BN lib:rsa_gen.c:515: make[1]: *** [signing_key.x509] Error 1 make: *** [kernel] Error 2
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
(In reply to Justin M. Forbes from comment #16) ... > Fedora 20 has now been rebased to 3.17.2-200.fc20. ... Still a problem with 3.17.2-200.fc20
still a problem with 3.17.3-200.fc20.x86_64 . Also, it seems to get worse; maybe it is the newer wget (wget-1.16-3.fc20.x86_64 I got a few days ago), maybe I just haven't used wget that way, but it is also affecting "wget https://..." now. e.g. $ wget -m https://gmplib.org/~tege/x86-timing.pdf --2014-11-22 23:25:00-- https://gmplib.org/~tege/x86-timing.pdf Resolving gmplib.org (gmplib.org)... 37.252.124.96 Connecting to gmplib.org (gmplib.org)|37.252.124.96|:443... connected. OpenSSL: error:0307A071:bignum routines:BN_rand_range:too many iterations OpenSSL: error:1409802B:SSL routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:reason(43) Unable to establish SSL connection.
I don't know what changed, but I just upgraded from fedora 20 to fedora 21 yesterday, and therefore switching from 3.17.6-200.fc20.x86_64 to 3.17.6-300.fc21.x86_64 , and both ssh and generating the module signing key of kernel build also start to work. As it happened, I have started to script/alias wget to always have OPENSSL_ia32cap=~0x4000000000000000 yesterday merely 1/2 a day before upgrading, so it definitely did not work merely 10 hours before I booted f21 for the first time. This can be closed, I think, though I would like to know whether it is userland or the kernel which affects it; I'll boot into the older f20 kernel with f21 userland soon, just to see which way it is.
The fc20 kernel actually behaves correctly under a fc21 userland, strangely enough; and I am certainly that it did not with fc20 userland, as I have been on the same kernel for a week, and had to do my usual OPENSSL_ia32cap=~0x4000000000000000 for wget/ssh until as recent as 10 hours before upgrade, I think.
Apparently it is due to a change in mind of the openssl developers, https://software.intel.com/en-us/blogs/2014/10/03/changes-to-rdrand-integration-in-openssl FWIW, I was on openssl-1.0.1e-40.fc20.x86_64 and now openssl-1.0.1j-1.fc21.x86_64 , so indeed I have moved from pre 1.0.1f to post 1.0.1f.
Thanks for persisting with this. I guess I'll reassign it to openssl and let them decide what to do.
Note that the OpenSSL change is not a "fix". The RDRAND instruction support is still broken on the user's machine, it is just not used by default with the openssl-1.0.1j.
I agree - while it is useful for people who might suffer from this to have the later openssl pushed down as an upgrade (to f20 or EL*), the kernel still need to sleep and reinitialise the rdrand system correctly on waking up...
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.18.7-100.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
No reason to believe it is fixed, though if you insist, I'd compile openssl-1.0.1e or older to verify.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those.
There is an upstream bug to this which isn't closed; it is also relatively easy to test (I just need to compile the affected version of openssl-1.0.1e and set LD_LIBRARY_PATH, etc to try). I'll test when there is reason to believe something had been done to fix it. e.g.upstream commented, etc.
Sorry, meant to clear the needinfo field in my last comment.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs. Fedora 23 has now been rebased to 4.7.4-100.fc23. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Still a problem with 4.8.8-200.fc24.x86_64. Step to reproduce: 1. suspend/resume 2. build openssl-1.0.1e with ./Configure linux-x86_64 shared LD_LIBRARY_PATH=`pwd` make 3. LD_LIBRARY_PATH=`pwd` make test fails with (see also comment 15): === testing session-id conversions p -> d p -> p d -> d p -> d d -> p p -> p Generate and verify a certificate request generating certificate request rsa There should be a 2 sequences of .'s and some +'s. There should not be more that at most 80 per line This could take some time. Generating a 1024 bit RSA private key .Error Generating Key 139620662339224:error:0307A071:bignum routines:BN_rand_range:too many iterations:bn_rand.c:269: 139620662339224:error:04081003:rsa routines:RSA_BUILTIN_KEYGEN:BN lib:rsa_gen.c:223: problems creating request Makefile:261: recipe for target 'test_gen' failed make[1]: *** [test_gen] Error 1 make[1]: Leaving directory '/tmp/openssl-1.0.1e/test' Makefile:456: recipe for target 'tests' failed make: *** [tests] Error 2 === 4. Re-run with: OPENSSL_ia32cap=~0x4000000000000000 LD_LIBRARY_PATH=`pwd` make test now it succeeds, and go much further: === testing session-id conversions p -> d p -> p d -> d p -> d d -> p p -> p Generate and verify a certificate request generating certificate request rsa There should be a 2 sequences of .'s and some +'s. There should not be more that at most 80 per line This could take some time. Generating a 1024 bit RSA private key .....++++++ ......................++++++ writing new private key to 'testkey.pem' ----- === and go a lot further before it fails with === Test SRP ../util/shlib_wrap.sh ./srptest ... CMS consistency test /usr/bin/perl cms-test.pl CMS => PKCS#7 compatibility tests signed content DER format, RSA key: verify error Makefile:314: recipe for target 'test_cms' failed make[1]: *** [test_cms] Error 1 make[1]: Leaving directory '/tmp/openssl-1.0.1e/test' Makefile:456: recipe for target 'tests' failed make: *** [tests] Error 2 ===
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 25 has now been rebased to 4.10.9-100.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
Still a problem.
Still a problem under 4.11.5-200.fc25.x86_64 procedure for testing: 1. get hold of openssl 1.0.1e 2. suspend & resume 3. ./config && make && make test fails with this --- generating certificate request rsa There should be a 2 sequences of .'s and some +'s. There should not be more that at most 80 per line This could take some time. Generating a 1024 bit RSA private key .Error Generating Key 139620662322840:error:0307A071:bignum routines:BN_rand_range:too many iterations:bn_rand.c:269: 139620662322840:error:04081003:rsa routines:RSA_BUILTIN_KEYGEN:BN lib:rsa_gen.c:223: problems creating request Makefile:261: recipe for target 'test_gen' failed make[1]: *** [test_gen] Error 1 make[1]: Leaving directory '/tmp/openssl-1.0.1e/test' Makefile:456: recipe for target 'tests' failed make: *** [tests] Error 2 ---
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. As kernel maintainers, we try to keep up with bugzilla but due the rate at which the upstream kernel project moves, bugs may be fixed without any indication to us. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.15.3-300.f27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
kernel 4.15.3-300.f27, I no longer have that hardware - current hardware similar but have different problems. # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 112 model name : AMD A9-9410 RADEON R5, 5 COMPUTE CORES 2C+3G stepping : 0 microcode : 0x6006704 cpu MHz : 2543.810 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bogomips : 5789.15 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro acc_power [13] processor : 1 vendor_id : AuthenticAMD cpu family : 21 model : 112 model name : AMD A9-9410 RADEON R5, 5 COMPUTE CORES 2C+3G stepping : 0 microcode : 0x6006704 cpu MHz : 2587.635 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 4 apicid : 17 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bogomips : 5789.15 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro acc_power [13] make test goes beyond the earlier point, but fails later: Test SRP ../util/shlib_wrap.sh ./srptest N = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 g = 2 Salt = 3F80B007F2C9AB1338A204AE2CE2C62D63001B6 Verifier = 487E47B25CB86E3BD7990AB93C475F3271BF7C1F9425B62851AA5F7D50411655B9CFB55D30E27BBA59B38DD545C22DAF69A1557EE7FC21ED63E0FE83D2A75882A89CD7DD2D3D76CFF96FB0C26C882CF17E906C9EF7915AA3AB702D6DC06A4D91527634DB146CA20C332DABB343015EF28C1AF8C6EACA288592872D35CFB41A3A b = E378B1DF959CCB45C52AFD9F97234483C163AF5D84863B01D2877C53EB8E8CEF B = C8186D98515C888EBDA5225CA88938BA1C6F8B7B05889E89DCAF9B2ED8627C2989AB401D590466871E61412263AA7DD0B23D07872580586D56C7AFB07D6C9C270B8C463AAB1A88DAC424F0C893172DAD18EBC7769279FDE042A2121892E63CEC586166751C525675BE79BB2A7DBDA3B77FDDEEA1F1555D80D708C92D1D59FEB0 a = B351BA53B8BC2CB9E64DBF6DFCFDB38F413DA036D4A9E7392AAA52F543F09328 A = 3319EE9AE7BBAFA57D80872ED92BB9057293D5DAE55277F3F7CA966DA29441BC47C3E55D9AD0811BAD49CB0004CCE9D85E8E7043096362406D6CA1D23D7C277042749651A305002BD16BADC5D0A286A2217711D147AFD653F1D5B118CCA4DDAE5EA2CF6AA676A5BE9E58B2E383B9D3F2F25F7563F4CE2E8D468F878C8D77E1F8 Client's key = 6FD214D90A0E319E2B860E29C063D874394561DB9BE5918F258A4B5A6CC25A8B47210D615A2164EB5916608B05EF145ECE017238171D201004EE7DEFA1BC971E54B5014654CAD506E48BD8388BCC7CDB1F37DD640BA9C9AEEA01E5A53D557DFFB28661CDC49A97021E6D9906F023DB97556987BF8D1E88BE5EF6C1E0079D3EFA Server's key = A7A5916FA2D76D876942EF74223F5F293D74E86FAD48EEBFDB58D232599BA92412649EBB5A7161B09E084FC4956E43759F7257B187A245E00272AE779FBA20E714624CDC9EE2395024916515D684BFB2C6AB4473646326396C845733F2F19CFD67D45FBB5F341E0E41FBF480F10E81015AB5233E5119C05600B260D0520604E Keys mismatch N = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 g = 2 Salt = 61F60AC2CD3923908EF3A9DDCC7F3C77AE055333 Verifier = A84A5C2B6DC5763BE5899EA605FC109057C82E33F9C3610CF5B133C9987DE021EAA9BBBB8B9EE345EB790903AB4BB7727D02A7DB3744840DA2F173F2920BD664E99E9E82E0E8A9EAFD414DB5F901EF6A21ED9DE20C6165B78A0ED9727260D20146CCE63F44FAE5D0975F13DDE718B4F57918669EFBB349BA90EDC4EDAFB0E0F b = BA05797E0B764840D7E18F86122696995DCF3EE425C9987B86C7E6C37F54C471 B = B1806C86691ACD2642DE361163A0AA63D0998C2503A0C5BF9AC7E2A7B420A133C7C63D6B80DCD095CBB893C1D01E408042223EEA4EB385659A85ED666F34B9616E755DEFE081737A5DA91095C5FBC7C4D9AD25188AFC96AC1E4F25402AAEF0B817E0B4DF291352F24EE660AC536A50CFDB6F568D42C0E05DBDE2E71DF4B544F1 a = 9DF6192E4B414F5078C75AD2C9635CCC61CA62E05BF666EB2F6DD521E8E40A8B A = ECC7FD714BEAE647A9A2245FB5C7D53730C6C6F700F980BB3997FABE1ED96F4D8AFF18D336CF377213DB3BCFA4DE6A598D661E18ECECB81CBF07C1377AD754470B85E49920381E02D1E664D01A7D274E74F578FFE2B968B4F820D4BA61967AC3E346DB4CCBC364A0849C947A07D1D4E607E1397C537AC7D9FB816BBB3BE3771B Client's key = 23BD01DD83C50BC1F245208188385D7C39C16479AC68DC7D4360818139CAF7B45406452A5085418BDF19174E65C6F641C5A72E736C4008A438D4D49A3E8109A6C85FCB4692B53905193728B70D14377B3CB7B2BFB1DC051154086455ECFF9A82068833C0E2E3A6CD49653C24EB105BCB3848A3486A4FD0D4C6B50CFD2F4A51C1 Server's key = 23BD01DD83C50BC1F245208188385D7C39C16479AC68DC7D4360818139CAF7B45406452A5085418BDF19174E65C6F641C5A72E736C4008A438D4D49A3E8109A6C85FCB4692B53905193728B70D14377B3CB7B2BFB1DC051154086455ECFF9A82068833C0E2E3A6CD49653C24EB105BCB3848A3486A4FD0D4C6B50CFD2F4A51C1 CMS consistency test /usr/bin/perl cms-test.pl CMS => PKCS#7 compatibility tests signed content DER format, RSA key: verify error make[1]: *** [Makefile:315: test_cms] Error 1 make[1]: Leaving directory '/tmp/openssl-1.0.1e/test' make: *** [Makefile:456: tests] Error 2 since this is older openssl, probably not worth reporting?
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.17.7-100.fc27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 5 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
I stumbled across the issue when I noticed the kernel or systemd disable the RDRAND instruction on a machine with AMD A6-9220e RADEON R4, 5 COMPUTE CORES 2C+3G: [0.163183] BIOS may not properly restore RDRAND after suspend, hiding RDRAND via CPUID. Use rdrand=force to reenable. Also see Systemd Issue 11810, https://github.com/systemd/systemd/issues/11810 .