Restricting automatic kernel-module loading [LWN.net]

Restricting automatic kernel-module loading

Posted Dec 4, 2017 18:48 UTC (Mon) by edeloget (subscriber, #88392)
In reply to: Restricting automatic kernel-module loading by gutschke
Parent article: Restricting automatic kernel-module loading

(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 :)

to post comments

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.