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#c48 --- Comment #48 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Michal Kubeček from comment #47) > I'm not sure if our setup is able to use different keys for different flavors > or if it can be taught to with reasonable effort. We would need someone > familiar with the implementation to answer this. Perhaps we could build that flavor in a different project? -- 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#c47 --- Comment #47 from Michal Kubeček <mkubecek(a)suse.com> --- (In reply to Martin Wilck from comment #45) > - 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. I'm not sure if our setup is able to use different keys for different flavors or if it can be taught to with reasonable effort. We would need someone familiar with the implementation to answer this. -- 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#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