Messages in this thread | | | Date | Thu, 15 Feb 2018 16:25:16 +0100 | From | Jessica Yu <> | Subject | Re: [PATCH] Make kernel taint on invalid module signatures configurable |
| |
+++ Matthew Garrett [14/02/18 18:21 +0000]: >Hi Jessica, > >Any objections to this patch? > >Thanks!
Hi Matthew!
My questions and comments from last year still apply here -
http://lkml.kernel.org/r/20170829175647.ej5fqszss2mbpc5i@redbean
I'm still unclear on why a distro would enable CONFIG_MODULE_SIG and then _not_ want to know about unsigned modules.
From what I understand from Ben's post from last year (http://lkml.kernel.org/r/1504044122.4448.24.camel@decadent.org.uk), it sounds like the main issue is that Debian doesn't support their own centralised module signing yet, causing all of their modules to be automatically tainted if they enable CONFIG_MODULE_SIG, and that a new option like this would likely be used as a temporary "fix". Am I understanding correctly?
I understand this predicament, but it seems like adding a new set of options/parameters like this is just hiding the symptoms of the problem (modules distributed by Debian getting tainted by default) instead of fixing what seems to be the heart of the issue (Debian doesn't support their own module signing yet), if that makes sense. I am hesitant about merging something that would only serve as a temporary solution until Debian supports their own module signing. In that case, I would prefer the Debian folks to maintain their own patch removing the taint until they support module signing for their own modules, especially if - and please correct me if I'm wrong - the new option is not going to see long-term usage.
Thanks,
Jessica
| |