|
Bugzilla – Full Text Bug Listing |
| Summary: | kernel: scsi_dh_alua: module verification failed: signature and/or required key missing - tainting kernel | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Suse User <suseino> |
| Component: | Kernel | Assignee: | E-mail List <kernel-maintainers> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | jslaby, suseino, tiwai |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
journal excerpt
modinfo scsi_dh_alua requested info lscpu with kernel-pae |
||
Looks like the kernel module signing problem. Does this still happen with the latest kernel? In anyway, TW kernel will move to 5.5 soon later, so let us know if the problem persists with it. Thanks. > Does this still happen with the latest kernel?
This was reported right after a system udpate, so - yes.
And as of today - still yes:
# uname -rvpio
5.4.14-1-default #1 SMP Thu Jan 23 08:54:47 UTC 2020 (fc4ea7a) i686 i386 GNU/Linux
*As of today = the system is up to date Hm, strange. Which kernel module is used there? Please check "modinfo scsi_dh_alua" output. Created attachment 829153 [details]
modinfo scsi_dh_alua
Attached.
Where is this kernel from? It is neither signed, nor properly versioned, nor properly packed. What's the output from: rpm -qif /lib/modules/5.4.14-1-default/kernel/drivers/scsi/device_handler/scsi_dh_alua.ko ? Created attachment 829383 [details]
requested info
The requested info is in the attachment and includes output of the commands before and right after today's run of zypper update.
(In reply to Suse User from comment #7) > Created attachment 829383 [details] > requested info Ah! (In reply to Suse User from comment #2) > # uname -rvpio > 5.4.14-1-default #1 SMP Thu Jan 23 08:54:47 UTC 2020 (fc4ea7a) i686 i386 > GNU/Linux Looking at a different part of this line now, I see, of course. This is 32bit. Why does pesign fail completely for 32bit? (In reply to Jiri Slaby from comment #8) > Looking at a different part of this line now, I see, of course. This is > 32bit. Why does pesign fail completely for 32bit? # XXX: do not sign on x86, as the repackaging changes kernel-pae # from i686 to i586 BRP_PESIGN_FILES="" OK, we should perhaps disable module signing on i386, given we don't generate signatures at all... (In reply to Suse User from comment #2) > 5.4.14-1-default #1 SMP Thu Jan 23 08:54:47 UTC 2020 (fc4ea7a) i686 i386 > GNU/Linux BTW do you have so old CPU, that -pae doesn't work on it? Created attachment 829503 [details] lscpu > This is 32bit. Yes, as reported initially. > Why does pesign fail completely for 32bit? I don't know. I am not an expert. > BTW do you have so old CPU, that -pae doesn't work on it? Attaching lscpu. (In reply to Suse User from comment #11) > > Why does pesign fail completely for 32bit? > > I don't know. I am not an expert. Sure, the answer and a solution is in comment 9. > > BTW do you have so old CPU, that -pae doesn't work on it? > > Attaching lscpu. Flags: fpu … pae It really looks like you should use more secure kernel-pae (NX), not kernel-default. Doesn't it work for you? Could you try it? It won't fix this problem, though. Created attachment 829601 [details] with kernel-pae > It really looks like you should use more secure kernel-pae (NX), not kernel-default. I was using the kernel which the OS installer suggested. I wasn't aware that a better option exists and that PAE is relevant for a computer which doesn't support more than 2GB of RAM. I know what PAE means but I never know it is "more secure". > Doesn't it work for you? Could you try it? It won't fix this problem, though. I installed it and it seems to work (see attachment). Now there is a mitigation for L1TF and Meltdown. Unfortunately the other vulnerabilities remain. The bug reported here remains with kernel-pae too. (also seen in the attachment) Questions: - Why doesn't the OS installer suggest kernel-pae if the CPU supports PAE? Is this another bug/issue to report? - Could you please suggest a solution for mitigation of the other vulnerabilities? (I realize this is "off-topic" but I would very very much appreciate an advice. Please feel free to email me directly if you think it is more appropriate or direct me to a proper place to ask/read). (In reply to Suse User from comment #13) > Created attachment 829601 [details] > with kernel-pae > > > It really looks like you should use more secure kernel-pae (NX), not kernel-default. > > I was using the kernel which the OS installer suggested. I wasn't aware that > a better option exists and that PAE is relevant for a computer which doesn't > support more than 2GB of RAM. I know what PAE means but I never know it is > "more secure". When a processor supports PAE, it has to (spec says so) support other features like NX too (generally, this one does not allow executing code from data pages). > > Doesn't it work for you? Could you try it? It won't fix this problem, though. > > I installed it and it seems to work (see attachment). > > Now there is a mitigation for L1TF and Meltdown. Unfortunately the other > vulnerabilities remain. The bug reported here remains with kernel-pae too. > (also seen in the attachment) Sure. We have to fix it as per comment 9 first. > Questions: > > - Why doesn't the OS installer suggest kernel-pae if the CPU supports PAE? > Is this another bug/issue to report? It looks like that. Installer mostly install pae correctly. Maybe your model is not whitelisted. So open a bug against the installer to find out the reasons, please. > - Could you please suggest a solution for mitigation of the other > vulnerabilities? (I realize this is "off-topic" but I would very very much > appreciate an advice. Please feel free to email me directly if you think it > is more appropriate or direct me to a proper place to ask/read). Again, open a new bug. It's likely because Intel hasn't released fixed microcode either because the cpu cannot be fixed via microcode or it is too old for them to care about it at all. (In reply to Jiri Slaby from comment #14) > > - Why doesn't the OS installer suggest kernel-pae if the CPU supports PAE? > > Is this another bug/issue to report? > > It looks like that. Installer mostly install pae correctly. Maybe your model > is not whitelisted. So open a bug against the installer to find out the > reasons, please. And I am wrong here: PAE allows for NX, but not all CPUs implement that. Yours is one of them (according to lscpu). So maybe that's the reason why -pae was not installed on your system (I'm not sure what's the logic in the installer). Opening new bugs for the 2 other issues: https://bugzilla.opensuse.org/show_bug.cgi?id=1163117 https://bugzilla.opensuse.org/show_bug.cgi?id=1163120 Also after switching to kernel-pae I am experiencing a new bug (not sure if this is related to the NX, please have a look): https://bugzilla.opensuse.org/show_bug.cgi?id=1163116 Still an issue with new kernel: # uname -rvpio 5.5.2-1-pae #1 SMP Sat Feb 8 07:54:02 UTC 2020 (994cf1f) i686 i386 GNU/Linux Fixed now: commit 599e3c21dfae731c705c3900a5dff90e43b1fedd Author: Jiri Slaby <jslaby@suse.cz> Date: Wed Feb 19 08:03:41 2020 +0100 Update config files (bnc#1161832). It will take some time to propagate... After today's TW update it seem it has still not propagated: # journalctl -b -o short-monotonic --no-hostname | grep taint [ 4.848598] kernel: scsi_dh_alua: module verification failed: signature and/or required key missing - tainting kernel # uname -rvpio 5.5.4-1-pae #1 SMP Sat Feb 15 08:16:55 UTC 2020 (119f9ca) i686 i386 GNU/Linux |
Created attachment 828292 [details] journal excerpt After upgrading a Tumblweed system I notice this message in the journal (and in dmesg). *I don't know if this is a bug but I thought I should report it because of the "failed" note.