Bug 1150286 - rdrand instruction fails after resume on AMD CPU
Summary: rdrand instruction fails after resume on AMD CPU
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 27
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-07 20:12 UTC by Hin-Tak Leung
Modified: 2020-01-17 03:52 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-29 15:02:13 UTC
Type: Bug


Attachments (Terms of Use)
lsmod (4.38 KB, text/plain)
2014-10-07 20:19 UTC, Hin-Tak Leung
no flags Details
cat /proc/cpuinfo (4.29 KB, text/plain)
2014-10-08 10:59 UTC, Hin-Tak Leung
no flags Details
dmesg (80.02 KB, text/plain)
2014-10-08 13:05 UTC, Hin-Tak Leung
no flags Details


Links
System ID Priority Status Summary Last Updated
Linux Kernel 85911 None None None 2019-07-18 15:02:29 UTC

Description Hin-Tak Leung 2014-10-07 20:12:43 UTC
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

Comment 1 Hin-Tak Leung 2014-10-07 20:19:27 UTC
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.

Comment 2 Tomas Mraz 2014-10-08 08:18:26 UTC
This really looks like a kernel bug. Can you attach the output of 'cat /proc/cpuinfo' ?

Comment 3 Hin-Tak Leung 2014-10-08 10:59:37 UTC
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

Comment 4 Hin-Tak Leung 2014-10-08 11:12:30 UTC
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.

Comment 5 Tomas Mraz 2014-10-08 11:26:25 UTC
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?

Comment 6 Hin-Tak Leung 2014-10-08 11:33:43 UTC
(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.

Comment 7 Hin-Tak Leung 2014-10-08 11:49:37 UTC
Read up on rdrand - so this is likely a hardware/kernel bug or hardware fault that needs a kernel workaround then?

Comment 8 Tomas Mraz 2014-10-08 11:58:22 UTC
Yes.

Comment 9 Hin-Tak Leung 2014-10-08 12:03:26 UTC
Please re-assign and/or do whatever necessarily to get this prob to the right people then...

Comment 10 Josh Boyer 2014-10-08 12:41:47 UTC
Please attach the output of dmesg from a fresh boot, followed by the output after a suspend/resume cycle and a failed ssh login.

Comment 11 Hin-Tak Leung 2014-10-08 13:05:26 UTC
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.

Comment 12 Hin-Tak Leung 2014-10-08 13:28:20 UTC
(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 .

Comment 13 Hin-Tak Leung 2014-10-08 13:34:55 UTC
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...)

Comment 14 Hin-Tak Leung 2014-10-08 20:38:50 UTC
Filed upstream bug. I am fine with either upstream pushing a fix down, or the fedora people fixing it and pushing a fix up...

Comment 15 Hin-Tak Leung 2014-10-10 22:43:27 UTC
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

Comment 16 Justin M. Forbes 2014-11-13 15:57:14 UTC
*********** 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.

Comment 17 Hin-Tak Leung 2014-11-13 17:49:35 UTC
(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

Comment 18 Hin-Tak Leung 2014-11-23 19:36:26 UTC
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.

Comment 19 Hin-Tak Leung 2014-12-15 18:52:10 UTC
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.

Comment 20 Hin-Tak Leung 2014-12-16 00:22:04 UTC
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.

Comment 21 Hin-Tak Leung 2014-12-16 01:13:49 UTC
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.

Comment 22 Josh Boyer 2014-12-16 01:18:50 UTC
Thanks for persisting with this.  I guess I'll reassign it to openssl and let them decide what to do.

Comment 23 Tomas Mraz 2014-12-16 10:03:37 UTC
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.

Comment 24 Hin-Tak Leung 2014-12-16 10:14:55 UTC
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...

Comment 25 Fedora Kernel Team 2015-02-24 16:23:07 UTC
*********** 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.

Comment 26 Hin-Tak Leung 2015-02-25 01:03:18 UTC
No reason to believe it is fixed, though if you insist, I'd compile openssl-1.0.1e or older to verify.

Comment 27 Fedora Kernel Team 2015-04-28 18:30:14 UTC
*********** 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.

Comment 28 Hin-Tak Leung 2015-04-29 21:49:49 UTC
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.

Comment 29 Hin-Tak Leung 2015-04-29 21:50:49 UTC
Sorry, meant to clear the needinfo field in my last comment.

Comment 30 Justin M. Forbes 2015-10-20 19:23:18 UTC
*********** 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.

Comment 31 Laura Abbott 2016-09-23 19:29:11 UTC
*********** 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.

Comment 32 Laura Abbott 2016-10-26 16:46:15 UTC
*********** 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.

Comment 33 Hin-Tak Leung 2016-11-22 16:28:39 UTC
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
===

Comment 34 Justin M. Forbes 2017-04-11 14:44:32 UTC
*********** 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.

Comment 35 Hin-Tak Leung 2017-04-11 21:36:44 UTC
Still a problem.

Comment 36 Hin-Tak Leung 2017-06-21 16:55:08 UTC
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

---

Comment 37 Fedora End Of Life 2017-11-16 19:12:48 UTC
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.

Comment 38 Laura Abbott 2018-02-20 19:56:29 UTC
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.

Comment 39 Hin-Tak Leung 2018-03-01 23:46:53 UTC
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?

Comment 40 Hin-Tak Leung 2018-03-01 23:47:23 UTC
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?

Comment 41 Justin M. Forbes 2018-07-23 15:05:45 UTC
*********** 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.

Comment 42 Justin M. Forbes 2018-08-29 15:02:13 UTC
*********** 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.

Comment 43 Jeffrey Walton 2020-01-17 03:52:55 UTC
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 .


Note You need to log in before you can comment on or make changes to this bug.