Thomas Gleixner [off-list ref] wrote:

quoted

-module_param(mmio_address, ulong, 0);
+module_param_hw(mmio_address, ulong, iomem, 0);
 MODULE_PARM_DESC(mmio_address, " Start address of the mapping of 16 kB "
 				"(or 8 MB if read_far is non-zero).");

The copied boilerplate above is really nonsensical here. The default
address is 0, so the init function will emit:

     pr_err("you have to use the module argument mmio_address.\n");
     pr_err("DO NOT LOAD THIS MODULE UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!\n");

Pretty useless when you can't supply a valid address.

       if (kernel_locked_down()) {
       		pr_info("This is not allowed because ...");
		return -EPERM;
       }

would make too much sense for the user, right?

In some drivers, this would be wrong - ipmi, for example - and we've already
been through this.  The hwparam series of patches annotates *all*
ioport/iomem/irq/dma specifiers unconditionally.  The hwparam series is the
way it is is because this has no overhead if it's not used - and also has the
potentially useful side effect of making such parameters greppable.

It may well make sense to add your above suggestion also - but in the other
patch series.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html