July 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c46 --- Comment #46 from Michal Kubeček <mkubecek(a)suse.com> --- (In reply to Ludwig Nussel from comment #43) > https://media.giphy.com/media/3oEjHMBUxwVJ9iu5JS/giphy.gif Could you be more specific? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c45 --- Comment #45 from Martin Wilck <martin.wilck(a)suse.com> --- While I think the KMP solution is The Right Thing (TM), it is obviously not viable short-term. Here's an idea what we can do quickly: - create a new kernel flavor, call it "nolockdown" or whatever, that loosens lockdown features enough to load NVidia and other proprietary drivers. - sign this flavor with a different key, which is not allowed on SB systems by default. People who want to use that key would need to set it up using mokutil. that would be a one-time measure, as opposed to having to provide keys with every driver rebuild. - that kernel package could be accompanied by an EULA file explaining why it exists and what the security implications are. Advantages: * It allows leaving the secure boot setting on in the BIOS (might be mandated by another OS on the system, or other policies). * It satisfies the security requirement that enabling it requires an explicit action of the user in the UEFI environment ("physical presence" - well). * It's far better than adding a "nolockdown" kernel command line parameter from a security PoV. * Security-wise, people using this kernel would be as "good" as Leap 15.1 users, possibly a little better off. * It's less hassle for users than having to create and deploy keys themselved, possibly repeatedly. * It should be pretty quick to implement, no re-engineering of NVidia drivers needed. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c44 --- Comment #44 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Michal Kubeček from comment #42) > Ther preferrable (if viable) solution should still be having the NVidia > modules signed, even if with a key that is kept on the system itself (which > is, naturally, also questionable from security point of view). Indeed, I'd say it's not much better than allowing unsigned modules in the first place. > AFAIK the > module consists of two parts, "GPL wrapper" and the actual driver which has > kernel incompatible license; does it suffice to sign the "GPL wrapper"? Unless I'm very mistaken, the full module has to be signed. Otherwise circumvention of the lockdown feature would be just too easy. In theory the firmware loading mechanism could be abused to load a binary blob, but the Nvidia driver doesn't do that, and I guess lockdown would prevent this mechanism somehow, too. > Some other out of tree modules, e.g. host modules for VMware Workstation, > go this way: if you have secure boot, you need to sign the modules after you > build them. Heck, I really don't understand why this has to be done differently for almost every module. *SUSE has an excellent technology to solve this problem.* It is called "Kernel Module Packages", most of it has been designed and engineered at SUSE, and it has well-established processes behind it (Solid Driver). SUSE is better at this than any other Linux distro I'm aware of. The only issue with KPMs in this context is that we can't use OBS to create *proprietary* KMPs for legal reasons, and can't distribute them on our servers. The obvious solution would be to have some external entity (preferably NVidia itself) set up an OBS instance, enabled for module signing, and a key. They don't have to do the KMP engineering themselves if they lack the ability, we'd find someone to do it for them. They'd just have to throw the spec file at their private OBS instance, build, and create a repo. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c43 --- Comment #43 from Ludwig Nussel <lnussel(a)suse.com> --- https://media.giphy.com/media/3oEjHMBUxwVJ9iu5JS/giphy.gif -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c42 Michal Kubeček <mkubecek(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jlee(a)suse.com --- Comment #42 from Michal Kubeček <mkubecek(a)suse.com> --- One thing we should keep in mind is that secure boot, i.e. making sure only properly signed kernel is loaded, makes very little sense if we then allow loading any strange module into it. It could be even considered a security vulnerability. So rather than asking for "less lockdown" (for everyone), I would suggest to look for a (secure enough) way to opt out from strict checking that people who want to run NVidia modules on systems with secure boot could do. One obvious idea is a command line parameter - but that is also obviously wrong. Do we have some option to pass parameters "from outside"? Could e.g. EFI variables be used for this? Adding Joey Lee who did the lockdown backport and knows way more about how it works. Ther preferrable (if viable) solution should still be having the NVidia modules signed, even if with a key that is kept on the system itself (which is, naturally, also questionable from security point of view). AFAIK the module consists of two parts, "GPL wrapper" and the actual driver which has kernel incompatible license; does it suffice to sign the "GPL wrapper"? Some other out of tree modules, e.g. host modules for VMware Workstation, go this way: if you have secure boot, you need to sign the modules after you build them. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173912] ThinkPad Dock USB Audio - Output distorted
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173912 https://bugzilla.suse.com/show_bug.cgi?id=1173912#c2 --- Comment #2 from Marc Höhn <marc(a)hoehn.de> --- ok thx will do. I'm not with that machine right now so its gonna be next week. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173912] ThinkPad Dock USB Audio - Output distorted
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173912 https://bugzilla.suse.com/show_bug.cgi?id=1173912#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marc(a)hoehn.de, | |tiwai(a)suse.com Flags| |needinfo?(marc(a)hoehn.de) --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- Likely a recent regression in the upstream. The fix got merged yesterday in the upstream and SLE15-SP2/Leap15.2 branch. Please check the kernel in OBS Kernel:openSUSE-15.2 repo http://download.opensuse.org/reposiotires/Kernel:/openSUSE-15.2/standard/ -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.suse.com/s | |how_bug.cgi?id=1173682 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c40 --- Comment #40 from Stefan Dirsch <sndirsch(a)suse.com> --- (In reply to Takashi Iwai from comment #8) > The problem isn't too serious on TW because the TW kernel (i.e. the upstream > kernel) still has no strict lockdown. SLE / Leap kernel has a stricter > lockdown, so it can be an actual problem. It might be a problem on TW as > well once when the upstream accepts the more lockdown. Seems we didn't listen closely to Takashi. :-( Can we have "less" lockdown, please? ;-) > IOW, it's not only about CONFIG_MODULE_SIG. Rather the key point is whether > the kernel has a lockdown feature for the unsigned module or not. Hmm. Is this configurable? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c39 --- Comment #39 from Stefan Dirsch <sndirsch(a)suse.com> --- (In reply to Michal Kubeček from comment #37) > (In reply to Martin Wilck from comment #36) > > Is this perhaps caused by recent lockdown patches? Is that the reason why it > > doesn't behave the way we were used to? > > Not so recent, actually. The lockdown backport was merged into SLE15-SP2 > branch on November 27th and into openSUSE-15.2 one day later. Not that old. We would need a kernel build before this happened to see whether the lockdown is the culprit here. And if it is I would expect - even if there would an agreement to remove this feature (very unlikely?) - it won't be doable any longer with thousands of patches sitting on top of it meanwhile ... -- You are receiving this mail because: You are the assignee for the bug.

1 0