Annotate hw config module params for future lockdown

Here's a set of patches that annotate module parameters that configure hardware resources including ioports, iomem addresses, irq lines and dma channels.

This will be used in a future patch to prohibit the use of such module parameters so that hardware can't be abused to gain access to the running kernel image.

This is done by changing:

module_param(n, t, p)
module_param_named(n, v, t, p)
module_param_array(n, t, m, p)

to:

module_param_hw(n, t, hwtype, p)
module_param_hw_named(n, v, t, hwtype, p)
module_param_hw_array(n, t, hwtype, m, p)

where hwtype specifies the type of the resource being configured.

Note that the hwtype is compile checked, but not currently stored (the lockdown code probably won't require it). It is, however, there for future use.

The patches can be found here also:

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=hwparam

at tag:

	hwparam-20161201

David
---
David Howells (39):
Annotate module params that specify hardware parameters (eg. ioport) Annotate hardware config module parameters in arch/x86/mm/ Annotate hardware config module parameters in drivers/char/ipmi/ Annotate hardware config module parameters in drivers/char/mwave/ Annotate hardware config module parameters in drivers/char/ Annotate hardware config module parameters in drivers/clocksource/ Annotate hardware config module parameters in drivers/cpufreq/ Annotate hardware config module parameters in drivers/gpio/ Annotate hardware config module parameters in drivers/i2c/ Annotate hardware config module parameters in drivers/iio/ Annotate hardware config module parameters in drivers/input/ Annotate hardware config module parameters in drivers/isdn/ Annotate hardware config module parameters in drivers/media/ Annotate hardware config module parameters in drivers/misc/ Annotate hardware config module parameters in drivers/mmc/host/ Annotate hardware config module parameters in drivers/net/appletalk/ Annotate hardware config module parameters in drivers/net/arcnet/ Annotate hardware config module parameters in drivers/net/can/ Annotate hardware config module parameters in drivers/net/ethernet/ Annotate hardware config module parameters in drivers/net/hamradio/ Annotate hardware config module parameters in drivers/net/irda/ Annotate hardware config module parameters in drivers/net/wan/ Annotate hardware config module parameters in drivers/net/wireless/ Annotate hardware config module parameters in drivers/parport/ Annotate hardware config module parameters in drivers/pci/hotplug/ Annotate hardware config module parameters in drivers/pcmcia/ Annotate hardware config module parameters in drivers/scsi/ Annotate hardware config module parameters in drivers/staging/i4l/ Annotate hardware config module parameters in drivers/staging/media/ Annotate hardware config module parameters in drivers/staging/speakup/ Annotate hardware config module parameters in drivers/staging/vme/ Annotate hardware config module parameters in drivers/tty/ Annotate hardware config module parameters in drivers/video/ Annotate hardware config module parameters in drivers/watchdog/ Annotate hardware config module parameters in fs/pstore/ Annotate hardware config module parameters in sound/drivers/ Annotate hardware config module parameters in sound/isa/ Annotate hardware config module parameters in sound/oss/ Annotate hardware config module parameters in sound/pci/

 arch/x86/mm/testmmiotrace.c                 |    2 -
 drivers/char/applicom.c                     |    4 +-
 drivers/char/ipmi/ipmi_si_intf.c            |   14 +++---
 drivers/char/mwave/mwavedd.c                |    8 ++-
 drivers/clocksource/cs5535-clockevt.c       |    2 -
 drivers/cpufreq/speedstep-smi.c             |    2 -
 drivers/gpio/gpio-104-dio-48e.c             |    4 +-
 drivers/gpio/gpio-104-idi-48.c              |    4 +-
 drivers/gpio/gpio-104-idio-16.c             |    4 +-
 drivers/gpio/gpio-gpio-mm.c                 |    2 -
 drivers/gpio/gpio-ws16c48.c                 |    4 +-
 drivers/i2c/busses/i2c-elektor.c            |    6 +-
 drivers/i2c/busses/i2c-parport-light.c      |    4 +-
 drivers/i2c/busses/i2c-pca-isa.c            |    4 +-
 drivers/i2c/busses/scx200_acb.c             |    2 -
 drivers/iio/adc/stx104.c                    |    2 -
 drivers/iio/dac/cio-dac.c                   |    2 -
 drivers/input/mouse/inport.c                |    2 -
 drivers/input/mouse/logibm.c                |    2 -
 drivers/input/touchscreen/mk712.c           |    4 +-
 drivers/isdn/hardware/avm/b1isa.c           |    4 +-
 drivers/isdn/hardware/avm/t1isa.c           |    4 +-
 drivers/isdn/hisax/config.c                 |   10 ++--
 drivers/media/pci/zoran/zoran_card.c        |    2 -
 drivers/misc/dummy-irq.c                    |    2 -
 drivers/mmc/host/wbsd.c                     |    8 ++-
 drivers/net/appletalk/cops.c                |    6 +-
 drivers/net/appletalk/ltpc.c                |    6 +-
 drivers/net/arcnet/com20020-isa.c           |    4 +-
 drivers/net/arcnet/com90io.c                |    4 +-
 drivers/net/arcnet/com90xx.c                |    4 +-
 drivers/net/can/cc770/cc770_isa.c           |    8 ++-
 drivers/net/can/sja1000/sja1000_isa.c       |    8 ++-
 drivers/net/ethernet/3com/3c509.c           |    2 -
 drivers/net/ethernet/3com/3c59x.c           |    4 +-
 drivers/net/ethernet/8390/ne.c              |    4 +-
 drivers/net/ethernet/8390/smc-ultra.c       |    4 +-
 drivers/net/ethernet/8390/wd.c              |    8 ++-
 drivers/net/ethernet/amd/lance.c            |    6 +-
 drivers/net/ethernet/amd/ni65.c             |    6 +-
 drivers/net/ethernet/cirrus/cs89x0.c        |    6 +-
 drivers/net/ethernet/dec/tulip/de4x5.c      |    2 -
 drivers/net/ethernet/hp/hp100.c             |    2 -
 drivers/net/ethernet/realtek/atp.c          |    4 +-
 drivers/net/ethernet/smsc/smc9194.c         |    4 +-
 drivers/net/hamradio/baycom_epp.c           |    2 -
 drivers/net/hamradio/baycom_par.c           |    2 -
 drivers/net/hamradio/baycom_ser_fdx.c       |    4 +-
 drivers/net/hamradio/baycom_ser_hdx.c       |    4 +-
 drivers/net/hamradio/dmascc.c               |    2 -
 drivers/net/irda/ali-ircc.c                 |    6 +-
 drivers/net/irda/nsc-ircc.c                 |    6 +-
 drivers/net/irda/smsc-ircc2.c               |   10 ++--
 drivers/net/irda/w83977af_ir.c              |    4 +-
 drivers/net/wan/cosa.c                      |    6 +-
 drivers/net/wan/hostess_sv11.c              |    6 +-
 drivers/net/wan/sbni.c                      |    4 +-
 drivers/net/wan/sealevel.c                  |    8 ++-
 drivers/net/wireless/cisco/airo.c           |    4 +-
 drivers/parport/parport_pc.c                |    8 ++-
 drivers/pci/hotplug/cpcihp_generic.c        |    2 -
 drivers/pcmcia/i82365.c                     |    8 ++-
 drivers/pcmcia/tcic.c                       |    8 ++-
 drivers/scsi/aha152x.c                      |    4 +-
 drivers/scsi/aha1542.c                      |    2 -
 drivers/scsi/g_NCR5380.c                    |    8 ++-
 drivers/scsi/gdth.c                         |    2 -
 drivers/scsi/qlogicfas.c                    |    4 +-
 drivers/staging/i4l/act2000/module.c        |    6 +-
 drivers/staging/i4l/icn/icn.c               |    4 +-
 drivers/staging/i4l/pcbit/module.c          |    4 +-
 drivers/staging/media/lirc/lirc_parallel.c  |    4 +-
 drivers/staging/media/lirc/lirc_serial.c    |   10 ++--
 drivers/staging/media/lirc/lirc_sir.c       |    4 +-
 drivers/staging/speakup/speakup_acntpc.c    |    2 -
 drivers/staging/speakup/speakup_dtlk.c      |    2 -
 drivers/staging/speakup/speakup_keypc.c     |    2 -
 drivers/staging/vme/devices/vme_pio2_core.c |    8 ++-
 drivers/tty/cyclades.c                      |    4 +-
 drivers/tty/moxa.c                          |    2 -
 drivers/tty/mxser.c                         |    2 -
 drivers/tty/rocket.c                        |   10 ++--
 drivers/tty/serial/8250/8250_core.c         |    4 +-
 drivers/tty/synclink.c                      |    6 +-
 drivers/video/fbdev/arcfb.c                 |    8 ++-
 drivers/video/fbdev/n411.c                  |    6 +-
 drivers/watchdog/cpu5wdt.c                  |    2 -
 drivers/watchdog/eurotechwdt.c              |    4 +-
 drivers/watchdog/pc87413_wdt.c              |    2 -
 drivers/watchdog/sc1200wdt.c                |    2 -
 drivers/watchdog/wdt.c                      |    4 +-
 fs/pstore/ram.c                             |    2 -
 include/linux/moduleparam.h                 |   65 +++++++++++++++++++++++++++
 sound/drivers/mpu401/mpu401.c               |    4 +-
 sound/drivers/mtpav.c                       |    4 +-
 sound/drivers/serial-u16550.c               |    4 +-
 sound/isa/ad1848/ad1848.c                   |    6 +-
 sound/isa/adlib.c                           |    2 -
 sound/isa/cmi8328.c                         |   12 ++---
 sound/isa/cmi8330.c                         |   20 ++++----
 sound/isa/cs423x/cs4231.c                   |   12 ++---
 sound/isa/cs423x/cs4236.c                   |   18 ++++---
 sound/isa/es1688/es1688.c                   |   12 ++---
 sound/isa/es18xx.c                          |   12 ++---
 sound/isa/galaxy/galaxy.c                   |   16 +++----
 sound/isa/gus/gusclassic.c                  |    8 ++-
 sound/isa/gus/gusextreme.c                  |   16 +++----
 sound/isa/gus/gusmax.c                      |    8 ++-
 sound/isa/gus/interwave.c                   |   10 ++--
 sound/isa/msnd/msnd_pinnacle.c              |   20 ++++----
 sound/isa/opl3sa2.c                         |   16 +++----
 sound/isa/opti9xx/miro.c                    |   14 +++---
 sound/isa/opti9xx/opti92x-ad1848.c          |   14 +++---
 sound/isa/sb/jazz16.c                       |   12 ++---
 sound/isa/sb/sb16.c                         |   14 +++---
 sound/isa/sb/sb8.c                          |    6 +-
 sound/isa/sc6000.c                          |   12 ++---
 sound/isa/sscape.c                          |   12 ++---
 sound/isa/wavefront/wavefront.c             |   18 ++++---
 sound/oss/ad1848.c                          |    8 ++-
 sound/oss/aedsp16.c                         |   12 ++---
 sound/oss/mpu401.c                          |    4 +-
 sound/oss/msnd_pinnacle.c                   |   20 ++++----
 sound/oss/opl3.c                            |    2 -
 sound/oss/pas2_card.c                       |   18 ++++---
 sound/oss/pss.c                             |   14 +++---
 sound/oss/sb_card.c                         |   10 ++--
 sound/oss/trix.c                            |   18 ++++---
 sound/oss/uart401.c                         |    4 +-
 sound/oss/uart6850.c                        |    4 +-
 sound/oss/waveartist.c                      |    8 ++-
 sound/pci/als4000.c                         |    2 -
 sound/pci/cmipci.c                          |    6 +-
 sound/pci/ens1370.c                         |    2 -
 sound/pci/riptide/riptide.c                 |    6 +-
 sound/pci/sonicvibes.c                      |    2 -
 sound/pci/via82xx.c                         |    2 -
 sound/pci/ymfpci/ymfpci.c                   |    6 +-
 138 files changed, 498 insertions(+), 435 deletions(-)

Provided an annotation for module parameters that specify hardware parameters (such as io ports, iomem addresses, irqs, dma channels, fixed dma buffers and other types).

This will enable such parameters to be locked down in the core parameter parser for secure boot support.

I've also included annotations as to what sort of hardware configuration each module is dealing with for future use. Some of these are straightforward (ioport, iomem, irq, dma), but there are also:

(1) drivers that switch the semantics of a parameter between ioport and iomem depending on a second parameter,

(2) drivers that appear to reserve a CPU memory buffer at a fixed address,

(3) other parameters, such as bus types and irq selection bitmasks.

For the moment, the hardware configuration type isn't actually stored, though its validity is checked.

---

 include/linux/moduleparam.h |   65 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 64 insertions(+), 1 deletion(-)

index 52666d90ca94..6be1949ebcdf 100644
@@ -60,9 +60,11 @@ struct kernel_param_ops {
  * Flags available for kernel_param
  *
  * UNSAFE - the parameter is dangerous and setting it will taint the kernel
+ * HWPARAM - Hardware param not permitted in lockdown mode
  */
 enum {
-	KERNEL_PARAM_FL_UNSAFE = (1 << 0)
+	KERNEL_PARAM_FL_UNSAFE	= (1 << 0),
+	KERNEL_PARAM_FL_HWPARAM	= (1 << 1),
 };
 
 struct kernel_param {

@@ -451,6 +453,67 @@ extern int param_set_bint(const char *val, const struct kernel_param *kp);
 			    perm, -1, 0);				\
 	__MODULE_PARM_TYPE(name, "array of " #type)
 
+enum hwparam_type {
+	hwparam_ioport,		/* Module parameter configures an I/O port */
+	hwparam_iomem,		/* Module parameter configures an I/O mem address */
+	hwparam_ioport_or_iomem, /* Module parameter could be either, depending on other option */
+	hwparam_irq,		/* Module parameter configures an I/O port */
+	hwparam_dma,		/* Module parameter configures a DMA channel */
+	hwparam_dma_addr,	/* Module parameter configures a DMA buffer address */
+	hwparam_other,		/* Module parameter configures some other value */
+};
+
+/**
+ * module_param_hw_named - A parameter representing a hw parameters
+ * @name: a valid C identifier which is the parameter name.
+ * @value: the actual lvalue to alter.
+ * @type: the type of the parameter
+ * @hwtype: what the value represents (enum hwparam_type)
+ * @perm: visibility in sysfs.
+ *
+ * Usually it's a good idea to have variable names and user-exposed names the
+ * same, but that's harder if the variable must be non-static or is inside a
+ * structure.  This allows exposure under a different name.
+ */
+#define module_param_hw_named(name, value, type, hwtype, perm)		\
+	param_check_##type(name, &(value));				\
+	__module_param_call(MODULE_PARAM_PREFIX, name,			\
+			    &param_ops_##type, &value,			\
+			    perm, -1,					\
+			    KERNEL_PARAM_FL_HWPARAM | (hwparam_##hwtype & 0));	\
+	__MODULE_PARM_TYPE(name, #type)
+
+#define module_param_hw(name, type, hwtype, perm)		\
+	module_param_hw_named(name, name, type, hwtype, perm)
+
+/**
+ * module_param_hw_array - A parameter representing an array of hw parameters
+ * @name: the name of the array variable
+ * @type: the type, as per module_param()
+ * @hwtype: what the value represents (enum hwparam_type)
+ * @nump: optional pointer filled in with the number written
+ * @perm: visibility in sysfs
+ *
+ * Input and output are as comma-separated values.  Commas inside values
+ * don't work properly (eg. an array of charp).
+ *
+ * ARRAY_SIZE(@name) is used to determine the number of elements in the
+ * array, so the definition must be visible.
+ */
+#define module_param_hw_array(name, type, hwtype, nump, perm)		\
+	param_check_##type(name, &(name)[0]);				\
+	static const struct kparam_array __param_arr_##name		\
+	= { .max = ARRAY_SIZE(name), .num = nump,			\
+	    .ops = &param_ops_##type,					\
+	    .elemsize = sizeof(name[0]), .elem = name };		\
+	__module_param_call(MODULE_PARAM_PREFIX, name,			\
+			    &param_array_ops,				\
+			    .arr = &__param_arr_##name,			\
+			    perm, -1,					\
+			    KERNEL_PARAM_FL_HWPARAM | (hwparam_##hwtype & 0));	\
+	__MODULE_PARM_TYPE(name, "array of " #type)
+
+
 extern const struct kernel_param_ops param_array_ops;
 
 extern const struct kernel_param_ops param_ops_string;

ick ick ick.

First off, this "secure boot support" massive patchset has not gone anywhere yet, so why do this now? Also, I think Alan's comment about it the last time it came up was more like a "look at all of the other ways you could do bad things to hardware!" comment, not a "you need to also do this thing too!" type of request.

I certianly do not see how this makes anything "more secure" at all. And I thought the last time this came up, Linus also objected to it, which is why the patchset never went anywhere.

Secure boot is a trust that the previous boot process is now booting your image that it feels is secure (with various levels of "secure"). It is not about "lock things down so no one can ever touch the hardware through different options, except through random logic[1] that we somehow trust "more" than configuration options.

So, what are you really trying to "block" here? The ability for someone to set an i/o port value? why? Why does it matter what root sets for an irq? For a dma buffer? For anything else? What is preventing this going to "secure" somehow?

Overall, I really don't like this, and honestly, don't like the whole "secure boot" patchset either, as it is really a lot of work for absolutely no gain that I can see. Who is "asking" for this type of thing, and what are their specific requirements?

thanks,

greg k-h

[1] Really, do you trust random driver writers to get things more "correct" than allowing people to get their hardware to work properly with module parameters? I know driver writers, and really, I trust users more than them...

Alan said:

You need to filter or lock down kernel module options because a lot of modules let you set the I/O port or similar (eg mmio) which means you can hack the entire machine with say the 8250 driver just by using it with an mmio of the right location to patch the secure state to zero just by getting the ability to write to the modules conf file.

I'm not entirely sure how one would do it, but Alan seems to think it can be done.

To continue quoting Alan:

Without that at least fixed I don't see the point in merging this. Either we don't do it (which given the level of security the current Linux kernel provides, and also all the golden key messups from elsewhere might be the honest approach), or at least try and do the job right.

Alan also said this:

It is - so pushing something with known trivial holes isn't a useful way to do this. The module parameter hole needs to be addressed before this is fit for upstream.

So you and Alan present something of a conflict of ordering: for Alan, I have to fix the module parameter hole first; for you, I have to do the secure boot support first.

I'll grant that prohibiting the changing of irq settings or dma channel settings may not actually be necessary. However, annotation module parameters to indicate hardware resource configuration seems potentially useful in its own right - and lets the policy be decided later.

Setting ioports and iomem might allow you to get a driver for one piece of hardware to do something nasty with an unrelated piece of hardware. I really need Alan to weigh in on this.

David

In all honesty I think both need to go in together, otherwise the first patch is useless. It's not a case of "oh there may be another obscure exploit .." , this is "I can automate it with a python script, post a CVE, and show I'm awesome" 8)

Alan

What about all of the ways you can change ioports dynamically from ioctls? Or can't python write ioctls to device nodes? :)

thanks,

greg k-h

Do you mean change the ioport a driver uses by ioctl or actually read/write an ioport directly?

Do the following patches that I've already posted address your issues:

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=efi-lock-down&id=c67c338dd82d28c67d38eb3147368eb36dbf1c16

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=efi-lock-down&id=10bd7277eef5194ba038fc2d907bac9e6aeab12b

They're going to be in a patchset that I am/was intending to sit atop the module parameter-lockdown patchset.

David

change the ioport a driver uses. The tty layer can do this for UARTs through an ioctl (can't remember which one off the top of my head, sorry, it gets reported as a bug by the syscall fuzzers every other year or so when they crash the kernel randomly...)

Ah, I hadn't seen those, that's a good start, and does close some other places.

thanks,

greg k-h

Because David ended up with the short straw when distro maintainers talked about this at LPC.

If root is able to modify the behaviour of verified code after it was verified, then the value of that verification is reduced. Ensuring that the code remains trustworthy is vital in a number of security use cases.

If root can tell a driver to probe for hardware at a specific address, and that driver will then blindly do so, root is trivially able to modify arbitrary kernel memory and disable arbitrary security features. IRQ or io port attacks are much more difficult to take advantage of, but I could imagine that some of them are still plausible.

Here's an example. The sysfs option to enable module signing is write once. If root sets that, root can't unset it. Except there's a whole bunch of ways that root *can* unset it, including kexec
(https://mjg59.dreamwidth.org/28746.html) and a bunch of other things that are disabled by this patchset. That feature is entirely useless as is. This patchset helps make it useful.

Right now, the secure boot patchset is shipped by basically every single mainstream Linux distribution (and a whole bunch that are niche). Right now they're having to do extra work to rebase it and ensure that fixes get distributed to everyone. There's clearly demand, and Linus has been clear that features that are shipped by everyone should just go into mainline, so if there are *technical* objections then let's figure them out and otherwise just get this stuff merged.

--
Matthew Garrett | [email protected]

Ok, but why are you now deciding to somehow try to "classify" the types of module parameters? Why would you want to allow irqs to change, but not iobase? Or something else? Who is going to do this "I want you and you but not you" decision? Why not just forbid all module parameters at all if they are so dangerous?

Then just mark them all as "bad", why pick and choose?

"this" patchset does nothing to disable anything, so I can't speak to any of the other goals you might have for that code, that's not what we are reviewing here.

"this stuff" is brand new things, that no one is shipping. And nothing "just goes" into mainline, no matter what foolish stuff distros end up shipping (an example, do you want the giant Xen kernel patchset that SuSE has been dragging around for 10+ years?)

Come on, you know better than this, each patch/series/feature has to be justifable on it's own, and this patchset, as-is, doesn't pass that test to me, if for no other reason than it is just "marking" things that is never then being used.

thanks,

greg k-h

If the parameters plausibly make it possible for root to modify the kernel in interesting ways, then restricting them makes sense. My gut sense is that parameters that allow the alteration of the base address of memory mapped devices are clearly a problem in this respect, but port io and IRQs *probably* aren't. On the other hand, blocking mmio base addresses and not blocking the others is kind of inconsistent.

Most parameters are going to be fine, but sure, flagging all IRQ/mmio/pio address parameters seems reasonable.

This is prep work that makes it possible to block module parameters that would otherwise make it possible to avoid those restrictions.

This is a logical extension to the base patchset, and one maintainer has NAKed the base patchset due to it lacking this feature. If you don't care about this then just tell Alan that you want the base patchset merged anyway and we'll go from there. Let's not get into a situation where people are being given incompatible requirements before something's merged.

Matthew Garrett | [email protected]

It is actually useful even without secure boot because right now DAC capability bypass is easier to get and gives you CAP_SYS_RAWIO if you've mastered your first class in being an 3733t h4x0r. (because you can modify /etc/moprobe.d/* and even with signed modules that's not protected).

It's also the case if you go through those drivers that pretty much none of them are found on a modern EFI and secure boot enabled system and those that are will be using ACPI, PCI, devicetree or other reliablish bus enumerations instead. The cross section of people needing io=foo, and having secure boot is close to nil.

The base patchset actually doesn't do anything without it. I'd hope the vendors adopt it anyway if they are serious about secure boot (or security in general) given it's really valuable even without the secure boot firmware nonsense to be able to boot a machine and then lock down raw I/O access.

Alan

Because Alan says that locking down the module parameters needs to be done first. Since I had to go through and modify each module parameter to mark the hardware config ones, it seemed like a good opportunity to label their type (ioport, iomem, irq, etc.) whilst I was at it.

Because some drivers, IPMI for example, can also be autoconfigured via PCI, PNP, ACPI or whatever and still be useful, if not important, to the system's operation.

Simply marking all drivers that can be so configured as "bad" and rejecting them outright in lockdown mode is a non-starter.

That is correct, I even say as much in the cover note and patch 1.

With this patchset, I'm hoping maintainers will check the annotations are correct and point out anything I've missed. There are a lot of module parameters and not so much consistency in schemes for naming parameters and their variables.

True, but my other two patchsets are primarily made up of things people *are* shipping. If you're happy to for those to go in and can persuade Alan to okay deferral of module parameter lockdown for an extra cycle, that's fine by me.

You're being unreasonable. The complete set is on the order of 90 patches, I think. I could submit them all in one go in a single series, but then people would be complaining that it's too big and that I have to split it up.

I have broken it up into a number of logical series, of which I've published some:

(1) Determining the EFI secure boot state. This only depends on tip efi/core. This mostly takes what the ARM arch already does upstream and extends it to x86 too.

(2) Marking hardware config module params. Patches 2+ all depend on patch 1, but there are no dependencies outside of that series. If I could get patch 1 upstream, I could distribute patches 2+ individually to the maintainers.

(3) Kernel lockdown. This takes the determination made by (1) and applies it, enabling various lockdowns, including locking down anything annotated in (2).

(4) System blacklist. List hashes to be blacklisted. This is independent of all other series.

(5) UEFI/SHIM whitelist/blacklist loading. This has a dependency on some constants added in (1).

I have to do them in some order. Doing it this way means that some of these are self-contained, making it technically easier to upstream those pieces.

David

Sorry, I meant to mark all of these types of attributes as "bad", not trying to classify all of the different types of attributes, given that you will probably want to just ban all of them or none, right?

I'll defer to Alan as to what he feels is needed here, given that this patchset isn't being shipped by anyone I think it's odd to somehow make this a pre-requisite for anything to be merged as no real user of the patchset seemed to feel this type of thing was needed :)

These are hashes of what?

I think patch 3 is going to be the "hardest", along with 2, given the large area it touches. Why not work on the other bits first?

thanks,

greg k-h

That was my intent. However, since I was touching every hardware module param anyway, it seemed like a good thing to add. At least now one can grep for every config param that explicitly sets a DMA channel, for example.

But unless I post it, no one's going to review it. Granted, I should probably have stuck "RFC" in the subject.

Hashes of module content, kexec image content, X.509 toBeSigned content, firmware blobs. Things that are going to get hashes blacklisted in the UEFI database.

Because not everyone agrees with you on the order. Further, some of the bits are independent - (2) vs (4)/(5) for example. Besides, I have patchsets for
(1) and (3). There is a patch in (3) that depends on (2), but that could be moved across.

David

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in arch/x86/mm/.

---

 arch/x86/mm/testmmiotrace.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 38868adf07ea..f6ae6830b341 100644
@@ -9,7 +9,7 @@
 #include <linux/mmiotrace.h>
 
 static unsigned long mmio_address;
-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).");
 

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/char/ipmi/.

---

 drivers/char/ipmi/ipmi_si_intf.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

index a112c0146012..157e96391eca 100644
@@ -1375,39 +1375,39 @@ MODULE_PARM_DESC(type, "Defines the type of each interface, each"
 		 " interface separated by commas.  The types are 'kcs',"
 		 " 'smic', and 'bt'.  For example si_type=kcs,bt will set"
 		 " the first interface to kcs and the second to bt");
-module_param_array(addrs, ulong, &num_addrs, 0);
+module_param_hw_array(addrs, ulong, iomem, &num_addrs, 0);
 MODULE_PARM_DESC(addrs, "Sets the memory address of each interface, the"
 		 " addresses separated by commas.  Only use if an interface"
 		 " is in memory.  Otherwise, set it to zero or leave"
 		 " it blank.");
-module_param_array(ports, uint, &num_ports, 0);
+module_param_hw_array(ports, uint, ioport, &num_ports, 0);
 MODULE_PARM_DESC(ports, "Sets the port address of each interface, the"
 		 " addresses separated by commas.  Only use if an interface"
 		 " is a port.  Otherwise, set it to zero or leave"
 		 " it blank.");
-module_param_array(irqs, int, &num_irqs, 0);
+module_param_hw_array(irqs, int, irq, &num_irqs, 0);
 MODULE_PARM_DESC(irqs, "Sets the interrupt of each interface, the"
 		 " addresses separated by commas.  Only use if an interface"
 		 " has an interrupt.  Otherwise, set it to zero or leave"
 		 " it blank.");
-module_param_array(regspacings, int, &num_regspacings, 0);
+module_param_hw_array(regspacings, int, other, &num_regspacings, 0);
 MODULE_PARM_DESC(regspacings, "The number of bytes between the start address"
 		 " and each successive register used by the interface.  For"
 		 " instance, if the start address is 0xca2 and the spacing"
 		 " is 2, then the second address is at 0xca4.  Defaults"
 		 " to 1.");
-module_param_array(regsizes, int, &num_regsizes, 0);
+module_param_hw_array(regsizes, int, other, &num_regsizes, 0);
 MODULE_PARM_DESC(regsizes, "The size of the specific IPMI register in bytes."
 		 " This should generally be 1, 2, 4, or 8 for an 8-bit,"
 		 " 16-bit, 32-bit, or 64-bit register.  Use this if you"
 		 " the 8-bit IPMI register has to be read from a larger"
 		 " register.");
-module_param_array(regshifts, int, &num_regshifts, 0);
+module_param_hw_array(regshifts, int, other, &num_regshifts, 0);
 MODULE_PARM_DESC(regshifts, "The amount to shift the data read from the."
 		 " IPMI register, in bits.  For instance, if the data"
 		 " is read from a 32-bit word and the IPMI data is in"
 		 " bit 8-15, then the shift would be 8");
-module_param_array(slave_addrs, int, &num_slave_addrs, 0);
+module_param_hw_array(slave_addrs, int, other, &num_slave_addrs, 0);
 MODULE_PARM_DESC(slave_addrs, "Set the default IPMB slave address for"
 		 " the controller.  Normally this is 0x20, but can be"
 		 " overridden by this parm.  This is an array indexed"

Reviewed by: Corey Minyard <[email protected]>

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/char/mwave/.

---

 drivers/char/mwave/mwavedd.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

index 3a3ff2eb6cba..b5e3103c1175 100644
@@ -80,10 +80,10 @@ int mwave_3780i_io = 0;
 int mwave_uart_irq = 0;
 int mwave_uart_io = 0;
 module_param(mwave_debug, int, 0);
-module_param(mwave_3780i_irq, int, 0);
-module_param(mwave_3780i_io, int, 0);
-module_param(mwave_uart_irq, int, 0);
-module_param(mwave_uart_io, int, 0);
+module_param_hw(mwave_3780i_irq, int, irq, 0);
+module_param_hw(mwave_3780i_io, int, ioport, 0);
+module_param_hw(mwave_uart_irq, int, irq, 0);
+module_param_hw(mwave_uart_io, int, ioport, 0);
 
 static int mwave_open(struct inode *inode, struct file *file);
 static int mwave_close(struct inode *inode, struct file *file);

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/char/.

---

 drivers/char/applicom.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index 14790304b84b..b1bf7a687a59 100644
@@ -94,9 +94,9 @@ static struct applicom_board {
 static unsigned int irq = 0;	/* interrupt number IRQ       */
 static unsigned long mem = 0;	/* physical segment of board  */
 
-module_param(irq, uint, 0);
+module_param_hw(irq, uint, irq, 0);
 MODULE_PARM_DESC(irq, "IRQ of the Applicom board");
-module_param(mem, ulong, 0);
+module_param_hw(mem, ulong, iomem, 0);
 MODULE_PARM_DESC(mem, "Shared Memory Address of Applicom board");
 
 static unsigned int numboards;	/* number of installed boards */

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/clocksource/.

---

 drivers/clocksource/cs5535-clockevt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 9a7e37cf56b0..a1df588343f2 100644
@@ -22,7 +22,7 @@
 #define DRV_NAME "cs5535-clockevt"
 
 static int timer_irq;
-module_param_named(irq, timer_irq, int, 0644);
+module_param_hw_named(irq, timer_irq, int, irq, 0644);
 MODULE_PARM_DESC(irq, "Which IRQ to use for the clock source MFGPT ticks.");
 
 /*

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/cpufreq/.

---

 drivers/cpufreq/speedstep-smi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 770a9ae1999a..37b30071c220 100644
@@ -378,7 +378,7 @@ static void __exit speedstep_exit(void)
 	cpufreq_unregister_driver(&speedstep_driver);
 }
 
-module_param(smi_port, int, 0444);
+module_param_hw(smi_port, int, ioport, 0444);
 module_param(smi_cmd,  int, 0444);
 module_param(smi_sig, uint, 0444);
 

I can try bearding Linus. All of the second+ patches depend on the first, so if nothing else, I need to get that one in the next merge window and then send the patches to individual maintainers.

David

OK

You can add my ACK to this one if that helps.

Thanks,
Rafael

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/gpio/.

---

 drivers/gpio/gpio-104-dio-48e.c |    4 ++--
 drivers/gpio/gpio-104-idi-48.c  |    4 ++--
 drivers/gpio/gpio-104-idio-16.c |    4 ++--
 drivers/gpio/gpio-gpio-mm.c     |    2 +-
 drivers/gpio/gpio-ws16c48.c     |    4 ++--
 5 files changed, 9 insertions(+), 9 deletions(-)

index fcf776971ca9..1c334eed5821 100644
@@ -33,11 +33,11 @@
 
 static unsigned int base[MAX_NUM_DIO48E];
 static unsigned int num_dio48e;
-module_param_array(base, uint, &num_dio48e, 0);
+module_param_hw_array(base, uint, ioport, &num_dio48e, 0);
 MODULE_PARM_DESC(base, "ACCES 104-DIO-48E base addresses");
 
 static unsigned int irq[MAX_NUM_DIO48E];
-module_param_array(irq, uint, NULL, 0);
+module_param_hw_array(irq, uint, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "ACCES 104-DIO-48E interrupt line numbers");
 
 /**

index 2d2763ea1a68..6639920b3299 100644
@@ -33,11 +33,11 @@
 
 static unsigned int base[MAX_NUM_IDI_48];
 static unsigned int num_idi_48;
-module_param_array(base, uint, &num_idi_48, 0);
+module_param_hw_array(base, uint, ioport, &num_idi_48, 0);
 MODULE_PARM_DESC(base, "ACCES 104-IDI-48 base addresses");
 
 static unsigned int irq[MAX_NUM_IDI_48];
-module_param_array(irq, uint, NULL, 0);
+module_param_hw_array(irq, uint, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "ACCES 104-IDI-48 interrupt line numbers");
 
 /**

index 6787b8fcf0d8..6d7024ac2689 100644
@@ -33,11 +33,11 @@
 
 static unsigned int base[MAX_NUM_IDIO_16];
 static unsigned int num_idio_16;
-module_param_array(base, uint, &num_idio_16, 0);
+module_param_hw_array(base, uint, ioport, &num_idio_16, 0);
 MODULE_PARM_DESC(base, "ACCES 104-IDIO-16 base addresses");
 
 static unsigned int irq[MAX_NUM_IDIO_16];
-module_param_array(irq, uint, NULL, 0);
+module_param_hw_array(irq, uint, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "ACCES 104-IDIO-16 interrupt line numbers");
 
 /**

index 1e7def9449ce..4ac2179b96ad 100644
@@ -31,7 +31,7 @@
 
 static unsigned int base[MAX_NUM_GPIOMM];
 static unsigned int num_gpiomm;
-module_param_array(base, uint, &num_gpiomm, 0);
+module_param_hw_array(base, uint, ioport, &num_gpiomm, 0);
 MODULE_PARM_DESC(base, "Diamond Systems GPIO-MM base addresses");
 
 /**

index eaa71d440ccf..c84d600a8bb0 100644
@@ -30,11 +30,11 @@
 
 static unsigned int base[MAX_NUM_WS16C48];
 static unsigned int num_ws16c48;
-module_param_array(base, uint, &num_ws16c48, 0);
+module_param_hw_array(base, uint, ioport, &num_ws16c48, 0);
 MODULE_PARM_DESC(base, "WinSystems WS16C48 base addresses");
 
 static unsigned int irq[MAX_NUM_WS16C48];
-module_param_array(irq, uint, NULL, 0);
+module_param_hw_array(irq, uint, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "WinSystems WS16C48 interrupt line numbers");
 
 /**

Yours,
Linus Walleij

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/i2c/.

---

 drivers/i2c/busses/i2c-elektor.c       |    6 +++---
 drivers/i2c/busses/i2c-parport-light.c |    4 ++--
 drivers/i2c/busses/i2c-pca-isa.c       |    4 ++--
 drivers/i2c/busses/scx200_acb.c        |    2 +-
 4 files changed, 8 insertions(+), 8 deletions(-)

index 8af62fb3fe41..5416003e0605 100644
@@ -323,9 +323,9 @@ MODULE_AUTHOR("Hans Berglund <[email protected]>");
 MODULE_DESCRIPTION("I2C-Bus adapter routines for PCF8584 ISA bus adapter");
 MODULE_LICENSE("GPL");
 
-module_param(base, int, 0);
-module_param(irq, int, 0);
+module_param_hw(base, int, ioport_or_iomem, 0);
+module_param_hw(irq, int, irq, 0);
 module_param(clock, int, 0);
 module_param(own, int, 0);
-module_param(mmapped, int, 0);
+module_param_hw(mmapped, int, other, 0);
 module_isa_driver(i2c_elektor_driver, 1);

index 1bcdd10b68b9..faa8fb8f2b8f 100644
@@ -38,11 +38,11 @@
 static struct platform_device *pdev;
 
 static u16 base;
-module_param(base, ushort, 0);
+module_param_hw(base, ushort, ioport, 0);
 MODULE_PARM_DESC(base, "Base I/O address");
 
 static int irq;
-module_param(irq, int, 0);
+module_param_hw(irq, int, irq, 0);
 MODULE_PARM_DESC(irq, "IRQ (optional)");
 
 /* ----- Low-level parallel port access ----------------------------------- */

index ba88f17f636c..946ac646de2a 100644
@@ -197,9 +197,9 @@ MODULE_AUTHOR("Ian Campbell <[email protected]>");
 MODULE_DESCRIPTION("ISA base PCA9564/PCA9665 driver");
 MODULE_LICENSE("GPL");
 
-module_param(base, ulong, 0);
+module_param_hw(base, ulong, ioport, 0);
 MODULE_PARM_DESC(base, "I/O base address");
-module_param(irq, int, 0);
+module_param_hw(irq, int, irq, 0);
 MODULE_PARM_DESC(irq, "IRQ");
 module_param(clock, int, 0);
 MODULE_PARM_DESC(clock, "Clock rate in hertz.\n\t\t"

index 0a7e410b6195..e0923bee8d1f 100644
@@ -42,7 +42,7 @@ MODULE_LICENSE("GPL");
 
 #define MAX_DEVICES 4
 static int base[MAX_DEVICES] = { 0x820, 0x840 };
-module_param_array(base, int, NULL, 0);
+module_param_hw_array(base, int, ioport, NULL, 0);
 MODULE_PARM_DESC(base, "Base addresses for the ACCESS.bus controllers");
 
 #define POLL_TIMEOUT	(HZ/5)

Hi David,

Initializing the driver when you are not able to honor the user request looks wrong to me. I don't see how some drivers having sane defaults justifies that. Using the defaults when no parameters are passed is one thing (good), still using the defaults when parameters are passed is another (bad), and you should be able to differentiate between these two cases.

I know this is only a Suggested-by and not a Signed-off-by, but still I believe the Developer's Certificate of Origin applies, and it says:
"using your real name (sorry, no pseudonyms or anonymous contributions.)"

Jean Delvare
SUSE L3 Support

Corey Minyard argues the other way:

This would prevent any IPMI interface from working if any address was given on the kernel command line. I'm not sure what the best policy is, but that sounds like a possible DOS to me.

Your preference allows someone to prevent a driver from initialising - which could also be bad. The problem is that I don't think there's any way to do both.

Note that the policy isn't actually handled in any of these patches, but will be handled in a later patchset that is on top of my EFI changes also.

I asked him what he prefers - but no response.

Okay, thanks. They all seem to encode ioports. All changed.

I don't know either. One could argue it *should* be locked down because its need appears to reflect a BIOS bug.

David

I'm not sure what is your threat model, but I'm afraid that if the attacker can change the kernel command line, he/she has so many ways to screw up the machine, that removing one won't make a difference.

Indeed. OTOH if you remove all kernel code that is there solely due to BIOS bugs, then you can rename Secure Boot to No Boot. Well that's certainly one way to be secure ;-)

Jean Delvare
SUSE L3 Support

O> > > Suggested-by: One Thousand Gnomes <[email protected]>

I didn't see that question but "Alan Cox" is probably saner - the thousand gnomes is an old Linus joke 8)

And none of those should show up in that usage form on a box new enough to have EFI secure boot. Those that do have i2c busses will report them via ACPI by that period.

Alan

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/iio/.

---

 drivers/iio/adc/stx104.c  |    2 +-
 drivers/iio/dac/cio-dac.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

index 7e3645749eaf..a805bd543acb 100644
@@ -49,7 +49,7 @@
 
 static unsigned int base[max_num_isa_dev(STX104_EXTENT)];
 static unsigned int num_stx104;
-module_param_array(base, uint, &num_stx104, 0);
+module_param_hw_array(base, uint, ioport, &num_stx104, 0);
 MODULE_PARM_DESC(base, "Apex Embedded Systems STX104 base addresses");
 
 /**

index 5a743e2a779d..dac086129edf 100644
@@ -39,7 +39,7 @@
 
 static unsigned int base[max_num_isa_dev(CIO_DAC_EXTENT)];
 static unsigned int num_cio_dac;
-module_param_array(base, uint, &num_cio_dac, 0);
+module_param_hw_array(base, uint, ioport, &num_cio_dac, 0);
 MODULE_PARM_DESC(base, "Measurement Computing CIO-DAC base addresses");
 
 /**

Hi David,

I'm on a train so can't check the original thread right now (and will probably forget to do so later!). I am guessing the new functions are introduced earlier in the series? Hence for now I'll assume you want to merge this lot in one go.

Shout if you want me to take this via the IIO tree after the merge window closes.

Thanks,

Jonathan

obably

Yeah, patch 1 is a prerequisite for all the subsequent patches.

I'll see if I can get patch 1 in and then distribute the other patches.

David

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/input/.

---

 drivers/input/mouse/inport.c      |    2 +-
 drivers/input/mouse/logibm.c      |    2 +-
 drivers/input/touchscreen/mk712.c |    4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

index 3827a22362de..9ce71dfa0de1 100644
@@ -78,7 +78,7 @@ MODULE_LICENSE("GPL");
 #define INPORT_IRQ		5
 
 static int inport_irq = INPORT_IRQ;
-module_param_named(irq, inport_irq, uint, 0);
+module_param_hw_named(irq, inport_irq, uint, irq, 0);
 MODULE_PARM_DESC(irq, "IRQ number (5=default)");
 
 static struct input_dev *inport_dev;

index e2413113df22..6f165e053f4d 100644
@@ -69,7 +69,7 @@ MODULE_LICENSE("GPL");
 #define LOGIBM_IRQ		5
 
 static int logibm_irq = LOGIBM_IRQ;
-module_param_named(irq, logibm_irq, uint, 0);
+module_param_hw_named(irq, logibm_irq, uint, irq, 0);
 MODULE_PARM_DESC(irq, "IRQ number (5=default)");
 
 static struct input_dev *logibm_dev;

index 36e57deacd03..bd5352824f77 100644
@@ -50,11 +50,11 @@ MODULE_DESCRIPTION("ICS MicroClock MK712 TouchScreen driver");
 MODULE_LICENSE("GPL");
 
 static unsigned int mk712_io = 0x260;	/* Also 0x200, 0x208, 0x300 */
-module_param_named(io, mk712_io, uint, 0);
+module_param_hw_named(io, mk712_io, uint, ioport, 0);
 MODULE_PARM_DESC(io, "I/O base address of MK712 touchscreen controller");
 
 static unsigned int mk712_irq = 10;	/* Also 12, 14, 15 */
-module_param_named(irq, mk712_irq, uint, 0);
+module_param_hw_named(irq, mk712_irq, uint, irq, 0);
 MODULE_PARM_DESC(irq, "IRQ of MK712 touchscreen controller");
 
 /* eight 8-bit registers */

Please merge with the rest of patches.

Dmitry

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/isdn/.

---

 drivers/isdn/hardware/avm/b1isa.c |    4 ++--
 drivers/isdn/hardware/avm/t1isa.c |    4 ++--
 drivers/isdn/hisax/config.c       |   10 +++++-----
 3 files changed, 9 insertions(+), 9 deletions(-)

index 31ef8130a87f..54e871a47387 100644
@@ -169,8 +169,8 @@ static struct pci_dev isa_dev[MAX_CARDS];
 static int io[MAX_CARDS];
 static int irq[MAX_CARDS];
 
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 MODULE_PARM_DESC(io, "I/O base address(es)");
 MODULE_PARM_DESC(irq, "IRQ number(s) (assigned)");
 

index 72ef18853951..9516203c735f 100644
@@ -516,8 +516,8 @@ static int io[MAX_CARDS];
 static int irq[MAX_CARDS];
 static int cardnr[MAX_CARDS];
 
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param_array(cardnr, int, NULL, 0);
 MODULE_PARM_DESC(io, "I/O base address(es)");
 MODULE_PARM_DESC(irq, "IRQ number(s) (assigned)");

index bf04d2a3cf4a..30da1bc106f0 100644
@@ -350,13 +350,13 @@ MODULE_AUTHOR("Karsten Keil");
 MODULE_LICENSE("GPL");
 module_param_array(type, int, NULL, 0);
 module_param_array(protocol, int, NULL, 0);
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
-module_param_array(mem, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
+module_param_hw_array(mem, int, iomem, NULL, 0);
 module_param(id, charp, 0);
 #ifdef IO0_IO1
-module_param_array(io0, int, NULL, 0);
-module_param_array(io1, int, NULL, 0);
+module_param_hw_array(io0, int, ioport, NULL, 0);
+module_param_hw_array(io1, int, ioport, NULL, 0);
 #endif
 #endif /* MODULE */
 

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/media/.

---

 drivers/media/pci/zoran/zoran_card.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 9d2697f5b455..3a03a0df7999 100644
@@ -73,7 +73,7 @@ MODULE_PARM_DESC(card, "Card type");
  */
 
 static unsigned long vidmem;	/* default = 0 - Video memory base address */
-module_param(vidmem, ulong, 0444);
+module_param_hw(vidmem, ulong, iomem, 0444);
 MODULE_PARM_DESC(vidmem, "Default video memory base address");
 
 /*

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/misc/.

---

 drivers/misc/dummy-irq.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index acbbe0390be4..76a1015d5783 100644
@@ -59,6 +59,6 @@ module_exit(dummy_irq_exit);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Jiri Kosina");
-module_param(irq, uint, 0444);
+module_param_hw(irq, uint, irq, 0444);
 MODULE_PARM_DESC(irq, "The IRQ to register for");
 MODULE_DESCRIPTION("Dummy IRQ handler driver");

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/mmc/host/.

---

 drivers/mmc/host/wbsd.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

index c3fd16d997ca..76c7f643fab5 100644
@@ -1995,11 +1995,11 @@ static void __exit wbsd_drv_exit(void)
 module_init(wbsd_drv_init);
 module_exit(wbsd_drv_exit);
 #ifdef CONFIG_PNP
-module_param_named(nopnp, param_nopnp, uint, 0444);
+module_param_hw_named(nopnp, param_nopnp, uint, other, 0444);
 #endif
-module_param_named(io, param_io, uint, 0444);
-module_param_named(irq, param_irq, uint, 0444);
-module_param_named(dma, param_dma, int, 0444);
+module_param_hw_named(io, param_io, uint, ioport, 0444);
+module_param_hw_named(irq, param_irq, uint, irq, 0444);
+module_param_hw_named(dma, param_dma, int, dma, 0444);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Pierre Ossman <[email protected]>");

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/net/appletalk/.

---

 drivers/net/appletalk/cops.c |    6 +++---
 drivers/net/appletalk/ltpc.c |    6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

index 1b2e9217ec78..486e1e6997fc 100644
@@ -986,9 +986,9 @@ static int cops_close(struct net_device *dev)
 static struct net_device *cops_dev;
 
 MODULE_LICENSE("GPL");
-module_param(io, int, 0);
-module_param(irq, int, 0);
-module_param(board_type, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
+module_param_hw(board_type, int, other, 0);
 
 static int __init cops_module_init(void)
 {

index 01e2ac55c137..ac755d2950a6 100644
@@ -1231,9 +1231,9 @@ static struct net_device *dev_ltpc;
 
 MODULE_LICENSE("GPL");
 module_param(debug, int, 0);
-module_param(io, int, 0);
-module_param(irq, int, 0);
-module_param(dma, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
+module_param_hw(dma, int, dma, 0);
 
 
 static int __init ltpc_module_init(void)

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/net/arcnet/.

---

 drivers/net/arcnet/com20020-isa.c |    4 ++--
 drivers/net/arcnet/com90io.c      |    4 ++--
 drivers/net/arcnet/com90xx.c      |    4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

index b9e9931353b2..38fa60ddaf2e 100644
@@ -129,8 +129,8 @@ static int clockp = 0;
 static int clockm = 0;
 
 module_param(node, int, 0);
-module_param(io, int, 0);
-module_param(irq, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
 module_param_string(device, device, sizeof(device), 0);
 module_param(timeout, int, 0);
 module_param(backplane, int, 0);

index b57863df5bf5..4e56aaf2b984 100644
@@ -347,8 +347,8 @@ static int io;			/* use the insmod io= irq= shmem= options */
 static int irq;
 static char device[9];		/* use eg. device=arc1 to change name */
 
-module_param(io, int, 0);
-module_param(irq, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
 module_param_string(device, device, sizeof(device), 0);
 MODULE_LICENSE("GPL");
 

index 81f90c4703ae..ca4a57c30bf8 100644
@@ -88,8 +88,8 @@ static int irq;
 static int shmem;
 static char device[9];		/* use eg. device=arc1 to change name */
 
-module_param(io, int, 0);
-module_param(irq, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
 module_param(shmem, int, 0);
 module_param_string(device, device, sizeof(device), 0);
 

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/net/can/.

---

 drivers/net/can/cc770/cc770_isa.c     |    8 ++++----
 drivers/net/can/sja1000/sja1000_isa.c |    8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

index e0d15711e9ac..3a30fd3b4498 100644
@@ -82,16 +82,16 @@ static u8 cor[MAXDEV] = {[0 ... (MAXDEV - 1)] = 0xff};
 static u8 bcr[MAXDEV] = {[0 ... (MAXDEV - 1)] = 0xff};
 static int indirect[MAXDEV] = {[0 ... (MAXDEV - 1)] = -1};
 
-module_param_array(port, ulong, NULL, S_IRUGO);
+module_param_hw_array(port, ulong, ioport, NULL, S_IRUGO);
 MODULE_PARM_DESC(port, "I/O port number");
 
-module_param_array(mem, ulong, NULL, S_IRUGO);
+module_param_hw_array(mem, ulong, iomem, NULL, S_IRUGO);
 MODULE_PARM_DESC(mem, "I/O memory address");
 
-module_param_array(indirect, int, NULL, S_IRUGO);
+module_param_hw_array(indirect, int, ioport, NULL, S_IRUGO);
 MODULE_PARM_DESC(indirect, "Indirect access via address and data port");
 
-module_param_array(irq, int, NULL, S_IRUGO);
+module_param_hw_array(irq, int, irq, NULL, S_IRUGO);
 MODULE_PARM_DESC(irq, "IRQ number");
 
 module_param_array(clk, int, NULL, S_IRUGO);

index e97e6d35b300..a89c1e92554d 100644
@@ -48,16 +48,16 @@ static unsigned char ocr[MAXDEV] = {[0 ... (MAXDEV - 1)] = 0xff};
 static int indirect[MAXDEV] = {[0 ... (MAXDEV - 1)] = -1};
 static spinlock_t indirect_lock[MAXDEV];  /* lock for indirect access mode */
 
-module_param_array(port, ulong, NULL, S_IRUGO);
+module_param_hw_array(port, ulong, ioport, NULL, S_IRUGO);
 MODULE_PARM_DESC(port, "I/O port number");
 
-module_param_array(mem, ulong, NULL, S_IRUGO);
+module_param_hw_array(mem, ulong, iomem, NULL, S_IRUGO);
 MODULE_PARM_DESC(mem, "I/O memory address");
 
-module_param_array(indirect, int, NULL, S_IRUGO);
+module_param_hw_array(indirect, int, ioport, NULL, S_IRUGO);
 MODULE_PARM_DESC(indirect, "Indirect access via address and data port");
 
-module_param_array(irq, int, NULL, S_IRUGO);
+module_param_hw_array(irq, int, irq, NULL, S_IRUGO);
 MODULE_PARM_DESC(irq, "IRQ number");
 
 module_param_array(clk, int, NULL, S_IRUGO);

regards,
Marc

Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/net/ethernet/.

---

 drivers/net/ethernet/3com/3c509.c      |    2 +-
 drivers/net/ethernet/3com/3c59x.c      |    4 ++--
 drivers/net/ethernet/8390/ne.c         |    4 ++--
 drivers/net/ethernet/8390/smc-ultra.c  |    4 ++--
 drivers/net/ethernet/8390/wd.c         |    8 ++++----
 drivers/net/ethernet/amd/lance.c       |    6 +++---
 drivers/net/ethernet/amd/ni65.c        |    6 +++---
 drivers/net/ethernet/cirrus/cs89x0.c   |    6 +++---
 drivers/net/ethernet/dec/tulip/de4x5.c |    2 +-
 drivers/net/ethernet/hp/hp100.c        |    2 +-
 drivers/net/ethernet/realtek/atp.c     |    4 ++--
 drivers/net/ethernet/smsc/smc9194.c    |    4 ++--
 12 files changed, 26 insertions(+), 26 deletions(-)

index 91ada52f776b..33a6d67ee182 100644
@@ -1369,7 +1369,7 @@ el3_resume(struct device *pdev)
 #endif /* CONFIG_PM */
 
 module_param(debug,int, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param(max_interrupt_work, int, 0);
 MODULE_PARM_DESC(debug, "debug level (0-6)");
 MODULE_PARM_DESC(irq, "IRQ number(s) (assigned)");

index 9133e7926da5..d041e3c7c3e6 100644
@@ -813,8 +813,8 @@ module_param(global_enable_wol, int, 0);
 module_param_array(enable_wol, int, NULL, 0);
 module_param(rx_copybreak, int, 0);
 module_param(max_interrupt_work, int, 0);
-module_param(compaq_ioaddr, int, 0);
-module_param(compaq_irq, int, 0);
+module_param_hw(compaq_ioaddr, int, ioport, 0);
+module_param_hw(compaq_irq, int, irq, 0);
 module_param(compaq_device_id, int, 0);
 module_param(watchdog, int, 0);
 module_param(global_use_mmio, int, 0);

index c063b410a163..66f47987e2a2 100644
@@ -74,8 +74,8 @@ static int bad[MAX_NE_CARDS];
 static u32 ne_msg_enable;
 
 #ifdef MODULE
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param_array(bad, int, NULL, 0);
 module_param_named(msg_enable, ne_msg_enable, uint, (S_IRUSR|S_IRGRP|S_IROTH));
 MODULE_PARM_DESC(io, "I/O base address(es),required");

index 139385dcdaa7..c5dbf6938a4e 100644
@@ -562,8 +562,8 @@ static struct net_device *dev_ultra[MAX_ULTRA_CARDS];
 static int io[MAX_ULTRA_CARDS];
 static int irq[MAX_ULTRA_CARDS];
 
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param_named(msg_enable, ultra_msg_enable, uint, (S_IRUSR|S_IRGRP|S_IROTH));
 MODULE_PARM_DESC(io, "I/O base address(es)");
 MODULE_PARM_DESC(irq, "IRQ number(s) (assigned)");

index dd7d816bde52..e16deef661e3 100644
@@ -504,10 +504,10 @@ static int irq[MAX_WD_CARDS];
 static int mem[MAX_WD_CARDS];
 static int mem_end[MAX_WD_CARDS];	/* for non std. mem size */
 
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
-module_param_array(mem, int, NULL, 0);
-module_param_array(mem_end, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
+module_param_hw_array(mem, int, iomem, NULL, 0);
+module_param_hw_array(mem_end, int, iomem, NULL, 0);
 module_param_named(msg_enable, wd_msg_enable, uint, (S_IRUSR|S_IRGRP|S_IROTH));
 MODULE_PARM_DESC(io, "I/O base address(es)");
 MODULE_PARM_DESC(irq, "IRQ number(s) (ignored for PureData boards)");

index abb1ba228b26..1b5603c30bd2 100644
@@ -318,9 +318,9 @@ static int io[MAX_CARDS];
 static int dma[MAX_CARDS];
 static int irq[MAX_CARDS];
 
-module_param_array(io, int, NULL, 0);
-module_param_array(dma, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(dma, int, dma, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param(lance_debug, int, 0);
 MODULE_PARM_DESC(io, "LANCE/PCnet I/O base address(es),required");
 MODULE_PARM_DESC(dma, "LANCE/PCnet ISA DMA channel (ignored for some devices)");

index cda53db75f17..8b2e4deefdd4 100644
@@ -1228,9 +1228,9 @@ static void set_multicast_list(struct net_device *dev)
 #ifdef MODULE
 static struct net_device *dev_ni65;
 
-module_param(irq, int, 0);
-module_param(io, int, 0);
-module_param(dma, int, 0);
+module_param_hw(irq, int, irq, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(dma, int, dma, 0);
 MODULE_PARM_DESC(irq, "ni6510 IRQ number (ignored for some cards)");
 MODULE_PARM_DESC(io, "ni6510 I/O base address");
 MODULE_PARM_DESC(dma, "ni6510 ISA DMA channel (ignored for some cards)");

index c363b58552e9..424f62b28c63 100644
@@ -1705,12 +1705,12 @@ static int use_dma;			/* These generate unused var warnings if ALLOW_DMA = 0 */
 static int dma;
 static int dmasize = 16;		/* or 64 */
 
-module_param(io, int, 0);
-module_param(irq, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
 module_param(debug, int, 0);
 module_param_string(media, media, sizeof(media), 0);
 module_param(duplex, int, 0);
-module_param(dma , int, 0);
+module_param_hw(dma , int, dma, 0);
 module_param(dmasize , int, 0);
 module_param(use_dma , int, 0);
 MODULE_PARM_DESC(io, "cs89x0 I/O base address");

index 6620fc861c47..9ba1a318916d 100644
@@ -1015,7 +1015,7 @@ static int     compact_infoblock(struct net_device *dev, u_char count, u_char *p
 
 static int io=0x0;/* EDIT THIS LINE FOR YOUR CONFIGURATION IF NEEDED        */
 
-module_param(io, int, 0);
+module_param_hw(io, int, ioport, 0);
 module_param(de4x5_debug, int, 0);
 module_param(dec_only, int, 0);
 module_param(args, charp, 0);

index 631dbc7b4dbb..eab44abb24ba 100644
@@ -2968,7 +2968,7 @@ MODULE_DESCRIPTION("HP CASCADE Architecture Driver for 100VG-AnyLan Network Adap
 #define HP100_DEVICES 5
 /* Parameters set by insmod */
 static int hp100_port[HP100_DEVICES] = { 0, [1 ... (HP100_DEVICES-1)] = -1 };
-module_param_array(hp100_port, int, NULL, 0);
+module_param_hw_array(hp100_port, int, ioport, NULL, 0);
 
 /* List of devices */
 static struct net_device *hp100_devlist[HP100_DEVICES];

index 5cb96785fb63..619938322915 100644
@@ -151,8 +151,8 @@ MODULE_LICENSE("GPL");
 
 module_param(max_interrupt_work, int, 0);
 module_param(debug, int, 0);
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param_array(xcvr, int, NULL, 0);
 MODULE_PARM_DESC(max_interrupt_work, "ATP maximum events handled per interrupt");
 MODULE_PARM_DESC(debug, "ATP debug level (0-7)");

index d496888b85d3..1bfae24066ce 100644
@@ -1502,8 +1502,8 @@ static void smc_set_multicast_list(struct net_device *dev)
 static struct net_device *devSMC9194;
 MODULE_LICENSE("GPL");
 
-module_param(io, int, 0);
-module_param(irq, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
 module_param(ifport, int, 0);
 MODULE_PARM_DESC(io, "SMC 99194 I/O base address");
 MODULE_PARM_DESC(irq, "SMC 99194 IRQ number");

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/net/hamradio/.

---

 drivers/net/hamradio/baycom_epp.c     |    2 +-
 drivers/net/hamradio/baycom_par.c     |    2 +-
 drivers/net/hamradio/baycom_ser_fdx.c |    4 ++--
 drivers/net/hamradio/baycom_ser_hdx.c |    4 ++--
 drivers/net/hamradio/dmascc.c         |    2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

index 78dbc44540f6..a50b72144b93 100644
@@ -1172,7 +1172,7 @@ static int iobase[NR_PORTS] = { 0x378, };
 
 module_param_array(mode, charp, NULL, 0);
 MODULE_PARM_DESC(mode, "baycom operating mode");
-module_param_array(iobase, int, NULL, 0);
+module_param_hw_array(iobase, int, ioport, NULL, 0);
 MODULE_PARM_DESC(iobase, "baycom io base address");
 
 MODULE_AUTHOR("Thomas M. Sailer, [email protected], [email protected]");

index 072cddce9264..cb7fe200f347 100644
@@ -481,7 +481,7 @@ static int iobase[NR_PORTS] = { 0x378, };
 
 module_param_array(mode, charp, NULL, 0);
 MODULE_PARM_DESC(mode, "baycom operating mode; eg. par96 or picpar");
-module_param_array(iobase, int, NULL, 0);
+module_param_hw_array(iobase, int, ioport, NULL, 0);
 MODULE_PARM_DESC(iobase, "baycom io base address");
 
 MODULE_AUTHOR("Thomas M. Sailer, [email protected], [email protected]");

index 7b916d5b14b9..36d49c89d601 100644
@@ -614,9 +614,9 @@ static int baud[NR_PORTS] = { [0 ... NR_PORTS-1] = 1200 };
 
 module_param_array(mode, charp, NULL, 0);
 MODULE_PARM_DESC(mode, "baycom operating mode; * for software DCD");
-module_param_array(iobase, int, NULL, 0);
+module_param_hw_array(iobase, int, ioport, NULL, 0);
 MODULE_PARM_DESC(iobase, "baycom io base address");
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "baycom irq number");
 module_param_array(baud, int, NULL, 0);
 MODULE_PARM_DESC(baud, "baycom baud rate (300 to 4800)");

index f9a8976195ba..1b310493ba8a 100644
@@ -642,9 +642,9 @@ static int irq[NR_PORTS] = { 4, };
 
 module_param_array(mode, charp, NULL, 0);
 MODULE_PARM_DESC(mode, "baycom operating mode; * for software DCD");
-module_param_array(iobase, int, NULL, 0);
+module_param_hw_array(iobase, int, ioport, NULL, 0);
 MODULE_PARM_DESC(iobase, "baycom io base address");
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "baycom irq number");
 
 MODULE_AUTHOR("Thomas M. Sailer, [email protected], [email protected]");

index e4137c1b3df9..f94ca7b91899 100644
@@ -274,7 +274,7 @@ static unsigned long rand;
 
 MODULE_AUTHOR("Klaus Kudielka");
 MODULE_DESCRIPTION("Driver for high-speed SCC boards");
-module_param_array(io, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
 MODULE_LICENSE("GPL");
 
 static void __exit dmascc_exit(void)

Hello Everyone,

Considering some of the recent toxicity that snuck into the Linux AX.25 codebase, is there anyone here that is still using some of the Baycom TNC hardware that could apply this patch and TEST their systems to ensure they continue to work as expected?

--David
KI6ZHD

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/net/irda/.

---

 drivers/net/irda/ali-ircc.c    |    6 +++---
 drivers/net/irda/nsc-ircc.c    |    6 +++---
 drivers/net/irda/smsc-ircc2.c  |   10 +++++-----
 drivers/net/irda/w83977af_ir.c |    4 ++--
 4 files changed, 13 insertions(+), 13 deletions(-)

index c285eafd3f1c..35f198d83701 100644
@@ -2207,11 +2207,11 @@ MODULE_LICENSE("GPL");
 MODULE_ALIAS("platform:" ALI_IRCC_DRIVER_NAME);
 
 
-module_param_array(io, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
 MODULE_PARM_DESC(io, "Base I/O addresses");
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "IRQ lines");
-module_param_array(dma, int, NULL, 0);
+module_param_hw_array(dma, int, dma, NULL, 0);
 MODULE_PARM_DESC(dma, "DMA channels");
 
 module_init(ali_ircc_init);

index aaecc3baaf30..7beae147be11 100644
@@ -2396,11 +2396,11 @@ MODULE_LICENSE("GPL");
 
 module_param(qos_mtt_bits, int, 0);
 MODULE_PARM_DESC(qos_mtt_bits, "Minimum Turn Time");
-module_param_array(io, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
 MODULE_PARM_DESC(io, "Base I/O addresses");
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "IRQ lines");
-module_param_array(dma, int, NULL, 0);
+module_param_hw_array(dma, int, dma, NULL, 0);
 MODULE_PARM_DESC(dma, "DMA channels");
 module_param(dongle_id, int, 0);
 MODULE_PARM_DESC(dongle_id, "Type-id of used dongle");

index dcf92ba80872..23ed89ae5ddc 100644
@@ -82,24 +82,24 @@ MODULE_PARM_DESC(nopnp, "Do not use PNP to detect controller settings, defaults
 
 #define DMA_INVAL 255
 static int ircc_dma = DMA_INVAL;
-module_param(ircc_dma, int, 0);
+module_param_hw(ircc_dma, int, dma, 0);
 MODULE_PARM_DESC(ircc_dma, "DMA channel");
 
 #define IRQ_INVAL 255
 static int ircc_irq = IRQ_INVAL;
-module_param(ircc_irq, int, 0);
+module_param_hw(ircc_irq, int, irq, 0);
 MODULE_PARM_DESC(ircc_irq, "IRQ line");
 
 static int ircc_fir;
-module_param(ircc_fir, int, 0);
+module_param_hw(ircc_fir, int, ioport, 0);
 MODULE_PARM_DESC(ircc_fir, "FIR Base Address");
 
 static int ircc_sir;
-module_param(ircc_sir, int, 0);
+module_param_hw(ircc_sir, int, ioport, 0);
 MODULE_PARM_DESC(ircc_sir, "SIR Base Address");
 
 static int ircc_cfg;
-module_param(ircc_cfg, int, 0);
+module_param_hw(ircc_cfg, int, ioport, 0);
 MODULE_PARM_DESC(ircc_cfg, "Configuration register base address");
 
 static int ircc_transceiver;

index 4e3d2e7c697c..f15d8752864b 100644
@@ -1264,9 +1264,9 @@ MODULE_LICENSE("GPL");
 
 module_param(qos_mtt_bits, int, 0);
 MODULE_PARM_DESC(qos_mtt_bits, "Mimimum Turn Time");
-module_param_array(io, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
 MODULE_PARM_DESC(io, "Base I/O addresses");
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "IRQ lines");
 
 /*

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/net/wan/.

---

 drivers/net/wan/cosa.c         |    6 +++---
 drivers/net/wan/hostess_sv11.c |    6 +++---
 drivers/net/wan/sbni.c         |    4 ++--
 drivers/net/wan/sealevel.c     |    8 ++++----
 4 files changed, 12 insertions(+), 12 deletions(-)

index b87fe0a01c69..2f7104e92dd8 100644
@@ -232,11 +232,11 @@ static int irq[MAX_CARDS+1] = { -1, -1, -1, -1, -1, -1, 0, };
 static struct class *cosa_class;
 
 #ifdef MODULE
-module_param_array(io, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
 MODULE_PARM_DESC(io, "The I/O bases of the COSA or SRP cards");
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "The IRQ lines of the COSA or SRP cards");
-module_param_array(dma, int, NULL, 0);
+module_param_hw_array(dma, int, dma, NULL, 0);
 MODULE_PARM_DESC(dma, "The DMA channels of the COSA or SRP cards");
 
 MODULE_AUTHOR("Jan \"Yenya\" Kasprzak, <[email protected]>");

index 3d741663fd67..4845560fd848 100644
@@ -325,11 +325,11 @@ static void sv11_shutdown(struct z8530_dev *dev)
 static int io = 0x200;
 static int irq = 9;
 
-module_param(io, int, 0);
+module_param_hw(io, int, ioport, 0);
 MODULE_PARM_DESC(io, "The I/O base of the Comtrol Hostess SV11 card");
-module_param(dma, int, 0);
+module_param_hw(dma, int, dma, 0);
 MODULE_PARM_DESC(dma, "Set this to 1 to use DMA1/DMA3 for TX/RX");
-module_param(irq, int, 0);
+module_param_hw(irq, int, irq, 0);
 MODULE_PARM_DESC(irq, "The interrupt line setting for the Comtrol Hostess SV11 card");
 
 MODULE_AUTHOR("Alan Cox");

index 3a421ca8a4d0..42220fa78093 100644
@@ -1464,8 +1464,8 @@ set_multicast_list( struct net_device  *dev )
 
 
 #ifdef MODULE
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param_array(baud, int, NULL, 0);
 module_param_array(rxl, int, NULL, 0);
 module_param_array(mac, int, NULL, 0);

index 27860b4f5908..1d762a2d3ddc 100644
@@ -364,13 +364,13 @@ static int rxdma=3;
 static int irq=5;
 static bool slow=false;
 
-module_param(io, int, 0);
+module_param_hw(io, int, ioport, 0);
 MODULE_PARM_DESC(io, "The I/O base of the Sealevel card");
-module_param(txdma, int, 0);
+module_param_hw(txdma, int, dma, 0);
 MODULE_PARM_DESC(txdma, "Transmit DMA channel");
-module_param(rxdma, int, 0);
+module_param_hw(rxdma, int, dma, 0);
 MODULE_PARM_DESC(rxdma, "Receive DMA channel");
-module_param(irq, int, 0);
+module_param_hw(irq, int, irq, 0);
 MODULE_PARM_DESC(irq, "The interrupt line setting for the SeaLevel card");
 module_param(slow, bool, 0);
 MODULE_PARM_DESC(slow, "Set this for an older Sealevel card such as the 4012");

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/net/wireless/.

---

 drivers/net/wireless/cisco/airo.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index 69b826d229c5..53d43c93a284 100644
@@ -246,8 +246,8 @@ MODULE_DESCRIPTION("Support for Cisco/Aironet 802.11 wireless ethernet cards.  "
 		   "Direct support for ISA/PCI/MPI cards and support for PCMCIA when used with airo_cs.");
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_SUPPORTED_DEVICE("Aironet 4500, 4800 and Cisco 340/350");
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param_array(rates, int, NULL, 0);
 module_param_array(ssids, charp, NULL, 0);
 module_param(auto_wep, int, 0);

Via which tree are you planning to submit this, should I take it to wireless-drivers or will someone else handle it? I didn't get the cover letter so I have no idea.

Kalle Valo

I'll see if I can get patch 1 (which defines the macros) in a window prior to the others - or maybe I can get Linus to apply all of these together.

David

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/parport/.

---

 drivers/parport/parport_pc.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

index 78530d1714dc..2080a0798d52 100644
@@ -3150,13 +3150,13 @@ static char *irq[PARPORT_PC_MAX_PORTS];
 static char *dma[PARPORT_PC_MAX_PORTS];
 
 MODULE_PARM_DESC(io, "Base I/O address (SPP regs)");
-module_param_array(io, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
 MODULE_PARM_DESC(io_hi, "Base I/O address (ECR)");
-module_param_array(io_hi, int, NULL, 0);
+module_param_hw_array(io_hi, int, ioport, NULL, 0);
 MODULE_PARM_DESC(irq, "IRQ line");
-module_param_array(irq, charp, NULL, 0);
+module_param_hw_array(irq, charp, irq, NULL, 0);
 MODULE_PARM_DESC(dma, "DMA channel");
-module_param_array(dma, charp, NULL, 0);
+module_param_hw_array(dma, charp, dma, NULL, 0);
 #if defined(CONFIG_PARPORT_PC_SUPERIO) || \
        (defined(CONFIG_PARPORT_1284) && defined(CONFIG_PARPORT_PC_FIFO))
 MODULE_PARM_DESC(verbose_probing, "Log chit-chat during initialisation");

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/pci/hotplug/.

---

 drivers/pci/hotplug/cpcihp_generic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 88a44a707b96..bbf9cf8aeaad 100644
@@ -220,7 +220,7 @@ module_param(first_slot, byte, 0);
 MODULE_PARM_DESC(first_slot, "Hotswap bus first slot number");
 module_param(last_slot, byte, 0);
 MODULE_PARM_DESC(last_slot, "Hotswap bus last slot number");
-module_param(port, ushort, 0);
+module_param_hw(port, ushort, ioport, 0);
 MODULE_PARM_DESC(port, "#ENUM signal I/O port");
 module_param(enum_bit, uint, 0);
 MODULE_PARM_DESC(enum_bit, "#ENUM signal bit (0-7)");

I assume you'll merge this via some non-PCI tree. Let me know if you need anything else from me.

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/pcmcia/.

---

 drivers/pcmcia/i82365.c |    8 ++++----
 drivers/pcmcia/tcic.c   |    8 ++++----
 2 files changed, 8 insertions(+), 8 deletions(-)

index eb0d80a429e4..fb38cc01859f 100644
@@ -108,12 +108,12 @@ static int async_clock = -1;
 static int cable_mode = -1;
 static int wakeup = 0;
 
-module_param(i365_base, ulong, 0444);
+module_param_hw(i365_base, ulong, ioport, 0444);
 module_param(ignore, int, 0444);
 module_param(extra_sockets, int, 0444);
-module_param(irq_mask, int, 0444);
-module_param_array(irq_list, int, &irq_list_count, 0444);
-module_param(cs_irq, int, 0444);
+module_param_hw(irq_mask, int, other, 0444);
+module_param_hw_array(irq_list, int, irq, &irq_list_count, 0444);
+module_param_hw(cs_irq, int, irq, 0444);
 module_param(async_clock, int, 0444);
 module_param(cable_mode, int, 0444);
 module_param(wakeup, int, 0444);

index 1ee63e5f0550..a1ac72d51d70 100644
@@ -85,12 +85,12 @@ static int poll_quick = HZ/20;
 /* CCLK external clock time, in nanoseconds.  70 ns = 14.31818 MHz */
 static int cycle_time = 70;
 
-module_param(tcic_base, ulong, 0444);
+module_param_hw(tcic_base, ulong, ioport, 0444);
 module_param(ignore, int, 0444);
 module_param(do_scan, int, 0444);
-module_param(irq_mask, int, 0444);
-module_param_array(irq_list, int, &irq_list_count, 0444);
-module_param(cs_irq, int, 0444);
+module_param_hw(irq_mask, int, other, 0444);
+module_param_hw_array(irq_list, int, irq, &irq_list_count, 0444);
+module_param_hw(cs_irq, int, irq, 0444);
 module_param(poll_interval, int, 0444);
 module_param(poll_quick, int, 0444);
 module_param(cycle_time, int, 0444);

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/scsi/.

---

 drivers/scsi/aha152x.c   |    4 ++--
 drivers/scsi/aha1542.c   |    2 +-
 drivers/scsi/g_NCR5380.c |    8 ++++----
 drivers/scsi/gdth.c      |    2 +-
 drivers/scsi/qlogicfas.c |    4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

index f44d0487236e..ce5dc73d85bb 100644
@@ -331,11 +331,11 @@ MODULE_LICENSE("GPL");
 #if !defined(PCMCIA)
 #if defined(MODULE)
 static int io[] = {0, 0};
-module_param_array(io, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
 MODULE_PARM_DESC(io,"base io address of controller");
 
 static int irq[] = {0, 0};
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 MODULE_PARM_DESC(irq,"interrupt for controller");
 
 static int scsiid[] = {7, 7};

index 7db448ec8beb..a23cc9ac5acd 100644
@@ -31,7 +31,7 @@ module_param(isapnp, bool, 0);
 MODULE_PARM_DESC(isapnp, "enable PnP support (default=1)");
 
 static int io[MAXBOARDS] = { 0x330, 0x334, 0, 0 };
-module_param_array(io, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
 MODULE_PARM_DESC(io, "base IO address of controller (0x130,0x134,0x230,0x234,0x330,0x334, default=0x330,0x334)");
 
 /* time AHA spends on the AT-bus during data transfer */

index cbf010324c18..cf4fa7a2e738 100644
@@ -44,8 +44,8 @@ static int ncr_53c400;
 static int ncr_53c400a;
 static int dtc_3181e;
 static int hp_c2502;
-module_param(ncr_irq, int, 0);
-module_param(ncr_addr, int, 0);
+module_param_hw(ncr_irq, int, irq, 0);
+module_param_hw(ncr_addr, int, ioport, 0);
 module_param(ncr_5380, int, 0);
 module_param(ncr_53c400, int, 0);
 module_param(ncr_53c400a, int, 0);

@@ -53,11 +53,11 @@ module_param(dtc_3181e, int, 0);
 module_param(hp_c2502, int, 0);
 
 static int irq[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 MODULE_PARM_DESC(irq, "IRQ number(s)");
 
 static int base[] = { 0, 0, 0, 0, 0, 0, 0, 0 };
-module_param_array(base, int, NULL, 0);
+module_param_hw_array(base, int, ioport, NULL, 0);
 MODULE_PARM_DESC(base, "base address(es)");
 
 static int card[] = { -1, -1, -1, -1, -1, -1, -1, -1 };

index 0a767740bf02..4ec08fb2dfa8 100644
@@ -353,7 +353,7 @@ static int probe_eisa_isa = 0;
 static int force_dma32 = 0;
 
 /* parameters for modprobe/insmod */
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 module_param(disable, int, 0);
 module_param(reserve_mode, int, 0);
 module_param_array(reserve_list, int, NULL, 0);

index 61cac87fb86f..840823b99e51 100644
@@ -137,8 +137,8 @@ static struct Scsi_Host *__qlogicfas_detect(struct scsi_host_template *host,
 static struct qlogicfas408_priv *cards;
 static int iobase[MAX_QLOGICFAS];
 static int irq[MAX_QLOGICFAS] = { [0 ... MAX_QLOGICFAS-1] = -1 };
-module_param_array(iobase, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(iobase, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 MODULE_PARM_DESC(iobase, "I/O address");
 MODULE_PARM_DESC(irq, "IRQ");
 

I can see how base addresses and IO ports are relevant, but the irq parameter changes below don't protect the kernel image AFAICT. What's the rationale for those changes? I think it should be stated here.

Easier grepping for one. But I'm also currently preventing the changing of any hardware parameters. If a driver refuses to share an irq, you could use it to deprive another driver of the ability to get an irq at all.

David

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/staging/i4l/.

---

 drivers/staging/i4l/act2000/module.c |    6 +++---
 drivers/staging/i4l/icn/icn.c        |    4 ++--
 drivers/staging/i4l/pcbit/module.c   |    4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

index 99c9c0a1c63e..b3c81e2af7b2 100644
@@ -40,9 +40,9 @@ MODULE_PARM_DESC(act_bus, "BusType of first card, 1=ISA, 2=MCA, 3=PCMCIA, curren
 MODULE_PARM_DESC(act_port, "Base port address of first card");
 MODULE_PARM_DESC(act_irq, "IRQ of first card");
 MODULE_PARM_DESC(act_id, "ID-String of first card");
-module_param(act_bus, int, 0);
-module_param(act_port, int, 0);
-module_param(act_irq, int, 0);
+module_param_hw(act_bus, int, other, 0);
+module_param_hw(act_port, int, ioport, 0);
+module_param_hw(act_irq, int, irq, 0);
 module_param(act_id, charp, 0);
 
 static int act2000_addcard(int, int, int, char *);

index 514bfc2c5b53..cadeee74e9f4 100644
@@ -23,9 +23,9 @@ static char *icn_id2 = "\0";
 MODULE_DESCRIPTION("ISDN4Linux: Driver for ICN active ISDN card");
 MODULE_AUTHOR("Fritz Elfert");
 MODULE_LICENSE("GPL");
-module_param(portbase, int, 0);
+module_param_hw(portbase, int, ioport, 0);
 MODULE_PARM_DESC(portbase, "Port address of first card");
-module_param(membase, ulong, 0);
+module_param_hw(membase, ulong, iomem, 0);
 MODULE_PARM_DESC(membase, "Shared memory address of all cards");
 module_param(icn_id, charp, 0);
 MODULE_PARM_DESC(icn_id, "ID-String of first card");

index 0a59bd0b8210..5a3ea2808351 100644
@@ -25,8 +25,8 @@ MODULE_LICENSE("GPL");
 static int mem[MAX_PCBIT_CARDS];
 static int irq[MAX_PCBIT_CARDS];
 
-module_param_array(mem, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(mem, int, iomem, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
 
 static int num_boards;
 struct pcbit_dev *dev_pcbit[MAX_PCBIT_CARDS];

When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is.

Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters.

This patch annotates drivers in drivers/staging/media/.