Restricting automatic kernel-module loading [LWN.net]

Restricting automatic kernel-module loading

Posted Dec 7, 2017 10:03 UTC (Thu) by tsr2 (subscriber, #4293)
In reply to: Restricting automatic kernel-module loading by gutschke
Parent article: Restricting automatic kernel-module loading

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.

to post comments

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