Restricting automatic kernel-module loading [LWN.net]

Restricting automatic kernel-module loading

Posted Dec 4, 2017 17:43 UTC (Mon) by gutschke (subscriber, #27910)
Parent article: Restricting automatic kernel-module loading

Allowing auto-loading of well-maintained modules could work.

It isn't possible to do a perfect job at auto-detecting well-maintained modules. But it is in fact possible to implement a dead-man switch that could become a reasonable approximation. Instead of making it a boolean flag, make it a kernel version number. If this number ever lags behind the actual kernel version number by more than two versions, we know that the module sources haven't been updated in several months. That's when the module would revert to non-maintained status.

There are all sorts of ways that this system could be gamed (e.g. picking the value with the help of a macro instead of a constant). But that's a social and not a technical problem. Those hacks shouldn't be permitted.

to post comments

Restricting automatic kernel-module loading

Posted Dec 4, 2017 18:48 UTC (Mon) by edeloget (subscriber, #88392) [Link] (5 responses)

(I have a strong headache, so my English might be a little broken tonight. I hereby present you my apologies).

I don't get it: I'm pretty sure that modules compiled for a specific kernel have the same kernel version as the kernel itself, so I don't understand how this would work. You cannot base this on the "last commit distance" as well, since a commit that would be unrelated to the module core code (for example a change in the driver API) would reduce this distance to a small value.

Thus, a flag is (IMHO) a good solution. Add those to well known and/or often used modules. In order to remove add the relevant flag, a maintainer will have to show that the module code is well maintained.

But before doing that, one must have some metrics, including which module is auto-loaded and how often it happens.

Now, from my point of view, it would be a good idea to get rid of module autoloading :)

Restricting automatic kernel-module loading

Posted Dec 4, 2017 21:43 UTC (Mon) by simcop2387 (subscriber, #101710) [Link] (4 responses)

I think he's proposing that we add another bit of information. The last kernel version that this module had changes in.

Restricting automatic kernel-module loading

Posted Dec 4, 2017 21:53 UTC (Mon) by gutschke (subscriber, #27910) [Link] (3 responses)

That's exactly right. It would be a manually maintained field. It doesn't *technically* require that this is the last time the source has changed. But it would be the last time a maintainer re-affirmed that the module is still actively maintained. Frequently, that would go hand-in-hand with making source code changes. But it doesn't have to.

Similarly, it is possible for somebody to change the source code (e.g. to make adjustments for kernel-wide API changes) without asserting the responsibility of a full-time committed maintainer. In that case, they would not bump up the version number.

The important part is that this number would never be changed automatically. It is always a conscious decision by a human developer.

Restricting automatic kernel-module loading

Posted Dec 4, 2017 22:05 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

The existing MODULE_VERSION macro shows what the fate of any such field is likely to be: rotting unnoticed even though the module *is* in fact actively maintained.

Restricting automatic kernel-module loading

Posted Dec 4, 2017 22:09 UTC (Mon) by gutschke (subscriber, #27910) [Link]

But that's OK, isn't it. The only people making use of this field are those maintainers who explicitly want to request enhanced permissions for their code.

If updating the field isn't something they can fit into their workflow, then maybe their code doesn't deserve these extra permissions. After all, it sounds as if the long-term goal would be for auto-loading to become the exception rather than the rule.

There probably would be a lengthy transition path before any of these policies would be widely and uniformly enforced anyway.

Restricting automatic kernel-module loading

Posted Dec 5, 2017 0:46 UTC (Tue) by edeloget (subscriber, #88392) [Link]

I get it.

Restricting automatic kernel-module loading

Posted Dec 7, 2017 10:03 UTC (Thu) by tsr2 (subscriber, #4293) [Link] (3 responses)

My "simple" solution to how the flag is maintained.

At the start of each release cycle, set all "well maintained" flags to false. They then have to be updated by the module maintainer in that cycle for the module to be considered well maintained.

Restricting automatic kernel-module loading

Posted Dec 7, 2017 13:28 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

This requires every maintainer to get at least one pull request accepted by Linus each cycle. Given that they are normally prepared atop the *previous* kernel release (so something that lands in 4.15.x was often prepared atop 4.13.x or even 4.12.x) and given that not everything needs an update in every release (the kernel has a *great many* modules), one cannot control when or even if Linus chooses to reject your pulls, this seems likely to lead to a huge number of things falsely being considered unmaintained.

Perhaps a decaying function of sorts? A per-module 'last updated version' (a KERNELVERSION, obviously), updated when the maintainer sees fit, and a constantly-advancing threshold that the kernel uses to consider a module 'unmaintained' if a module's last-updated is older than that? The threshold would be a few versions, so that maybe something that hadn't seen maintenance in four releases (~ 1 year) was considered unmaintained...

Restricting automatic kernel-module loading

Posted Dec 15, 2017 1:43 UTC (Fri) by wmealing (guest, #31633) [Link] (1 responses)

I can see a problem in this, the AUF CVE-2017-6074 would reset this counter as "maintained".

Restricting automatic kernel-module loading

Posted Dec 15, 2017 5:28 UTC (Fri) by gutschke (subscriber, #27910) [Link]

I fail to see the problem. This number would only ever be updated manually. So, either the maintainer explicitly takes responsibility for maintaining the code for another year and updates the number; or he states that emergency edits to the source should not be misconstrued as extending support, and be leaves the old number unchanged.

In either case, it's a deliberate and conscious decision