Messages in this thread | | | Date | Tue, 20 Feb 2018 22:23:59 +0100 | From | Jessica Yu <> | Subject | Re: [PATCH] Make kernel taint on invalid module signatures configurable |
| |
+++ Matthew Garrett [20/02/18 20:37 +0000]: >On Tue, Feb 20, 2018 at 11:21 AM Jessica Yu <jeyu@kernel.org> wrote: > >> Ah, OK. So if I'm understanding correctly, you want to use the same kernel >> image/configuration but for two different use cases, one where the module >> signatures do not matter, and one where they do matter. But the config you >> want to use in both use cases would have CONFIG_MODULE_SIG=y and >> CONFIG_MODULE_SIG_TAINT=n (to avoid tainting of unsigned/invalidly signed >> modules). > >Right. Distributions generally have to try to satisfy multiple use cases >with as few kernel images as possible. > >> In any case, I think I'd be willing to merge it as a module_param made >> available under CONFIG_MODULE_SIG=y (rather than as a new separate config >> option), while preserving the default behavior of tainting on >> unsigned/invalidly signed module loads (so let's keep the param parts of >> your patch). I think it makes sense to consider the turning-off-the-taint >> param as a behavioral tweak under CONFIG_MODULE_SIG. Then you could turn >> off the tainting behavior on the kernel command line, would this >sufficient >> enough for your use cases? > >I think that's probably not practical - distributions often aren't in >control of the kernel command line after initial installation, so they'd >end up with different behaviour depending on whether a machine was a clean >install or not (which is why several things that are module_params have >defaults controlled by additional kernel config options)
Ah I see.. Fair enough!
>> >Not entirely. There's two cases where the current situation causes >problems: >> > >> >1) Distributions that build out of tree kernel modules and don't have >> >infrastructure to sign them will end up with kernel taint. That's >something >> >that can be resolved by implementing that infrastructure. >> >2) End-users who build out of tree kernel modules will end up with kernel >> >taint and will file bugs. This cannot be fixed but will increase >> >distribution load anyway. > >> I thought these two cases (particularly #2) were the very situations >> where distros might find the unsigned module taint useful (especially >> in the use case where you do benefit from module signatures). From my >> understanding, the unsigned module taint is intended to be useful when >> looking at crashes/OOPses, to provide a clear indication of whether or >> not a developer could reliably debug the crash, or choose to tread >> carefully, because the end-user has loaded an unsigned/out-of-tree >> module that wasn't signed/shipped by the distribution. Is the taint >> just not useful to distros in this manner anymore? > >The module list is usually sufficient for that - users tend not to replace >individual distribution modules without rebuilding their entire kernel.
| |