* [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
@ 2016-12-01 12:29 ` David Howells
2016-12-01 15:01 ` Greg KH
2016-12-01 16:02 ` David Howells
2016-12-01 12:29 ` [PATCH 02/39] Annotate hardware config module parameters in arch/x86/mm/ David Howells
` (37 subsequent siblings)
38 siblings, 2 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:29 UTC (permalink / raw)
To: linux-kernel; +Cc: dhowells, gnomes, linux-security-module, keyrings, minyard
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.
Signed-off-by: David Howells <dhowells@redhat.com>
---
include/linux/moduleparam.h | 65 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 64 insertions(+), 1 deletion(-)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 52666d90ca94..6be1949ebcdf 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -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, \
+ ¶m_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 = ¶m_ops_##type, \
+ .elemsize = sizeof(name[0]), .elem = name }; \
+ __module_param_call(MODULE_PARAM_PREFIX, name, \
+ ¶m_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;
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-01 12:29 ` [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) David Howells
@ 2016-12-01 15:01 ` Greg KH
2016-12-02 3:07 ` Matthew Garrett
2016-12-01 16:02 ` David Howells
1 sibling, 1 reply; 78+ messages in thread
From: Greg KH @ 2016-12-01 15:01 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, gnomes, linux-security-module, keyrings, minyard
On Thu, Dec 01, 2016 at 12:29:47PM +0000, David Howells wrote:
> 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.
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...
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-01 15:01 ` Greg KH
@ 2016-12-02 3:07 ` Matthew Garrett
2016-12-02 6:55 ` Greg KH
2016-12-02 14:59 ` David Howells
0 siblings, 2 replies; 78+ messages in thread
From: Matthew Garrett @ 2016-12-02 3:07 UTC (permalink / raw)
To: Greg KH
Cc: David Howells, linux-kernel, gnomes, linux-security-module,
keyrings, minyard
On Thu, Dec 01, 2016 at 04:01:35PM +0100, Greg KH wrote:
> First off, this "secure boot support" massive patchset has not gone
> anywhere yet, so why do this now?
Because David ended up with the short straw when distro maintainers
talked about this at LPC.
> 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.
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.
> 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?
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.
> 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?
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 | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-02 3:07 ` Matthew Garrett
@ 2016-12-02 6:55 ` Greg KH
2016-12-02 7:12 ` Matthew Garrett
2016-12-02 14:59 ` David Howells
1 sibling, 1 reply; 78+ messages in thread
From: Greg KH @ 2016-12-02 6:55 UTC (permalink / raw)
To: Matthew Garrett
Cc: David Howells, linux-kernel, gnomes, linux-security-module,
keyrings, minyard
On Fri, Dec 02, 2016 at 03:07:00AM +0000, Matthew Garrett wrote:
> On Thu, Dec 01, 2016 at 04:01:35PM +0100, Greg KH wrote:
>
> > First off, this "secure boot support" massive patchset has not gone
> > anywhere yet, so why do this now?
>
> Because David ended up with the short straw when distro maintainers
> talked about this at LPC.
>
> > 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.
>
> 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.
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?
> > 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?
>
> 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.
Then just mark them all as "bad", why pick and choose?
> > 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?
>
> 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.
"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.
> 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.
"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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-02 6:55 ` Greg KH
@ 2016-12-02 7:12 ` Matthew Garrett
2016-12-05 21:26 ` One Thousand Gnomes
0 siblings, 1 reply; 78+ messages in thread
From: Matthew Garrett @ 2016-12-02 7:12 UTC (permalink / raw)
To: Greg KH
Cc: David Howells, linux-kernel, gnomes, linux-security-module,
keyrings, minyard
On Fri, Dec 02, 2016 at 07:55:30AM +0100, Greg KH wrote:
> On Fri, Dec 02, 2016 at 03:07:00AM +0000, Matthew Garrett wrote:
> > 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.
>
> 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?
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.
> > 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.
>
> Then just mark them all as "bad", why pick and choose?
Most parameters are going to be fine, but sure, flagging all
IRQ/mmio/pio address parameters seems reasonable.
> > 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.
>
> "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 is prep work that makes it possible to block module parameters that
would otherwise make it possible to avoid those restrictions.
> > 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.
>
> "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?)
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 | mjg59@srcf.ucam.org
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-02 7:12 ` Matthew Garrett
@ 2016-12-05 21:26 ` One Thousand Gnomes
0 siblings, 0 replies; 78+ messages in thread
From: One Thousand Gnomes @ 2016-12-05 21:26 UTC (permalink / raw)
To: Matthew Garrett
Cc: Greg KH, David Howells, linux-kernel, linux-security-module,
keyrings, minyard
> 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.
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.
> 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.
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-02 3:07 ` Matthew Garrett
2016-12-02 6:55 ` Greg KH
@ 2016-12-02 14:59 ` David Howells
2016-12-05 15:47 ` Greg KH
2016-12-06 10:54 ` David Howells
1 sibling, 2 replies; 78+ messages in thread
From: David Howells @ 2016-12-02 14:59 UTC (permalink / raw)
To: Greg KH
Cc: dhowells, Matthew Garrett, linux-kernel, gnomes,
linux-security-module, keyrings, minyard
Greg KH <gregkh@linuxfoundation.org> wrote:
> > 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.
>
> Ok, but why are you now deciding to somehow try to "classify" the types
> of module parameters?
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.
> Then just mark them all as "bad", why pick and choose?
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.
> "this" patchset does nothing to disable anything,
That is correct, I even say as much in the cover note and patch 1.
> 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.
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.
> > Right now, the secure boot patchset
>
> "this stuff" is brand new things, that no one is shipping.
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.
> 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.
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
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-02 14:59 ` David Howells
@ 2016-12-05 15:47 ` Greg KH
2016-12-06 10:54 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: Greg KH @ 2016-12-05 15:47 UTC (permalink / raw)
To: David Howells
Cc: Matthew Garrett, linux-kernel, gnomes, linux-security-module,
keyrings, minyard
On Fri, Dec 02, 2016 at 02:59:22PM +0000, David Howells wrote:
> Greg KH <gregkh@linuxfoundation.org> wrote:
>
> > > 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.
> >
> > Ok, but why are you now deciding to somehow try to "classify" the types
> > of module parameters?
>
> 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.
>
> > Then just mark them all as "bad", why pick and choose?
>
> 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.
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?
> > > Right now, the secure boot patchset
> >
> > "this stuff" is brand new things, that no one is shipping.
>
> 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.
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 :)
> > 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.
>
> 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.
These are hashes of what?
> (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.
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-02 14:59 ` David Howells
2016-12-05 15:47 ` Greg KH
@ 2016-12-06 10:54 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-06 10:54 UTC (permalink / raw)
To: Greg KH
Cc: dhowells, Matthew Garrett, linux-kernel, gnomes,
linux-security-module, keyrings, minyard
Greg KH <gregkh@linuxfoundation.org> wrote:
> > 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.
> >
> > > Then just mark them all as "bad", why pick and choose?
> >
> > 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.
>
> 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?
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.
> 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 :)
But unless I post it, no one's going to review it. Granted, I should probably
have stuck "RFC" in the subject.
> > (4) System blacklist. List hashes to be blacklisted. This is independent
> > of all other series.
>
> These are hashes of what?
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.
> 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?
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-01 12:29 ` [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) David Howells
2016-12-01 15:01 ` Greg KH
@ 2016-12-01 16:02 ` David Howells
2016-12-05 21:12 ` One Thousand Gnomes
1 sibling, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-01 16:02 UTC (permalink / raw)
To: Greg KH
Cc: dhowells, linux-kernel, gnomes, linux-security-module, keyrings, minyard
Greg KH <gregkh@linuxfoundation.org> wrote:
> 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.
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.
> First off, this "secure boot support" massive patchset has not gone
> anywhere yet, so why do this now?
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.
> 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?
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-01 16:02 ` David Howells
@ 2016-12-05 21:12 ` One Thousand Gnomes
2016-12-06 7:11 ` Greg KH
2016-12-06 10:42 ` David Howells
0 siblings, 2 replies; 78+ messages in thread
From: One Thousand Gnomes @ 2016-12-05 21:12 UTC (permalink / raw)
To: David Howells
Cc: Greg KH, linux-kernel, linux-security-module, keyrings, minyard
On Thu, 01 Dec 2016 16:02:26 +0000
David Howells <dhowells@redhat.com> wrote:
> Greg KH <gregkh@linuxfoundation.org> wrote:
>
> > 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.
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-05 21:12 ` One Thousand Gnomes
@ 2016-12-06 7:11 ` Greg KH
2016-12-06 10:42 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: Greg KH @ 2016-12-06 7:11 UTC (permalink / raw)
To: One Thousand Gnomes
Cc: David Howells, linux-kernel, linux-security-module, keyrings, minyard
On Mon, Dec 05, 2016 at 09:12:27PM +0000, One Thousand Gnomes wrote:
> On Thu, 01 Dec 2016 16:02:26 +0000
> David Howells <dhowells@redhat.com> wrote:
>
> > Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > > 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.
>
>
> 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)
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-05 21:12 ` One Thousand Gnomes
2016-12-06 7:11 ` Greg KH
@ 2016-12-06 10:42 ` David Howells
2016-12-06 10:50 ` Greg KH
1 sibling, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-06 10:42 UTC (permalink / raw)
To: Greg KH
Cc: dhowells, One Thousand Gnomes, linux-kernel,
linux-security-module, keyrings, minyard
Greg KH <gregkh@linuxfoundation.org> wrote:
> What about all of the ways you can change ioports dynamically from
> ioctls? Or can't python write ioctls to device nodes? :)
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)
2016-12-06 10:42 ` David Howells
@ 2016-12-06 10:50 ` Greg KH
0 siblings, 0 replies; 78+ messages in thread
From: Greg KH @ 2016-12-06 10:50 UTC (permalink / raw)
To: David Howells
Cc: One Thousand Gnomes, linux-kernel, linux-security-module,
keyrings, minyard
On Tue, Dec 06, 2016 at 10:42:47AM +0000, David Howells wrote:
> Greg KH <gregkh@linuxfoundation.org> wrote:
>
> > What about all of the ways you can change ioports dynamically from
> > ioctls? Or can't python write ioctls to device nodes? :)
>
> Do you mean change the ioport a driver uses by ioctl or actually read/write an
> ioport directly?
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...)
> 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.
Ah, I hadn't seen those, that's a good start, and does close some other
places.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 02/39] Annotate hardware config module parameters in arch/x86/mm/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
2016-12-01 12:29 ` [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) David Howells
@ 2016-12-01 12:29 ` David Howells
2016-12-01 12:30 ` [PATCH 03/39] Annotate hardware config module parameters in drivers/char/ipmi/ David Howells
` (36 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:29 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, nouveau, x86, Steven Rostedt, dhowells,
linux-security-module, keyrings, H. Peter Anvin, Thomas Gleixner,
Ingo Molnar
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Steven Rostedt <rostedt@goodmis.org>
cc: Ingo Molnar <mingo@kernel.org>
cc: Thomas Gleixner <tglx@linutronix.de>
cc: "H. Peter Anvin" <hpa@zytor.com>
cc: x86@kernel.org
cc: linux-kernel@vger.kernel.org
cc: nouveau@lists.freedesktop.org
---
arch/x86/mm/testmmiotrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
index 38868adf07ea..f6ae6830b341 100644
--- a/arch/x86/mm/testmmiotrace.c
+++ b/arch/x86/mm/testmmiotrace.c
@@ -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).");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 03/39] Annotate hardware config module parameters in drivers/char/ipmi/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
2016-12-01 12:29 ` [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) David Howells
2016-12-01 12:29 ` [PATCH 02/39] Annotate hardware config module parameters in arch/x86/mm/ David Howells
@ 2016-12-01 12:30 ` David Howells
2016-12-01 13:14 ` Corey Minyard
2016-12-01 12:30 ` [PATCH 04/39] Annotate hardware config module parameters in drivers/char/mwave/ David Howells
` (35 subsequent siblings)
38 siblings, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-01 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, dhowells, linux-security-module, keyrings,
openipmi-developer
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Corey Minyard <minyard@acm.org>
cc: openipmi-developer@lists.sourceforge.net
---
drivers/char/ipmi/ipmi_si_intf.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index a112c0146012..157e96391eca 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -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"
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 03/39] Annotate hardware config module parameters in drivers/char/ipmi/
2016-12-01 12:30 ` [PATCH 03/39] Annotate hardware config module parameters in drivers/char/ipmi/ David Howells
@ 2016-12-01 13:14 ` Corey Minyard
0 siblings, 0 replies; 78+ messages in thread
From: Corey Minyard @ 2016-12-01 13:14 UTC (permalink / raw)
To: David Howells, linux-kernel
Cc: gnomes, linux-security-module, keyrings, openipmi-developer
On 12/01/2016 06:30 AM, David Howells wrote:
> 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/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Corey Minyard <minyard@acm.org>
> cc: openipmi-developer@lists.sourceforge.net
Reviewed by: Corey Minyard <cminyard@mvista.com>
> ---
>
> drivers/char/ipmi/ipmi_si_intf.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
> index a112c0146012..157e96391eca 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -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"
>
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 04/39] Annotate hardware config module parameters in drivers/char/mwave/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (2 preceding siblings ...)
2016-12-01 12:30 ` [PATCH 03/39] Annotate hardware config module parameters in drivers/char/ipmi/ David Howells
@ 2016-12-01 12:30 ` David Howells
2016-12-01 12:30 ` [PATCH 05/39] Annotate hardware config module parameters in drivers/char/ David Howells
` (34 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:30 UTC (permalink / raw)
To: linux-kernel; +Cc: dhowells, gnomes, linux-security-module, keyrings, minyard
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/char/mwave/mwavedd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/mwave/mwavedd.c b/drivers/char/mwave/mwavedd.c
index 3a3ff2eb6cba..b5e3103c1175 100644
--- a/drivers/char/mwave/mwavedd.c
+++ b/drivers/char/mwave/mwavedd.c
@@ -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);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 05/39] Annotate hardware config module parameters in drivers/char/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (3 preceding siblings ...)
2016-12-01 12:30 ` [PATCH 04/39] Annotate hardware config module parameters in drivers/char/mwave/ David Howells
@ 2016-12-01 12:30 ` David Howells
2016-12-01 12:30 ` [PATCH 06/39] Annotate hardware config module parameters in drivers/clocksource/ David Howells
` (33 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, Arnd Bergmann, minyard, Greg Kroah-Hartman, dhowells,
linux-security-module, keyrings
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Arnd Bergmann <arnd@arndb.de>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/applicom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/applicom.c b/drivers/char/applicom.c
index 14790304b84b..b1bf7a687a59 100644
--- a/drivers/char/applicom.c
+++ b/drivers/char/applicom.c
@@ -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 */
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 06/39] Annotate hardware config module parameters in drivers/clocksource/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (4 preceding siblings ...)
2016-12-01 12:30 ` [PATCH 05/39] Annotate hardware config module parameters in drivers/char/ David Howells
@ 2016-12-01 12:30 ` David Howells
2016-12-01 12:30 ` [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/ David Howells
` (32 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, Daniel Lezcano, dhowells, linux-security-module,
keyrings, Thomas Gleixner
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Daniel Lezcano <daniel.lezcano@linaro.org>
cc: Thomas Gleixner <tglx@linutronix.de>
cc: linux-kernel@vger.kernel.org
---
drivers/clocksource/cs5535-clockevt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/cs5535-clockevt.c b/drivers/clocksource/cs5535-clockevt.c
index 9a7e37cf56b0..a1df588343f2 100644
--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -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.");
/*
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (5 preceding siblings ...)
2016-12-01 12:30 ` [PATCH 06/39] Annotate hardware config module parameters in drivers/clocksource/ David Howells
@ 2016-12-01 12:30 ` David Howells
2016-12-01 14:02 ` Rafael J. Wysocki
2016-12-01 14:19 ` David Howells
2016-12-01 12:30 ` [PATCH 08/39] Annotate hardware config module parameters in drivers/gpio/ David Howells
` (31 subsequent siblings)
38 siblings, 2 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, linux-pm, Viresh Kumar, Rafael J. Wysocki,
dhowells, linux-security-module, keyrings
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
cc: Viresh Kumar <viresh.kumar@linaro.org>
cc: linux-pm@vger.kernel.org
---
drivers/cpufreq/speedstep-smi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
index 770a9ae1999a..37b30071c220 100644
--- a/drivers/cpufreq/speedstep-smi.c
+++ b/drivers/cpufreq/speedstep-smi.c
@@ -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);
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/
2016-12-01 12:30 ` [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/ David Howells
@ 2016-12-01 14:02 ` Rafael J. Wysocki
2016-12-01 14:19 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: Rafael J. Wysocki @ 2016-12-01 14:02 UTC (permalink / raw)
To: David Howells
Cc: Linux Kernel Mailing List, gnomes, minyard, Linux PM,
Viresh Kumar, Rafael J. Wysocki, linux-security-module, keyrings
On Thu, Dec 1, 2016 at 1:30 PM, David Howells <dhowells@redhat.com> wrote:
> 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/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> cc: Viresh Kumar <viresh.kumar@linaro.org>
> cc: linux-pm@vger.kernel.org
> ---
>
> drivers/cpufreq/speedstep-smi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/speedstep-smi.c b/drivers/cpufreq/speedstep-smi.c
> index 770a9ae1999a..37b30071c220 100644
> --- a/drivers/cpufreq/speedstep-smi.c
> +++ b/drivers/cpufreq/speedstep-smi.c
> @@ -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);
Looks OK to me.
Whom do you expect to apply this?
Thanks,
Rafael
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/
2016-12-01 12:30 ` [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/ David Howells
2016-12-01 14:02 ` Rafael J. Wysocki
@ 2016-12-01 14:19 ` David Howells
2016-12-01 14:21 ` Rafael J. Wysocki
1 sibling, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-01 14:19 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: dhowells, Linux Kernel Mailing List, gnomes, minyard, Linux PM,
Viresh Kumar, Rafael J. Wysocki, linux-security-module, keyrings
Rafael J. Wysocki <rafael@kernel.org> wrote:
> Whom do you expect to apply this?
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/
2016-12-01 14:19 ` David Howells
@ 2016-12-01 14:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 78+ messages in thread
From: Rafael J. Wysocki @ 2016-12-01 14:21 UTC (permalink / raw)
To: David Howells
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, gnomes, minyard,
Linux PM, Viresh Kumar, linux-security-module, keyrings
On Thursday, December 01, 2016 02:19:29 PM David Howells wrote:
> Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> > Whom do you expect to apply this?
>
> 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.
OK
You can add my ACK to this one if that helps.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 08/39] Annotate hardware config module parameters in drivers/gpio/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (6 preceding siblings ...)
2016-12-01 12:30 ` [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/ David Howells
@ 2016-12-01 12:30 ` David Howells
2016-12-01 13:49 ` William Breathitt Gray
2016-12-02 12:55 ` Linus Walleij
2016-12-01 12:30 ` [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/ David Howells
` (30 subsequent siblings)
38 siblings, 2 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: Alexandre Courbot, minyard, gnomes, Linus Walleij,
William Breathitt Gray, dhowells, linux-gpio,
linux-security-module, keyrings
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: William Breathitt Gray <vilhelm.gray@gmail.com>
cc: Linus Walleij <linus.walleij@linaro.org>
cc: Alexandre Courbot <gnurou@gmail.com>
cc: linux-gpio@vger.kernel.org
---
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(-)
diff --git a/drivers/gpio/gpio-104-dio-48e.c b/drivers/gpio/gpio-104-dio-48e.c
index fcf776971ca9..1c334eed5821 100644
--- a/drivers/gpio/gpio-104-dio-48e.c
+++ b/drivers/gpio/gpio-104-dio-48e.c
@@ -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");
/**
diff --git a/drivers/gpio/gpio-104-idi-48.c b/drivers/gpio/gpio-104-idi-48.c
index 2d2763ea1a68..6639920b3299 100644
--- a/drivers/gpio/gpio-104-idi-48.c
+++ b/drivers/gpio/gpio-104-idi-48.c
@@ -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");
/**
diff --git a/drivers/gpio/gpio-104-idio-16.c b/drivers/gpio/gpio-104-idio-16.c
index 6787b8fcf0d8..6d7024ac2689 100644
--- a/drivers/gpio/gpio-104-idio-16.c
+++ b/drivers/gpio/gpio-104-idio-16.c
@@ -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");
/**
diff --git a/drivers/gpio/gpio-gpio-mm.c b/drivers/gpio/gpio-gpio-mm.c
index 1e7def9449ce..4ac2179b96ad 100644
--- a/drivers/gpio/gpio-gpio-mm.c
+++ b/drivers/gpio/gpio-gpio-mm.c
@@ -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");
/**
diff --git a/drivers/gpio/gpio-ws16c48.c b/drivers/gpio/gpio-ws16c48.c
index eaa71d440ccf..c84d600a8bb0 100644
--- a/drivers/gpio/gpio-ws16c48.c
+++ b/drivers/gpio/gpio-ws16c48.c
@@ -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");
/**
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 08/39] Annotate hardware config module parameters in drivers/gpio/
2016-12-01 12:30 ` [PATCH 08/39] Annotate hardware config module parameters in drivers/gpio/ David Howells
@ 2016-12-01 13:49 ` William Breathitt Gray
2016-12-02 12:55 ` Linus Walleij
1 sibling, 0 replies; 78+ messages in thread
From: William Breathitt Gray @ 2016-12-01 13:49 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, Alexandre Courbot, minyard, gnomes, Linus Walleij,
linux-gpio, linux-security-module, keyrings
On Thu, Dec 01, 2016 at 12:30:40PM +0000, David Howells wrote:
>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/.
>
>Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
>Signed-off-by: David Howells <dhowells@redhat.com>
>cc: William Breathitt Gray <vilhelm.gray@gmail.com>
>cc: Linus Walleij <linus.walleij@linaro.org>
>cc: Alexandre Courbot <gnurou@gmail.com>
>cc: linux-gpio@vger.kernel.org
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
>---
>
> 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(-)
>
>diff --git a/drivers/gpio/gpio-104-dio-48e.c b/drivers/gpio/gpio-104-dio-48e.c
>index fcf776971ca9..1c334eed5821 100644
>--- a/drivers/gpio/gpio-104-dio-48e.c
>+++ b/drivers/gpio/gpio-104-dio-48e.c
>@@ -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");
>
> /**
>diff --git a/drivers/gpio/gpio-104-idi-48.c b/drivers/gpio/gpio-104-idi-48.c
>index 2d2763ea1a68..6639920b3299 100644
>--- a/drivers/gpio/gpio-104-idi-48.c
>+++ b/drivers/gpio/gpio-104-idi-48.c
>@@ -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");
>
> /**
>diff --git a/drivers/gpio/gpio-104-idio-16.c b/drivers/gpio/gpio-104-idio-16.c
>index 6787b8fcf0d8..6d7024ac2689 100644
>--- a/drivers/gpio/gpio-104-idio-16.c
>+++ b/drivers/gpio/gpio-104-idio-16.c
>@@ -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");
>
> /**
>diff --git a/drivers/gpio/gpio-gpio-mm.c b/drivers/gpio/gpio-gpio-mm.c
>index 1e7def9449ce..4ac2179b96ad 100644
>--- a/drivers/gpio/gpio-gpio-mm.c
>+++ b/drivers/gpio/gpio-gpio-mm.c
>@@ -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");
>
> /**
>diff --git a/drivers/gpio/gpio-ws16c48.c b/drivers/gpio/gpio-ws16c48.c
>index eaa71d440ccf..c84d600a8bb0 100644
>--- a/drivers/gpio/gpio-ws16c48.c
>+++ b/drivers/gpio/gpio-ws16c48.c
>@@ -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");
>
> /**
>
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 08/39] Annotate hardware config module parameters in drivers/gpio/
2016-12-01 12:30 ` [PATCH 08/39] Annotate hardware config module parameters in drivers/gpio/ David Howells
2016-12-01 13:49 ` William Breathitt Gray
@ 2016-12-02 12:55 ` Linus Walleij
1 sibling, 0 replies; 78+ messages in thread
From: Linus Walleij @ 2016-12-02 12:55 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, Alexandre Courbot, minyard, One Thousand Gnomes,
William Breathitt Gray, linux-gpio, linux-security-module,
keyrings
On Thu, Dec 1, 2016 at 1:30 PM, David Howells <dhowells@redhat.com> wrote:
> 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/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: William Breathitt Gray <vilhelm.gray@gmail.com>
> cc: Linus Walleij <linus.walleij@linaro.org>
> cc: Alexandre Courbot <gnurou@gmail.com>
> cc: linux-gpio@vger.kernel.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (7 preceding siblings ...)
2016-12-01 12:30 ` [PATCH 08/39] Annotate hardware config module parameters in drivers/gpio/ David Howells
@ 2016-12-01 12:30 ` David Howells
2016-12-01 13:47 ` Jean Delvare
2016-12-01 14:12 ` David Howells
2016-12-01 12:30 ` [PATCH 10/39] Annotate hardware config module parameters in drivers/iio/ David Howells
` (29 subsequent siblings)
38 siblings, 2 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, Jean Delvare, minyard, Wolfram Sang, dhowells,
linux-security-module, keyrings, linux-i2c
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Wolfram Sang <wsa@the-dreams.de>
cc: Jean Delvare <jdelvare@suse.com>
cc: linux-i2c@vger.kernel.org
---
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(-)
diff --git a/drivers/i2c/busses/i2c-elektor.c b/drivers/i2c/busses/i2c-elektor.c
index 8af62fb3fe41..5416003e0605 100644
--- a/drivers/i2c/busses/i2c-elektor.c
+++ b/drivers/i2c/busses/i2c-elektor.c
@@ -323,9 +323,9 @@ MODULE_AUTHOR("Hans Berglund <hb@spacetec.no>");
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);
diff --git a/drivers/i2c/busses/i2c-parport-light.c b/drivers/i2c/busses/i2c-parport-light.c
index 1bcdd10b68b9..faa8fb8f2b8f 100644
--- a/drivers/i2c/busses/i2c-parport-light.c
+++ b/drivers/i2c/busses/i2c-parport-light.c
@@ -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 ----------------------------------- */
diff --git a/drivers/i2c/busses/i2c-pca-isa.c b/drivers/i2c/busses/i2c-pca-isa.c
index ba88f17f636c..946ac646de2a 100644
--- a/drivers/i2c/busses/i2c-pca-isa.c
+++ b/drivers/i2c/busses/i2c-pca-isa.c
@@ -197,9 +197,9 @@ MODULE_AUTHOR("Ian Campbell <icampbell@arcom.com>");
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"
diff --git a/drivers/i2c/busses/scx200_acb.c b/drivers/i2c/busses/scx200_acb.c
index 0a7e410b6195..e0923bee8d1f 100644
--- a/drivers/i2c/busses/scx200_acb.c
+++ b/drivers/i2c/busses/scx200_acb.c
@@ -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)
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/
2016-12-01 12:30 ` [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/ David Howells
@ 2016-12-01 13:47 ` Jean Delvare
2016-12-01 14:12 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: Jean Delvare @ 2016-12-01 13:47 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, gnomes, minyard, Wolfram Sang,
linux-security-module, keyrings, linux-i2c
Hi David,
On jeu., 2016-12-01 at 12:30 +0000, David Howells wrote:
> 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.
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.
> This patch annotates drivers in drivers/i2c/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
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.)"
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Wolfram Sang <wsa@the-dreams.de>
> cc: Jean Delvare <jdelvare@suse.com>
> cc: linux-i2c@vger.kernel.org
> ---
>
> 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(-)
>
> diff --git a/drivers/i2c/busses/i2c-elektor.c b/drivers/i2c/busses/i2c-elektor.c
> index 8af62fb3fe41..5416003e0605 100644
> --- a/drivers/i2c/busses/i2c-elektor.c
> +++ b/drivers/i2c/busses/i2c-elektor.c
> @@ -323,9 +323,9 @@ MODULE_AUTHOR("Hans Berglund <hb@spacetec.no>");
> 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);
> diff --git a/drivers/i2c/busses/i2c-parport-light.c b/drivers/i2c/busses/i2c-parport-light.c
> index 1bcdd10b68b9..faa8fb8f2b8f 100644
> --- a/drivers/i2c/busses/i2c-parport-light.c
> +++ b/drivers/i2c/busses/i2c-parport-light.c
> @@ -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 ----------------------------------- */
> diff --git a/drivers/i2c/busses/i2c-pca-isa.c b/drivers/i2c/busses/i2c-pca-isa.c
> index ba88f17f636c..946ac646de2a 100644
> --- a/drivers/i2c/busses/i2c-pca-isa.c
> +++ b/drivers/i2c/busses/i2c-pca-isa.c
> @@ -197,9 +197,9 @@ MODULE_AUTHOR("Ian Campbell <icampbell@arcom.com>");
> 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"
> diff --git a/drivers/i2c/busses/scx200_acb.c b/drivers/i2c/busses/scx200_acb.c
> index 0a7e410b6195..e0923bee8d1f 100644
> --- a/drivers/i2c/busses/scx200_acb.c
> +++ b/drivers/i2c/busses/scx200_acb.c
> @@ -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)
>
>
No objection from me, but I think you missed several i2c bus driver
parameters:
i2c-ali15x3.c:module_param(force_addr, ushort, 0);
i2c-piix4.c:module_param (force_addr, int, 0);
i2c-sis5595.c:module_param(force_addr, ushort, 0);
i2c-viapro.c:module_param(force_addr, ushort, 0);
And maybe the following ones, but I'm not sure if forcibly enabling a
device is part of what you need to prevent:
i2c-piix4.c:module_param (force, int, 0);
i2c-sis630.c:module_param(force, bool, 0);
i2c-viapro.c:module_param(force, bool, 0);
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/
2016-12-01 12:30 ` [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/ David Howells
2016-12-01 13:47 ` Jean Delvare
@ 2016-12-01 14:12 ` David Howells
2016-12-01 16:06 ` Jean Delvare
2016-12-05 21:09 ` One Thousand Gnomes
1 sibling, 2 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 14:12 UTC (permalink / raw)
To: Jean Delvare, minyard
Cc: dhowells, linux-kernel, gnomes, Wolfram Sang,
linux-security-module, keyrings, linux-i2c
Jean Delvare <jdelvare@suse.de> wrote:
> > 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.
>
> 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.
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.
> > Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
>
> 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.)"
I asked him what he prefers - but no response.
> No objection from me, but I think you missed several i2c bus driver
> parameters:
>
> i2c-ali15x3.c:module_param(force_addr, ushort, 0);
> i2c-piix4.c:module_param (force_addr, int, 0);
> i2c-sis5595.c:module_param(force_addr, ushort, 0);
> i2c-viapro.c:module_param(force_addr, ushort, 0);
Okay, thanks. They all seem to encode ioports. All changed.
> And maybe the following ones, but I'm not sure if forcibly enabling a
> device is part of what you need to prevent:
>
> i2c-piix4.c:module_param (force, int, 0);
> i2c-sis630.c:module_param(force, bool, 0);
> i2c-viapro.c:module_param(force, bool, 0);
I don't know either. One could argue it *should* be locked down because its
need appears to reflect a BIOS bug.
David
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/
2016-12-01 14:12 ` David Howells
@ 2016-12-01 16:06 ` Jean Delvare
2016-12-05 21:09 ` One Thousand Gnomes
1 sibling, 0 replies; 78+ messages in thread
From: Jean Delvare @ 2016-12-01 16:06 UTC (permalink / raw)
To: David Howells
Cc: minyard, linux-kernel, gnomes, Wolfram Sang,
linux-security-module, keyrings, linux-i2c
On jeu., 2016-12-01 at 14:12 +0000, David Howells wrote:
> Jean Delvare <jdelvare@suse.de> wrote:
>
> > > 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.
> >
> > 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.
>
> 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.
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.
>> (...)
> > And maybe the following ones, but I'm not sure if forcibly enabling a
> > device is part of what you need to prevent:
> >
> > i2c-piix4.c:module_param (force, int, 0);
> > i2c-sis630.c:module_param(force, bool, 0);
> > i2c-viapro.c:module_param(force, bool, 0);
>
> I don't know either. One could argue it *should* be locked down because its
> need appears to reflect a BIOS bug.
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/
2016-12-01 14:12 ` David Howells
2016-12-01 16:06 ` Jean Delvare
@ 2016-12-05 21:09 ` One Thousand Gnomes
1 sibling, 0 replies; 78+ messages in thread
From: One Thousand Gnomes @ 2016-12-05 21:09 UTC (permalink / raw)
To: David Howells
Cc: Jean Delvare, minyard, linux-kernel, Wolfram Sang,
linux-security-module, keyrings, linux-i2c
O> > > Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> >
> > 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.)"
>
> I asked him what he prefers - but no response.
I didn't see that question but "Alan Cox" is probably saner - the
thousand gnomes is an old Linus joke 8)
> > i2c-piix4.c:module_param (force, int, 0);
> > i2c-sis630.c:module_param(force, bool, 0);
> > i2c-viapro.c:module_param(force, bool, 0);
>
> I don't know either. One could argue it *should* be locked down because its
> need appears to reflect a BIOS bug.
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 10/39] Annotate hardware config module parameters in drivers/iio/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (8 preceding siblings ...)
2016-12-01 12:30 ` [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/ David Howells
@ 2016-12-01 12:30 ` David Howells
2016-12-01 13:50 ` William Breathitt Gray
2016-12-01 12:31 ` [PATCH 11/39] Annotate hardware config module parameters in drivers/input/ David Howells
` (28 subsequent siblings)
38 siblings, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-01 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, linux-iio, William Breathitt Gray, dhowells,
linux-security-module, keyrings, Jonathan Cameron
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: William Breathitt Gray <vilhelm.gray@gmail.com>
cc: Jonathan Cameron <jic23@kernel.org>
cc: linux-iio@vger.kernel.org
---
drivers/iio/adc/stx104.c | 2 +-
drivers/iio/dac/cio-dac.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/stx104.c b/drivers/iio/adc/stx104.c
index 7e3645749eaf..a805bd543acb 100644
--- a/drivers/iio/adc/stx104.c
+++ b/drivers/iio/adc/stx104.c
@@ -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");
/**
diff --git a/drivers/iio/dac/cio-dac.c b/drivers/iio/dac/cio-dac.c
index 5a743e2a779d..dac086129edf 100644
--- a/drivers/iio/dac/cio-dac.c
+++ b/drivers/iio/dac/cio-dac.c
@@ -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");
/**
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 10/39] Annotate hardware config module parameters in drivers/iio/
2016-12-01 12:30 ` [PATCH 10/39] Annotate hardware config module parameters in drivers/iio/ David Howells
@ 2016-12-01 13:50 ` William Breathitt Gray
2016-12-03 9:05 ` Jonathan Cameron
2016-12-07 13:43 ` David Howells
0 siblings, 2 replies; 78+ messages in thread
From: William Breathitt Gray @ 2016-12-01 13:50 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, gnomes, minyard, linux-iio, linux-security-module,
keyrings, Jonathan Cameron
On Thu, Dec 01, 2016 at 12:30:55PM +0000, David Howells wrote:
>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/.
>
>Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
>Signed-off-by: David Howells <dhowells@redhat.com>
>cc: William Breathitt Gray <vilhelm.gray@gmail.com>
>cc: Jonathan Cameron <jic23@kernel.org>
>cc: linux-iio@vger.kernel.org
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
>---
>
> drivers/iio/adc/stx104.c | 2 +-
> drivers/iio/dac/cio-dac.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/iio/adc/stx104.c b/drivers/iio/adc/stx104.c
>index 7e3645749eaf..a805bd543acb 100644
>--- a/drivers/iio/adc/stx104.c
>+++ b/drivers/iio/adc/stx104.c
>@@ -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");
>
> /**
>diff --git a/drivers/iio/dac/cio-dac.c b/drivers/iio/dac/cio-dac.c
>index 5a743e2a779d..dac086129edf 100644
>--- a/drivers/iio/dac/cio-dac.c
>+++ b/drivers/iio/dac/cio-dac.c
>@@ -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");
>
> /**
>
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 10/39] Annotate hardware config module parameters in drivers/iio/
2016-12-01 13:50 ` William Breathitt Gray
@ 2016-12-03 9:05 ` Jonathan Cameron
2016-12-07 13:43 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: Jonathan Cameron @ 2016-12-03 9:05 UTC (permalink / raw)
To: William Breathitt Gray, David Howells
Cc: linux-kernel, gnomes, minyard, linux-iio, linux-security-module,
keyrings
On 01/12/16 13:50, William Breathitt Gray wrote:
> On Thu, Dec 01, 2016 at 12:30:55PM +0000, David Howells wrote:
>> 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/.
>>
>> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
>> Signed-off-by: David Howells <dhowells@redhat.com>
>> cc: William Breathitt Gray <vilhelm.gray@gmail.com>
>> cc: Jonathan Cameron <jic23@kernel.org>
>> cc: linux-iio@vger.kernel.org
>
> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
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.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Shout if you want me to take this via the IIO tree after the merge window
closes.
Thanks,
Jonathan
>
>> ---
>>
>> drivers/iio/adc/stx104.c | 2 +-
>> drivers/iio/dac/cio-dac.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/iio/adc/stx104.c b/drivers/iio/adc/stx104.c
>> index 7e3645749eaf..a805bd543acb 100644
>> --- a/drivers/iio/adc/stx104.c
>> +++ b/drivers/iio/adc/stx104.c
>> @@ -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");
>>
>> /**
>> diff --git a/drivers/iio/dac/cio-dac.c b/drivers/iio/dac/cio-dac.c
>> index 5a743e2a779d..dac086129edf 100644
>> --- a/drivers/iio/dac/cio-dac.c
>> +++ b/drivers/iio/dac/cio-dac.c
>> @@ -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");
>>
>> /**
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 10/39] Annotate hardware config module parameters in drivers/iio/
2016-12-01 13:50 ` William Breathitt Gray
2016-12-03 9:05 ` Jonathan Cameron
@ 2016-12-07 13:43 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-07 13:43 UTC (permalink / raw)
To: Jonathan Cameron
Cc: dhowells, William Breathitt Gray, linux-kernel, gnomes, minyard,
linux-iio, linux-security-module, keyrings
Jonathan Cameron <jic23@kernel.org> wrote:
> 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?
Yeah, patch 1 is a prerequisite for all the subsequent patches.
> Hence for now I'll assume you want to merge this lot in one go.
I'll see if I can get patch 1 in and then distribute the other patches.
David
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 11/39] Annotate hardware config module parameters in drivers/input/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (9 preceding siblings ...)
2016-12-01 12:30 ` [PATCH 10/39] Annotate hardware config module parameters in drivers/iio/ David Howells
@ 2016-12-01 12:31 ` David Howells
2016-12-03 18:51 ` Dmitry Torokhov
2016-12-01 12:31 ` [PATCH 12/39] Annotate hardware config module parameters in drivers/isdn/ David Howells
` (27 subsequent siblings)
38 siblings, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-01 12:31 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, Dmitry Torokhov, dhowells,
linux-security-module, keyrings, linux-input
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
cc: linux-input@vger.kernel.org
---
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(-)
diff --git a/drivers/input/mouse/inport.c b/drivers/input/mouse/inport.c
index 3827a22362de..9ce71dfa0de1 100644
--- a/drivers/input/mouse/inport.c
+++ b/drivers/input/mouse/inport.c
@@ -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;
diff --git a/drivers/input/mouse/logibm.c b/drivers/input/mouse/logibm.c
index e2413113df22..6f165e053f4d 100644
--- a/drivers/input/mouse/logibm.c
+++ b/drivers/input/mouse/logibm.c
@@ -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;
diff --git a/drivers/input/touchscreen/mk712.c b/drivers/input/touchscreen/mk712.c
index 36e57deacd03..bd5352824f77 100644
--- a/drivers/input/touchscreen/mk712.c
+++ b/drivers/input/touchscreen/mk712.c
@@ -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 */
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 11/39] Annotate hardware config module parameters in drivers/input/
2016-12-01 12:31 ` [PATCH 11/39] Annotate hardware config module parameters in drivers/input/ David Howells
@ 2016-12-03 18:51 ` Dmitry Torokhov
0 siblings, 0 replies; 78+ messages in thread
From: Dmitry Torokhov @ 2016-12-03 18:51 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, gnomes, minyard, linux-security-module, keyrings,
linux-input
On Thu, Dec 01, 2016 at 12:31:03PM +0000, David Howells wrote:
> 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/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> cc: linux-input@vger.kernel.org
Please merge with the rest of patches.
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>
> 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(-)
>
> diff --git a/drivers/input/mouse/inport.c b/drivers/input/mouse/inport.c
> index 3827a22362de..9ce71dfa0de1 100644
> --- a/drivers/input/mouse/inport.c
> +++ b/drivers/input/mouse/inport.c
> @@ -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;
> diff --git a/drivers/input/mouse/logibm.c b/drivers/input/mouse/logibm.c
> index e2413113df22..6f165e053f4d 100644
> --- a/drivers/input/mouse/logibm.c
> +++ b/drivers/input/mouse/logibm.c
> @@ -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;
> diff --git a/drivers/input/touchscreen/mk712.c b/drivers/input/touchscreen/mk712.c
> index 36e57deacd03..bd5352824f77 100644
> --- a/drivers/input/touchscreen/mk712.c
> +++ b/drivers/input/touchscreen/mk712.c
> @@ -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 */
>
--
Dmitry
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 12/39] Annotate hardware config module parameters in drivers/isdn/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (10 preceding siblings ...)
2016-12-01 12:31 ` [PATCH 11/39] Annotate hardware config module parameters in drivers/input/ David Howells
@ 2016-12-01 12:31 ` David Howells
2016-12-01 12:31 ` [PATCH 13/39] Annotate hardware config module parameters in drivers/media/ David Howells
` (26 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:31 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, Karsten Keil, minyard, netdev, dhowells,
linux-security-module, keyrings
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Karsten Keil <isdn@linux-pingi.de>
cc: netdev@vger.kernel.org
---
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(-)
diff --git a/drivers/isdn/hardware/avm/b1isa.c b/drivers/isdn/hardware/avm/b1isa.c
index 31ef8130a87f..54e871a47387 100644
--- a/drivers/isdn/hardware/avm/b1isa.c
+++ b/drivers/isdn/hardware/avm/b1isa.c
@@ -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)");
diff --git a/drivers/isdn/hardware/avm/t1isa.c b/drivers/isdn/hardware/avm/t1isa.c
index 72ef18853951..9516203c735f 100644
--- a/drivers/isdn/hardware/avm/t1isa.c
+++ b/drivers/isdn/hardware/avm/t1isa.c
@@ -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)");
diff --git a/drivers/isdn/hisax/config.c b/drivers/isdn/hisax/config.c
index bf04d2a3cf4a..30da1bc106f0 100644
--- a/drivers/isdn/hisax/config.c
+++ b/drivers/isdn/hisax/config.c
@@ -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 */
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 13/39] Annotate hardware config module parameters in drivers/media/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (11 preceding siblings ...)
2016-12-01 12:31 ` [PATCH 12/39] Annotate hardware config module parameters in drivers/isdn/ David Howells
@ 2016-12-01 12:31 ` David Howells
2016-12-01 12:31 ` [PATCH 14/39] Annotate hardware config module parameters in drivers/misc/ David Howells
` (25 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:31 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, dhowells, linux-security-module, mjpeg-users,
keyrings, Mauro Carvalho Chehab, linux-media
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Mauro Carvalho Chehab <mchehab@kernel.org>
cc: mjpeg-users@lists.sourceforge.net
cc: linux-media@vger.kernel.org
---
drivers/media/pci/zoran/zoran_card.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/zoran/zoran_card.c b/drivers/media/pci/zoran/zoran_card.c
index 9d2697f5b455..3a03a0df7999 100644
--- a/drivers/media/pci/zoran/zoran_card.c
+++ b/drivers/media/pci/zoran/zoran_card.c
@@ -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");
/*
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 14/39] Annotate hardware config module parameters in drivers/misc/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (12 preceding siblings ...)
2016-12-01 12:31 ` [PATCH 13/39] Annotate hardware config module parameters in drivers/media/ David Howells
@ 2016-12-01 12:31 ` David Howells
2016-12-01 12:31 ` [PATCH 15/39] Annotate hardware config module parameters in drivers/mmc/host/ David Howells
` (24 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:31 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, Arnd Bergmann, minyard, Greg Kroah-Hartman, dhowells,
linux-security-module, keyrings
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Arnd Bergmann <arnd@arndb.de>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/dummy-irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
index acbbe0390be4..76a1015d5783 100644
--- a/drivers/misc/dummy-irq.c
+++ b/drivers/misc/dummy-irq.c
@@ -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");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 15/39] Annotate hardware config module parameters in drivers/mmc/host/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (13 preceding siblings ...)
2016-12-01 12:31 ` [PATCH 14/39] Annotate hardware config module parameters in drivers/misc/ David Howells
@ 2016-12-01 12:31 ` David Howells
2016-12-01 12:31 ` [PATCH 16/39] Annotate hardware config module parameters in drivers/net/appletalk/ David Howells
` (23 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:31 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, Ulf Hansson, minyard, linux-mmc, dhowells,
linux-security-module, keyrings, Pierre Ossman
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Pierre Ossman <pierre@ossman.eu>
cc: Ulf Hansson <ulf.hansson@linaro.org>
cc: linux-mmc@vger.kernel.org
---
drivers/mmc/host/wbsd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/wbsd.c b/drivers/mmc/host/wbsd.c
index c3fd16d997ca..76c7f643fab5 100644
--- a/drivers/mmc/host/wbsd.c
+++ b/drivers/mmc/host/wbsd.c
@@ -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 <pierre@ossman.eu>");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 16/39] Annotate hardware config module parameters in drivers/net/appletalk/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (14 preceding siblings ...)
2016-12-01 12:31 ` [PATCH 15/39] Annotate hardware config module parameters in drivers/mmc/host/ David Howells
@ 2016-12-01 12:31 ` David Howells
2016-12-01 12:31 ` [PATCH 17/39] Annotate hardware config module parameters in drivers/net/arcnet/ David Howells
` (22 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:31 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, netdev, dhowells, linux-security-module,
keyrings, Arnaldo Carvalho de Melo
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
cc: netdev@vger.kernel.org
---
drivers/net/appletalk/cops.c | 6 +++---
drivers/net/appletalk/ltpc.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/appletalk/cops.c b/drivers/net/appletalk/cops.c
index 1b2e9217ec78..486e1e6997fc 100644
--- a/drivers/net/appletalk/cops.c
+++ b/drivers/net/appletalk/cops.c
@@ -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)
{
diff --git a/drivers/net/appletalk/ltpc.c b/drivers/net/appletalk/ltpc.c
index 01e2ac55c137..ac755d2950a6 100644
--- a/drivers/net/appletalk/ltpc.c
+++ b/drivers/net/appletalk/ltpc.c
@@ -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)
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 17/39] Annotate hardware config module parameters in drivers/net/arcnet/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (15 preceding siblings ...)
2016-12-01 12:31 ` [PATCH 16/39] Annotate hardware config module parameters in drivers/net/appletalk/ David Howells
@ 2016-12-01 12:31 ` David Howells
2016-12-01 12:32 ` [PATCH 18/39] Annotate hardware config module parameters in drivers/net/can/ David Howells
` (21 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:31 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, Michael Grzeschik, minyard, netdev, dhowells,
linux-security-module, keyrings
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
cc: netdev@vger.kernel.org
---
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(-)
diff --git a/drivers/net/arcnet/com20020-isa.c b/drivers/net/arcnet/com20020-isa.c
index b9e9931353b2..38fa60ddaf2e 100644
--- a/drivers/net/arcnet/com20020-isa.c
+++ b/drivers/net/arcnet/com20020-isa.c
@@ -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);
diff --git a/drivers/net/arcnet/com90io.c b/drivers/net/arcnet/com90io.c
index b57863df5bf5..4e56aaf2b984 100644
--- a/drivers/net/arcnet/com90io.c
+++ b/drivers/net/arcnet/com90io.c
@@ -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");
diff --git a/drivers/net/arcnet/com90xx.c b/drivers/net/arcnet/com90xx.c
index 81f90c4703ae..ca4a57c30bf8 100644
--- a/drivers/net/arcnet/com90xx.c
+++ b/drivers/net/arcnet/com90xx.c
@@ -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);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 18/39] Annotate hardware config module parameters in drivers/net/can/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (16 preceding siblings ...)
2016-12-01 12:31 ` [PATCH 17/39] Annotate hardware config module parameters in drivers/net/arcnet/ David Howells
@ 2016-12-01 12:32 ` David Howells
2016-12-01 13:05 ` Marc Kleine-Budde
2016-12-01 12:32 ` [PATCH 19/39] Annotate hardware config module parameters in drivers/net/ethernet/ David Howells
` (20 subsequent siblings)
38 siblings, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-01 12:32 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, netdev, linux-can, dhowells,
linux-security-module, keyrings, Marc Kleine-Budde,
Wolfgang Grandegger
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Wolfgang Grandegger <wg@grandegger.com>
cc: Marc Kleine-Budde <mkl@pengutronix.de>
cc: linux-can@vger.kernel.org
cc: netdev@vger.kernel.org
---
drivers/net/can/cc770/cc770_isa.c | 8 ++++----
drivers/net/can/sja1000/sja1000_isa.c | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/can/cc770/cc770_isa.c b/drivers/net/can/cc770/cc770_isa.c
index e0d15711e9ac..3a30fd3b4498 100644
--- a/drivers/net/can/cc770/cc770_isa.c
+++ b/drivers/net/can/cc770/cc770_isa.c
@@ -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);
diff --git a/drivers/net/can/sja1000/sja1000_isa.c b/drivers/net/can/sja1000/sja1000_isa.c
index e97e6d35b300..a89c1e92554d 100644
--- a/drivers/net/can/sja1000/sja1000_isa.c
+++ b/drivers/net/can/sja1000/sja1000_isa.c
@@ -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);
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 18/39] Annotate hardware config module parameters in drivers/net/can/
2016-12-01 12:32 ` [PATCH 18/39] Annotate hardware config module parameters in drivers/net/can/ David Howells
@ 2016-12-01 13:05 ` Marc Kleine-Budde
0 siblings, 0 replies; 78+ messages in thread
From: Marc Kleine-Budde @ 2016-12-01 13:05 UTC (permalink / raw)
To: David Howells, linux-kernel
Cc: gnomes, minyard, netdev, linux-can, linux-security-module,
keyrings, Wolfgang Grandegger
[-- Attachment #1.1: Type: text/plain, Size: 1779 bytes --]
On 12/01/2016 01:32 PM, David Howells wrote:
> 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/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Wolfgang Grandegger <wg@grandegger.com>
> cc: Marc Kleine-Budde <mkl@pengutronix.de>
> cc: linux-can@vger.kernel.org
> cc: netdev@vger.kernel.org
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
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 |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 19/39] Annotate hardware config module parameters in drivers/net/ethernet/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (17 preceding siblings ...)
2016-12-01 12:32 ` [PATCH 18/39] Annotate hardware config module parameters in drivers/net/can/ David Howells
@ 2016-12-01 12:32 ` David Howells
2016-12-01 12:32 ` [PATCH 20/39] Annotate hardware config module parameters in drivers/net/hamradio/ David Howells
` (19 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:32 UTC (permalink / raw)
To: linux-kernel
Cc: minyard, gnomes, Steffen Klassert, linux-parisc, netdev,
Jaroslav Kysela, dhowells, linux-security-module, keyrings
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
cc: Jaroslav Kysela <perex@perex.cz>
cc: netdev@vger.kernel.org
cc: linux-parisc@vger.kernel.org
---
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(-)
diff --git a/drivers/net/ethernet/3com/3c509.c b/drivers/net/ethernet/3com/3c509.c
index 91ada52f776b..33a6d67ee182 100644
--- a/drivers/net/ethernet/3com/3c509.c
+++ b/drivers/net/ethernet/3com/3c509.c
@@ -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)");
diff --git a/drivers/net/ethernet/3com/3c59x.c b/drivers/net/ethernet/3com/3c59x.c
index 9133e7926da5..d041e3c7c3e6 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -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);
diff --git a/drivers/net/ethernet/8390/ne.c b/drivers/net/ethernet/8390/ne.c
index c063b410a163..66f47987e2a2 100644
--- a/drivers/net/ethernet/8390/ne.c
+++ b/drivers/net/ethernet/8390/ne.c
@@ -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");
diff --git a/drivers/net/ethernet/8390/smc-ultra.c b/drivers/net/ethernet/8390/smc-ultra.c
index 139385dcdaa7..c5dbf6938a4e 100644
--- a/drivers/net/ethernet/8390/smc-ultra.c
+++ b/drivers/net/ethernet/8390/smc-ultra.c
@@ -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)");
diff --git a/drivers/net/ethernet/8390/wd.c b/drivers/net/ethernet/8390/wd.c
index dd7d816bde52..e16deef661e3 100644
--- a/drivers/net/ethernet/8390/wd.c
+++ b/drivers/net/ethernet/8390/wd.c
@@ -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)");
diff --git a/drivers/net/ethernet/amd/lance.c b/drivers/net/ethernet/amd/lance.c
index abb1ba228b26..1b5603c30bd2 100644
--- a/drivers/net/ethernet/amd/lance.c
+++ b/drivers/net/ethernet/amd/lance.c
@@ -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)");
diff --git a/drivers/net/ethernet/amd/ni65.c b/drivers/net/ethernet/amd/ni65.c
index cda53db75f17..8b2e4deefdd4 100644
--- a/drivers/net/ethernet/amd/ni65.c
+++ b/drivers/net/ethernet/amd/ni65.c
@@ -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)");
diff --git a/drivers/net/ethernet/cirrus/cs89x0.c b/drivers/net/ethernet/cirrus/cs89x0.c
index c363b58552e9..424f62b28c63 100644
--- a/drivers/net/ethernet/cirrus/cs89x0.c
+++ b/drivers/net/ethernet/cirrus/cs89x0.c
@@ -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");
diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c
index 6620fc861c47..9ba1a318916d 100644
--- a/drivers/net/ethernet/dec/tulip/de4x5.c
+++ b/drivers/net/ethernet/dec/tulip/de4x5.c
@@ -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);
diff --git a/drivers/net/ethernet/hp/hp100.c b/drivers/net/ethernet/hp/hp100.c
index 631dbc7b4dbb..eab44abb24ba 100644
--- a/drivers/net/ethernet/hp/hp100.c
+++ b/drivers/net/ethernet/hp/hp100.c
@@ -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];
diff --git a/drivers/net/ethernet/realtek/atp.c b/drivers/net/ethernet/realtek/atp.c
index 5cb96785fb63..619938322915 100644
--- a/drivers/net/ethernet/realtek/atp.c
+++ b/drivers/net/ethernet/realtek/atp.c
@@ -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)");
diff --git a/drivers/net/ethernet/smsc/smc9194.c b/drivers/net/ethernet/smsc/smc9194.c
index d496888b85d3..1bfae24066ce 100644
--- a/drivers/net/ethernet/smsc/smc9194.c
+++ b/drivers/net/ethernet/smsc/smc9194.c
@@ -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");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 20/39] Annotate hardware config module parameters in drivers/net/hamradio/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (18 preceding siblings ...)
2016-12-01 12:32 ` [PATCH 19/39] Annotate hardware config module parameters in drivers/net/ethernet/ David Howells
@ 2016-12-01 12:32 ` David Howells
2016-12-01 12:32 ` [PATCH 21/39] Annotate hardware config module parameters in drivers/net/irda/ David Howells
` (18 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:32 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, netdev, dhowells, linux-security-module,
keyrings, linux-hams, Joerg Reuter, Thomas Sailer
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Thomas Sailer <t.sailer@alumni.ethz.ch>
cc: Joerg Reuter <jreuter@yaina.de>
cc: linux-hams@vger.kernel.org
cc: netdev@vger.kernel.org
---
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(-)
diff --git a/drivers/net/hamradio/baycom_epp.c b/drivers/net/hamradio/baycom_epp.c
index 78dbc44540f6..a50b72144b93 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -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, sailer@ife.ee.ethz.ch, hb9jnx@hb9w.che.eu");
diff --git a/drivers/net/hamradio/baycom_par.c b/drivers/net/hamradio/baycom_par.c
index 072cddce9264..cb7fe200f347 100644
--- a/drivers/net/hamradio/baycom_par.c
+++ b/drivers/net/hamradio/baycom_par.c
@@ -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, sailer@ife.ee.ethz.ch, hb9jnx@hb9w.che.eu");
diff --git a/drivers/net/hamradio/baycom_ser_fdx.c b/drivers/net/hamradio/baycom_ser_fdx.c
index 7b916d5b14b9..36d49c89d601 100644
--- a/drivers/net/hamradio/baycom_ser_fdx.c
+++ b/drivers/net/hamradio/baycom_ser_fdx.c
@@ -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)");
diff --git a/drivers/net/hamradio/baycom_ser_hdx.c b/drivers/net/hamradio/baycom_ser_hdx.c
index f9a8976195ba..1b310493ba8a 100644
--- a/drivers/net/hamradio/baycom_ser_hdx.c
+++ b/drivers/net/hamradio/baycom_ser_hdx.c
@@ -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, sailer@ife.ee.ethz.ch, hb9jnx@hb9w.che.eu");
diff --git a/drivers/net/hamradio/dmascc.c b/drivers/net/hamradio/dmascc.c
index e4137c1b3df9..f94ca7b91899 100644
--- a/drivers/net/hamradio/dmascc.c
+++ b/drivers/net/hamradio/dmascc.c
@@ -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)
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 21/39] Annotate hardware config module parameters in drivers/net/irda/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (19 preceding siblings ...)
2016-12-01 12:32 ` [PATCH 20/39] Annotate hardware config module parameters in drivers/net/hamradio/ David Howells
@ 2016-12-01 12:32 ` David Howells
2016-12-01 12:32 ` [PATCH 22/39] Annotate hardware config module parameters in drivers/net/wan/ David Howells
` (17 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:32 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, Samuel Ortiz, minyard, netdev, dhowells,
linux-security-module, keyrings
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Samuel Ortiz <samuel@sortiz.org>
cc: netdev@vger.kernel.org
---
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(-)
diff --git a/drivers/net/irda/ali-ircc.c b/drivers/net/irda/ali-ircc.c
index c285eafd3f1c..35f198d83701 100644
--- a/drivers/net/irda/ali-ircc.c
+++ b/drivers/net/irda/ali-ircc.c
@@ -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);
diff --git a/drivers/net/irda/nsc-ircc.c b/drivers/net/irda/nsc-ircc.c
index aaecc3baaf30..7beae147be11 100644
--- a/drivers/net/irda/nsc-ircc.c
+++ b/drivers/net/irda/nsc-ircc.c
@@ -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");
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index dcf92ba80872..23ed89ae5ddc 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -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;
diff --git a/drivers/net/irda/w83977af_ir.c b/drivers/net/irda/w83977af_ir.c
index 4e3d2e7c697c..f15d8752864b 100644
--- a/drivers/net/irda/w83977af_ir.c
+++ b/drivers/net/irda/w83977af_ir.c
@@ -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");
/*
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 22/39] Annotate hardware config module parameters in drivers/net/wan/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (20 preceding siblings ...)
2016-12-01 12:32 ` [PATCH 21/39] Annotate hardware config module parameters in drivers/net/irda/ David Howells
@ 2016-12-01 12:32 ` David Howells
2016-12-01 12:32 ` [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/ David Howells
` (16 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:32 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, netdev, dhowells, linux-security-module,
keyrings, Jan "Yenya" Kasprzak
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: "Jan \"Yenya\" Kasprzak" <kas@fi.muni.cz>
cc: netdev@vger.kernel.org
---
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(-)
diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index b87fe0a01c69..2f7104e92dd8 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -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, <kas@fi.muni.cz>");
diff --git a/drivers/net/wan/hostess_sv11.c b/drivers/net/wan/hostess_sv11.c
index 3d741663fd67..4845560fd848 100644
--- a/drivers/net/wan/hostess_sv11.c
+++ b/drivers/net/wan/hostess_sv11.c
@@ -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");
diff --git a/drivers/net/wan/sbni.c b/drivers/net/wan/sbni.c
index 3a421ca8a4d0..42220fa78093 100644
--- a/drivers/net/wan/sbni.c
+++ b/drivers/net/wan/sbni.c
@@ -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);
diff --git a/drivers/net/wan/sealevel.c b/drivers/net/wan/sealevel.c
index 27860b4f5908..1d762a2d3ddc 100644
--- a/drivers/net/wan/sealevel.c
+++ b/drivers/net/wan/sealevel.c
@@ -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");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (21 preceding siblings ...)
2016-12-01 12:32 ` [PATCH 22/39] Annotate hardware config module parameters in drivers/net/wan/ David Howells
@ 2016-12-01 12:32 ` David Howells
2016-12-02 5:04 ` Kalle Valo
2016-12-07 13:45 ` David Howells
2016-12-01 12:32 ` [PATCH 24/39] Annotate hardware config module parameters in drivers/parport/ David Howells
` (15 subsequent siblings)
38 siblings, 2 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:32 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, netdev, linux-wireless, dhowells,
linux-security-module, keyrings, Kalle Valo
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Kalle Valo <kvalo@codeaurora.org>
cc: linux-wireless@vger.kernel.org
cc: netdev@vger.kernel.org
---
drivers/net/wireless/cisco/airo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/cisco/airo.c b/drivers/net/wireless/cisco/airo.c
index 69b826d229c5..53d43c93a284 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -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);
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/
2016-12-01 12:32 ` [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/ David Howells
@ 2016-12-02 5:04 ` Kalle Valo
2016-12-07 13:45 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: Kalle Valo @ 2016-12-02 5:04 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, gnomes, minyard, netdev, linux-wireless,
linux-security-module, keyrings
David Howells <dhowells@redhat.com> writes:
> 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/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Kalle Valo <kvalo@codeaurora.org>
> cc: linux-wireless@vger.kernel.org
> cc: netdev@vger.kernel.org
> ---
>
> drivers/net/wireless/cisco/airo.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/
2016-12-01 12:32 ` [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/ David Howells
2016-12-02 5:04 ` Kalle Valo
@ 2016-12-07 13:45 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-07 13:45 UTC (permalink / raw)
To: Kalle Valo
Cc: dhowells, linux-kernel, gnomes, minyard, netdev, linux-wireless,
linux-security-module, keyrings
Kalle Valo <kvalo@codeaurora.org> wrote:
> 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.
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
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 24/39] Annotate hardware config module parameters in drivers/parport/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (22 preceding siblings ...)
2016-12-01 12:32 ` [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/ David Howells
@ 2016-12-01 12:32 ` David Howells
2016-12-01 12:32 ` [PATCH 25/39] Annotate hardware config module parameters in drivers/pci/hotplug/ David Howells
` (14 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:32 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, dhowells, linux-security-module, keyrings,
Sudip Mukherjee
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
---
drivers/parport/parport_pc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 78530d1714dc..2080a0798d52 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -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");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 25/39] Annotate hardware config module parameters in drivers/pci/hotplug/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (23 preceding siblings ...)
2016-12-01 12:32 ` [PATCH 24/39] Annotate hardware config module parameters in drivers/parport/ David Howells
@ 2016-12-01 12:32 ` David Howells
2016-12-07 18:34 ` Bjorn Helgaas
2016-12-01 12:33 ` [PATCH 26/39] Annotate hardware config module parameters in drivers/pcmcia/ David Howells
` (13 subsequent siblings)
38 siblings, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-01 12:32 UTC (permalink / raw)
To: linux-kernel
Cc: Scott Murray, minyard, gnomes, linux-pci, dhowells,
linux-security-module, keyrings, Bjorn Helgaas
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Scott Murray <scott@spiteful.org>
cc: Bjorn Helgaas <bhelgaas@google.com>
cc: linux-pci@vger.kernel.org
---
drivers/pci/hotplug/cpcihp_generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/hotplug/cpcihp_generic.c b/drivers/pci/hotplug/cpcihp_generic.c
index 88a44a707b96..bbf9cf8aeaad 100644
--- a/drivers/pci/hotplug/cpcihp_generic.c
+++ b/drivers/pci/hotplug/cpcihp_generic.c
@@ -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)");
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 25/39] Annotate hardware config module parameters in drivers/pci/hotplug/
2016-12-01 12:32 ` [PATCH 25/39] Annotate hardware config module parameters in drivers/pci/hotplug/ David Howells
@ 2016-12-07 18:34 ` Bjorn Helgaas
0 siblings, 0 replies; 78+ messages in thread
From: Bjorn Helgaas @ 2016-12-07 18:34 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, Scott Murray, minyard, gnomes, linux-pci,
linux-security-module, keyrings, Bjorn Helgaas
On Thu, Dec 01, 2016 at 12:32:58PM +0000, David Howells wrote:
> 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/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Scott Murray <scott@spiteful.org>
> cc: Bjorn Helgaas <bhelgaas@google.com>
> cc: linux-pci@vger.kernel.org
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
I assume you'll merge this via some non-PCI tree. Let me know if you
need anything else from me.
> ---
>
> drivers/pci/hotplug/cpcihp_generic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/cpcihp_generic.c b/drivers/pci/hotplug/cpcihp_generic.c
> index 88a44a707b96..bbf9cf8aeaad 100644
> --- a/drivers/pci/hotplug/cpcihp_generic.c
> +++ b/drivers/pci/hotplug/cpcihp_generic.c
> @@ -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)");
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 26/39] Annotate hardware config module parameters in drivers/pcmcia/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (24 preceding siblings ...)
2016-12-01 12:32 ` [PATCH 25/39] Annotate hardware config module parameters in drivers/pci/hotplug/ David Howells
@ 2016-12-01 12:33 ` David Howells
2016-12-01 12:33 ` [PATCH 27/39] Annotate hardware config module parameters in drivers/scsi/ David Howells
` (12 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:33 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, linux-pcmcia, dhowells, linux-security-module, keyrings
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pcmcia@lists.infradead.org
---
drivers/pcmcia/i82365.c | 8 ++++----
drivers/pcmcia/tcic.c | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/pcmcia/i82365.c b/drivers/pcmcia/i82365.c
index eb0d80a429e4..fb38cc01859f 100644
--- a/drivers/pcmcia/i82365.c
+++ b/drivers/pcmcia/i82365.c
@@ -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);
diff --git a/drivers/pcmcia/tcic.c b/drivers/pcmcia/tcic.c
index 1ee63e5f0550..a1ac72d51d70 100644
--- a/drivers/pcmcia/tcic.c
+++ b/drivers/pcmcia/tcic.c
@@ -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);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 27/39] Annotate hardware config module parameters in drivers/scsi/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (25 preceding siblings ...)
2016-12-01 12:33 ` [PATCH 26/39] Annotate hardware config module parameters in drivers/pcmcia/ David Howells
@ 2016-12-01 12:33 ` David Howells
2016-12-01 22:05 ` Finn Thain
2017-04-05 14:33 ` David Howells
2016-12-01 12:33 ` [PATCH 28/39] Annotate hardware config module parameters in drivers/staging/i4l/ David Howells
` (11 subsequent siblings)
38 siblings, 2 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:33 UTC (permalink / raw)
To: linux-kernel
Cc: Michael Schmitz, Achim Leubner, James E.J. Bottomley, linux-scsi,
Martin K. Petersen, gnomes, Finn Thain, dhowells,
linux-security-module, keyrings, minyard, Juergen E. Fischer,
Dario Ballabio
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: "Juergen E. Fischer" <fischer@norbit.de>
cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
cc: "Martin K. Petersen" <martin.petersen@oracle.com>
cc: Dario Ballabio <ballabio_dario@emc.com>
cc: Finn Thain <fthain@telegraphics.com.au>
cc: Michael Schmitz <schmitzmic@gmail.com>
cc: Achim Leubner <achim_leubner@adaptec.com>
cc: linux-scsi@vger.kernel.org
---
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(-)
diff --git a/drivers/scsi/aha152x.c b/drivers/scsi/aha152x.c
index f44d0487236e..ce5dc73d85bb 100644
--- a/drivers/scsi/aha152x.c
+++ b/drivers/scsi/aha152x.c
@@ -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};
diff --git a/drivers/scsi/aha1542.c b/drivers/scsi/aha1542.c
index 7db448ec8beb..a23cc9ac5acd 100644
--- a/drivers/scsi/aha1542.c
+++ b/drivers/scsi/aha1542.c
@@ -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 */
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index cbf010324c18..cf4fa7a2e738 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -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 };
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 0a767740bf02..4ec08fb2dfa8 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -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);
diff --git a/drivers/scsi/qlogicfas.c b/drivers/scsi/qlogicfas.c
index 61cac87fb86f..840823b99e51 100644
--- a/drivers/scsi/qlogicfas.c
+++ b/drivers/scsi/qlogicfas.c
@@ -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");
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 27/39] Annotate hardware config module parameters in drivers/scsi/
2016-12-01 12:33 ` [PATCH 27/39] Annotate hardware config module parameters in drivers/scsi/ David Howells
@ 2016-12-01 22:05 ` Finn Thain
2017-04-05 14:33 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: Finn Thain @ 2016-12-01 22:05 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, Michael Schmitz, Achim Leubner,
James E.J. Bottomley, linux-scsi, Martin K. Petersen, gnomes,
linux-security-module, keyrings, minyard, Juergen E. Fischer,
Dario Ballabio
On Thu, 1 Dec 2016, David Howells wrote:
> 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.
>
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.
> 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/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: "Juergen E. Fischer" <fischer@norbit.de>
> cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
> cc: "Martin K. Petersen" <martin.petersen@oracle.com>
> cc: Dario Ballabio <ballabio_dario@emc.com>
> cc: Finn Thain <fthain@telegraphics.com.au>
> cc: Michael Schmitz <schmitzmic@gmail.com>
> cc: Achim Leubner <achim_leubner@adaptec.com>
> cc: linux-scsi@vger.kernel.org
> ---
>
> 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(-)
>
> diff --git a/drivers/scsi/aha152x.c b/drivers/scsi/aha152x.c
> index f44d0487236e..ce5dc73d85bb 100644
> --- a/drivers/scsi/aha152x.c
> +++ b/drivers/scsi/aha152x.c
> @@ -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};
> diff --git a/drivers/scsi/aha1542.c b/drivers/scsi/aha1542.c
> index 7db448ec8beb..a23cc9ac5acd 100644
> --- a/drivers/scsi/aha1542.c
> +++ b/drivers/scsi/aha1542.c
> @@ -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 */
> diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
> index cbf010324c18..cf4fa7a2e738 100644
> --- a/drivers/scsi/g_NCR5380.c
> +++ b/drivers/scsi/g_NCR5380.c
> @@ -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 };
> diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
> index 0a767740bf02..4ec08fb2dfa8 100644
> --- a/drivers/scsi/gdth.c
> +++ b/drivers/scsi/gdth.c
> @@ -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);
> diff --git a/drivers/scsi/qlogicfas.c b/drivers/scsi/qlogicfas.c
> index 61cac87fb86f..840823b99e51 100644
> --- a/drivers/scsi/qlogicfas.c
> +++ b/drivers/scsi/qlogicfas.c
> @@ -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");
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
^ permalink raw reply [flat|nested] 78+ messages in thread* Re: [PATCH 27/39] Annotate hardware config module parameters in drivers/scsi/
2016-12-01 12:33 ` [PATCH 27/39] Annotate hardware config module parameters in drivers/scsi/ David Howells
2016-12-01 22:05 ` Finn Thain
@ 2017-04-05 14:33 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: David Howells @ 2017-04-05 14:33 UTC (permalink / raw)
To: Finn Thain
Cc: dhowells, linux-kernel, Michael Schmitz, Achim Leubner,
James E.J. Bottomley, linux-scsi, Martin K. Petersen, gnomes,
linux-security-module, keyrings, minyard, Juergen E. Fischer,
Dario Ballabio
Finn Thain <fthain@telegraphics.com.au> wrote:
> 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
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 28/39] Annotate hardware config module parameters in drivers/staging/i4l/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (26 preceding siblings ...)
2016-12-01 12:33 ` [PATCH 27/39] Annotate hardware config module parameters in drivers/scsi/ David Howells
@ 2016-12-01 12:33 ` David Howells
2016-12-01 12:33 ` [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/ David Howells
` (10 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:33 UTC (permalink / raw)
To: linux-kernel
Cc: devel, gnomes, minyard, Greg Kroah-Hartman, dhowells,
linux-security-module, keyrings
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: devel@driverdev.osuosl.org
---
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(-)
diff --git a/drivers/staging/i4l/act2000/module.c b/drivers/staging/i4l/act2000/module.c
index 99c9c0a1c63e..b3c81e2af7b2 100644
--- a/drivers/staging/i4l/act2000/module.c
+++ b/drivers/staging/i4l/act2000/module.c
@@ -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 *);
diff --git a/drivers/staging/i4l/icn/icn.c b/drivers/staging/i4l/icn/icn.c
index 514bfc2c5b53..cadeee74e9f4 100644
--- a/drivers/staging/i4l/icn/icn.c
+++ b/drivers/staging/i4l/icn/icn.c
@@ -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");
diff --git a/drivers/staging/i4l/pcbit/module.c b/drivers/staging/i4l/pcbit/module.c
index 0a59bd0b8210..5a3ea2808351 100644
--- a/drivers/staging/i4l/pcbit/module.c
+++ b/drivers/staging/i4l/pcbit/module.c
@@ -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];
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (27 preceding siblings ...)
2016-12-01 12:33 ` [PATCH 28/39] Annotate hardware config module parameters in drivers/staging/i4l/ David Howells
@ 2016-12-01 12:33 ` David Howells
2016-12-01 14:54 ` Mauro Carvalho Chehab
2016-12-01 14:59 ` David Howells
2016-12-01 12:33 ` [PATCH 30/39] Annotate hardware config module parameters in drivers/staging/speakup/ David Howells
` (9 subsequent siblings)
38 siblings, 2 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:33 UTC (permalink / raw)
To: linux-kernel
Cc: devel, gnomes, minyard, Greg Kroah-Hartman, dhowells,
linux-security-module, keyrings, Mauro Carvalho Chehab,
linux-media
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/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Mauro Carvalho Chehab <mchehab@kernel.org>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: linux-media@vger.kernel.org
cc: devel@driverdev.osuosl.org
---
drivers/staging/media/lirc/lirc_parallel.c | 4 ++--
drivers/staging/media/lirc/lirc_serial.c | 10 +++++-----
drivers/staging/media/lirc/lirc_sir.c | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_parallel.c b/drivers/staging/media/lirc/lirc_parallel.c
index bfb76a45bfbf..65530e0a6d99 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -725,10 +725,10 @@ MODULE_DESCRIPTION("Infrared receiver driver for parallel ports.");
MODULE_AUTHOR("Christoph Bartelmus");
MODULE_LICENSE("GPL");
-module_param(io, int, S_IRUGO);
+module_param_hw(io, int, ioport, S_IRUGO);
MODULE_PARM_DESC(io, "I/O address base (0x3bc, 0x378 or 0x278)");
-module_param(irq, int, S_IRUGO);
+module_param_hw(irq, int, irq, S_IRUGO);
MODULE_PARM_DESC(irq, "Interrupt (7 or 5)");
module_param(tx_mask, int, S_IRUGO);
diff --git a/drivers/staging/media/lirc/lirc_serial.c b/drivers/staging/media/lirc/lirc_serial.c
index b798b311d32c..ea3f735a196d 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -1094,11 +1094,11 @@ MODULE_PARM_DESC(type, "Hardware type (0 = home-brew, 1 = IRdeo,"
" 2 = IRdeo Remote, 3 = AnimaX, 4 = IgorPlug,"
" 5 = NSLU2 RX:CTS2/TX:GreenLED)");
-module_param(io, int, S_IRUGO);
+module_param_hw(io, int, ioport, S_IRUGO);
MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)");
/* some architectures (e.g. intel xscale) have memory mapped registers */
-module_param(iommap, bool, S_IRUGO);
+module_param_hw(iommap, bool, other, S_IRUGO);
MODULE_PARM_DESC(iommap, "physical base for memory mapped I/O"
" (0 = no memory mapped io)");
@@ -1107,13 +1107,13 @@ MODULE_PARM_DESC(iommap, "physical base for memory mapped I/O"
* on 32bit word boundaries.
* See linux-kernel/drivers/tty/serial/8250/8250.c serial_in()/out()
*/
-module_param(ioshift, int, S_IRUGO);
+module_param_hw(ioshift, int, other, S_IRUGO);
MODULE_PARM_DESC(ioshift, "shift I/O register offset (0 = no shift)");
-module_param(irq, int, S_IRUGO);
+module_param_hw(irq, int, irq, S_IRUGO);
MODULE_PARM_DESC(irq, "Interrupt (4 or 3)");
-module_param(share_irq, bool, S_IRUGO);
+module_param_hw (share_irq, bool, other, S_IRUGO);
MODULE_PARM_DESC(share_irq, "Share interrupts (0 = off, 1 = on)");
module_param(sense, int, S_IRUGO);
diff --git a/drivers/staging/media/lirc/lirc_sir.c b/drivers/staging/media/lirc/lirc_sir.c
index 4f326e97ad75..e27842e01fba 100644
--- a/drivers/staging/media/lirc/lirc_sir.c
+++ b/drivers/staging/media/lirc/lirc_sir.c
@@ -986,10 +986,10 @@ MODULE_AUTHOR("Milan Pikula");
#endif
MODULE_LICENSE("GPL");
-module_param(io, int, S_IRUGO);
+module_param_hw(io, int, ioport, S_IRUGO);
MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)");
-module_param(irq, int, S_IRUGO);
+module_param_hw(irq, int, irq, S_IRUGO);
MODULE_PARM_DESC(irq, "Interrupt (4 or 3)");
module_param(threshold, int, S_IRUGO);
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/
2016-12-01 12:33 ` [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/ David Howells
@ 2016-12-01 14:54 ` Mauro Carvalho Chehab
2016-12-01 14:59 ` David Howells
1 sibling, 0 replies; 78+ messages in thread
From: Mauro Carvalho Chehab @ 2016-12-01 14:54 UTC (permalink / raw)
To: David Howells, Greg Kroah-Hartman
Cc: linux-kernel, devel, gnomes, minyard, linux-security-module,
keyrings, Mauro Carvalho Chehab, linux-media
Em Thu, 01 Dec 2016 12:33:30 +0000
David Howells <dhowells@redhat.com> escreveu:
> 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/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> cc: linux-media@vger.kernel.org
> cc: devel@driverdev.osuosl.org
Tried to apply here, but got some errors:
drivers/staging/media/lirc/lirc_parallel.c:728:19: error: Expected ) in function declarator
drivers/staging/media/lirc/lirc_parallel.c:728:19: error: got ,
drivers/staging/media/lirc/lirc_parallel.c:731:20: error: Expected ) in function declarator
drivers/staging/media/lirc/lirc_parallel.c:731:20: error: got ,
drivers/staging/media/lirc/lirc_sir.c:989:19: error: Expected ) in function declarator
drivers/staging/media/lirc/lirc_sir.c:989:19: error: got ,
drivers/staging/media/lirc/lirc_sir.c:992:20: error: Expected ) in function declarator
drivers/staging/media/lirc/lirc_sir.c:992:20: error: got ,
drivers/staging/media/lirc/lirc_sir.c:989:21: error: expected ')' before 'int'
module_param_hw(io, int, ioport, S_IRUGO);
^~~
drivers/staging/media/lirc/lirc_sir.c:992:22: error: expected ')' before 'int'
module_param_hw(irq, int, irq, S_IRUGO);
^~~
scripts/Makefile.build:293: recipe for target 'drivers/staging/media/lirc/lirc_sir.o' failed
make[2]: *** [drivers/staging/media/lirc/lirc_sir.o] Error 1
make[2]: *** Waiting for unfinished jobs....
drivers/staging/media/lirc/lirc_parallel.c:728:21: error: expected ')' before 'int'
module_param_hw(io, int, ioport, S_IRUGO);
^~~
drivers/staging/media/lirc/lirc_parallel.c:731:22: error: expected ')' before 'int'
module_param_hw(irq, int, irq, S_IRUGO);
^~~
scripts/Makefile.build:293: recipe for target 'drivers/staging/media/lirc/lirc_parallel.o' failed
make[2]: *** [drivers/staging/media/lirc/lirc_parallel.o] Error 1
scripts/Makefile.build:544: recipe for target 'drivers/staging/media/lirc' failed
make[1]: *** [drivers/staging/media/lirc] Error 2
Makefile:1485: recipe for target '_module_drivers/staging/media' failed
make: *** [_module_drivers/staging/media] Error 2
> ---
>
> drivers/staging/media/lirc/lirc_parallel.c | 4 ++--
> drivers/staging/media/lirc/lirc_serial.c | 10 +++++-----
Btw, this got moved to another place, and had some patch getting rid
of those really ugly S_IRUGO & friend macros.
I rebased it to apply over the top of the media tree, but I suspect
it requires some other patch to be applied adding the new macro.
I'm enclosing the rebased patch as reference.
Regards,
Mauro
[PATCH] [media] Annotate hardware config module parameters in drivers/staging/media/
From: David Howells <dhowells@redhat.com>
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/.
[mchehab@s-opensource.com: fixed merge conflicts at serial_ir.c]
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: devel@driverdev.osuosl.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
index 436bd58b5f05..b7e44461de4a 100644
--- a/drivers/media/rc/serial_ir.c
+++ b/drivers/media/rc/serial_ir.c
@@ -811,11 +811,11 @@ MODULE_LICENSE("GPL");
module_param(type, int, 0444);
MODULE_PARM_DESC(type, "Hardware type (0 = home-brew, 1 = IRdeo, 2 = IRdeo Remote, 3 = AnimaX, 4 = IgorPlug");
-module_param(io, int, 0444);
+module_param_hw(io, int, ioport, 0444);
MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)");
/* some architectures (e.g. intel xscale) have memory mapped registers */
-module_param(iommap, bool, 0444);
+module_param_hw(iommap, bool, other, 0444);
MODULE_PARM_DESC(iommap, "physical base for memory mapped I/O (0 = no memory mapped io)");
/*
@@ -823,13 +823,13 @@ MODULE_PARM_DESC(iommap, "physical base for memory mapped I/O (0 = no memory map
* on 32bit word boundaries.
* See linux-kernel/drivers/tty/serial/8250/8250.c serial_in()/out()
*/
-module_param(ioshift, int, 0444);
+module_param_hw(ioshift, int, other, 0444);
MODULE_PARM_DESC(ioshift, "shift I/O register offset (0 = no shift)");
-module_param(irq, int, 0444);
+module_param_hw(irq, int, irq, 0444);
MODULE_PARM_DESC(irq, "Interrupt (4 or 3)");
-module_param(share_irq, bool, 0444);
+module_param_hw (share_irq, bool, other, 0444);
MODULE_PARM_DESC(share_irq, "Share interrupts (0 = off, 1 = on)");
module_param(sense, int, 0444);
diff --git a/drivers/staging/media/lirc/lirc_parallel.c b/drivers/staging/media/lirc/lirc_parallel.c
index bfb76a45bfbf..65530e0a6d99 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -725,10 +725,10 @@ MODULE_DESCRIPTION("Infrared receiver driver for parallel ports.");
MODULE_AUTHOR("Christoph Bartelmus");
MODULE_LICENSE("GPL");
-module_param(io, int, S_IRUGO);
+module_param_hw(io, int, ioport, S_IRUGO);
MODULE_PARM_DESC(io, "I/O address base (0x3bc, 0x378 or 0x278)");
-module_param(irq, int, S_IRUGO);
+module_param_hw(irq, int, irq, S_IRUGO);
MODULE_PARM_DESC(irq, "Interrupt (7 or 5)");
module_param(tx_mask, int, S_IRUGO);
diff --git a/drivers/staging/media/lirc/lirc_sir.c b/drivers/staging/media/lirc/lirc_sir.c
index 4f326e97ad75..e27842e01fba 100644
--- a/drivers/staging/media/lirc/lirc_sir.c
+++ b/drivers/staging/media/lirc/lirc_sir.c
@@ -986,10 +986,10 @@ MODULE_AUTHOR("Milan Pikula");
#endif
MODULE_LICENSE("GPL");
-module_param(io, int, S_IRUGO);
+module_param_hw(io, int, ioport, S_IRUGO);
MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)");
-module_param(irq, int, S_IRUGO);
+module_param_hw(irq, int, irq, S_IRUGO);
MODULE_PARM_DESC(irq, "Interrupt (4 or 3)");
module_param(threshold, int, S_IRUGO);
Thanks,
Mauro
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/
2016-12-01 12:33 ` [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/ David Howells
2016-12-01 14:54 ` Mauro Carvalho Chehab
@ 2016-12-01 14:59 ` David Howells
2016-12-01 15:17 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-01 14:59 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: dhowells, Greg Kroah-Hartman, linux-kernel, devel, gnomes,
minyard, linux-security-module, keyrings, Mauro Carvalho Chehab,
linux-media
Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
> drivers/staging/media/lirc/lirc_parallel.c:728:19: error: Expected ) in function declarator
Did you apply patch 1 first? That defines module_param_hw*.
David
^ permalink raw reply [flat|nested] 78+ messages in thread
* Re: [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/
2016-12-01 14:59 ` David Howells
@ 2016-12-01 15:17 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 78+ messages in thread
From: Mauro Carvalho Chehab @ 2016-12-01 15:17 UTC (permalink / raw)
To: David Howells
Cc: Greg Kroah-Hartman, linux-kernel, devel, gnomes, minyard,
linux-security-module, keyrings, Mauro Carvalho Chehab,
linux-media
Em Thu, 01 Dec 2016 14:59:56 +0000
David Howells <dhowells@redhat.com> escreveu:
> Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
>
> > drivers/staging/media/lirc/lirc_parallel.c:728:19: error: Expected ) in function declarator
>
> Did you apply patch 1 first? That defines module_param_hw*.
No. Applying it at the media upstream tree can be risky if it ends
by being merged with some changes.
On what tree do you intend patch 1 to be merged?
>
> David
Thanks,
Mauro
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 30/39] Annotate hardware config module parameters in drivers/staging/speakup/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (28 preceding siblings ...)
2016-12-01 12:33 ` [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/ David Howells
@ 2016-12-01 12:33 ` David Howells
2016-12-01 12:33 ` [PATCH 31/39] Annotate hardware config module parameters in drivers/staging/vme/ David Howells
` (8 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:33 UTC (permalink / raw)
To: linux-kernel
Cc: devel, gnomes, minyard, Greg Kroah-Hartman, speakup, dhowells,
linux-security-module, keyrings
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/speakup/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: speakup@linux-speakup.org
cc: devel@driverdev.osuosl.org
---
drivers/staging/speakup/speakup_acntpc.c | 2 +-
drivers/staging/speakup/speakup_dtlk.c | 2 +-
drivers/staging/speakup/speakup_keypc.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/speakup/speakup_acntpc.c b/drivers/staging/speakup/speakup_acntpc.c
index efb791bb642b..e7bbc03e4a4f 100644
--- a/drivers/staging/speakup/speakup_acntpc.c
+++ b/drivers/staging/speakup/speakup_acntpc.c
@@ -307,7 +307,7 @@ static void accent_release(void)
speakup_info.port_tts = 0;
}
-module_param_named(port, port_forced, int, S_IRUGO);
+module_param_hw_named(port, port_forced, int, ioport, S_IRUGO);
module_param_named(start, synth_acntpc.startup, short, S_IRUGO);
MODULE_PARM_DESC(port, "Set the port for the synthesizer (override probing).");
diff --git a/drivers/staging/speakup/speakup_dtlk.c b/drivers/staging/speakup/speakup_dtlk.c
index 38aa4013bf62..d04aa9e0a147 100644
--- a/drivers/staging/speakup/speakup_dtlk.c
+++ b/drivers/staging/speakup/speakup_dtlk.c
@@ -378,7 +378,7 @@ static void dtlk_release(void)
speakup_info.port_tts = 0;
}
-module_param_named(port, port_forced, int, S_IRUGO);
+module_param_hw_named(port, port_forced, int, ioport, S_IRUGO);
module_param_named(start, synth_dtlk.startup, short, S_IRUGO);
MODULE_PARM_DESC(port, "Set the port for the synthesizer (override probing).");
diff --git a/drivers/staging/speakup/speakup_keypc.c b/drivers/staging/speakup/speakup_keypc.c
index 5e2170bf4a8b..d245c7de5ee6 100644
--- a/drivers/staging/speakup/speakup_keypc.c
+++ b/drivers/staging/speakup/speakup_keypc.c
@@ -309,7 +309,7 @@ static void keynote_release(void)
synth_port = 0;
}
-module_param_named(port, port_forced, int, S_IRUGO);
+module_param_hw_named(port, port_forced, int, ioport, S_IRUGO);
module_param_named(start, synth_keypc.startup, short, S_IRUGO);
MODULE_PARM_DESC(port, "Set the port for the synthesizer (override probing).");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 31/39] Annotate hardware config module parameters in drivers/staging/vme/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (29 preceding siblings ...)
2016-12-01 12:33 ` [PATCH 30/39] Annotate hardware config module parameters in drivers/staging/speakup/ David Howells
@ 2016-12-01 12:33 ` David Howells
2016-12-01 12:33 ` [PATCH 32/39] Annotate hardware config module parameters in drivers/tty/ David Howells
` (7 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:33 UTC (permalink / raw)
To: linux-kernel
Cc: devel, gnomes, Manohar Vanga, minyard, Greg Kroah-Hartman,
Martyn Welch, dhowells, linux-security-module, keyrings
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/vme/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Martyn Welch <martyn@welchs.me.uk>
cc: Manohar Vanga <manohar.vanga@gmail.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: devel@driverdev.osuosl.org
---
drivers/staging/vme/devices/vme_pio2_core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_pio2_core.c b/drivers/staging/vme/devices/vme_pio2_core.c
index 8e66a520266c..c0e71cb27a6b 100644
--- a/drivers/staging/vme/devices/vme_pio2_core.c
+++ b/drivers/staging/vme/devices/vme_pio2_core.c
@@ -466,16 +466,16 @@ static void __exit pio2_exit(void)
/* These are required for each board */
MODULE_PARM_DESC(bus, "Enumeration of VMEbus to which the board is connected");
-module_param_array(bus, int, &bus_num, 0444);
+module_param_hw_array(bus, int, other, &bus_num, 0444);
MODULE_PARM_DESC(base, "Base VME address for PIO2 Registers");
-module_param_array(base, long, &base_num, 0444);
+module_param_hw_array(base, long, other, &base_num, 0444);
MODULE_PARM_DESC(vector, "VME IRQ Vector (Lower 4 bits masked)");
-module_param_array(vector, int, &vector_num, 0444);
+module_param_hw_array(vector, int, other, &vector_num, 0444);
MODULE_PARM_DESC(level, "VME IRQ Level");
-module_param_array(level, int, &level_num, 0444);
+module_param_hw_array(level, int, other, &level_num, 0444);
MODULE_PARM_DESC(variant, "Last 4 characters of PIO2 board variant");
module_param_array(variant, charp, &variant_num, 0444);
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 32/39] Annotate hardware config module parameters in drivers/tty/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (30 preceding siblings ...)
2016-12-01 12:33 ` [PATCH 31/39] Annotate hardware config module parameters in drivers/staging/vme/ David Howells
@ 2016-12-01 12:33 ` David Howells
2016-12-01 15:02 ` Greg Kroah-Hartman
2016-12-01 12:34 ` [PATCH 33/39] Annotate hardware config module parameters in drivers/video/ David Howells
` (6 subsequent siblings)
38 siblings, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-01 12:33 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, Greg Kroah-Hartman, dhowells,
linux-security-module, keyrings, linux-serial, Jiri Slaby
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/tty/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Jiri Slaby <jslaby@suse.com>
cc: linux-serial@vger.kernel.org
---
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 +++---
6 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/tty/cyclades.c b/drivers/tty/cyclades.c
index 5e4fa9206861..104f09c58163 100644
--- a/drivers/tty/cyclades.c
+++ b/drivers/tty/cyclades.c
@@ -156,8 +156,8 @@ static unsigned int cy_isa_addresses[] = {
static long maddr[NR_CARDS];
static int irq[NR_CARDS];
-module_param_array(maddr, long, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(maddr, long, iomem, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
#endif /* CONFIG_ISA */
diff --git a/drivers/tty/moxa.c b/drivers/tty/moxa.c
index 60d37b225589..055acf6acfc0 100644
--- a/drivers/tty/moxa.c
+++ b/drivers/tty/moxa.c
@@ -179,7 +179,7 @@ MODULE_FIRMWARE("c320tunx.cod");
module_param_array(type, uint, NULL, 0);
MODULE_PARM_DESC(type, "card type: C218=2, C320=4");
-module_param_array(baseaddr, ulong, NULL, 0);
+module_param_hw_array(baseaddr, ulong, ioport, NULL, 0);
MODULE_PARM_DESC(baseaddr, "base address");
module_param_array(numports, uint, NULL, 0);
MODULE_PARM_DESC(numports, "numports (ignored for C218)");
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 69294ae154be..80770da545dd 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -183,7 +183,7 @@ static int ttymajor = MXSERMAJOR;
MODULE_AUTHOR("Casper Yang");
MODULE_DESCRIPTION("MOXA Smartio/Industio Family Multiport Board Device Driver");
-module_param_array(ioaddr, ulong, NULL, 0);
+module_param_hw_array(ioaddr, ulong, ioport, NULL, 0);
MODULE_PARM_DESC(ioaddr, "ISA io addresses to look for a moxa board");
module_param(ttymajor, int, 0);
MODULE_LICENSE("GPL");
diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c
index b0cc47c77b40..44f6c3383c33 100644
--- a/drivers/tty/rocket.c
+++ b/drivers/tty/rocket.c
@@ -250,15 +250,15 @@ static int sReadAiopNumChan(WordIO_t io);
MODULE_AUTHOR("Theodore Ts'o");
MODULE_DESCRIPTION("Comtrol RocketPort driver");
-module_param(board1, ulong, 0);
+module_param_hw(board1, ulong, ioport, 0);
MODULE_PARM_DESC(board1, "I/O port for (ISA) board #1");
-module_param(board2, ulong, 0);
+module_param_hw(board2, ulong, ioport, 0);
MODULE_PARM_DESC(board2, "I/O port for (ISA) board #2");
-module_param(board3, ulong, 0);
+module_param_hw(board3, ulong, ioport, 0);
MODULE_PARM_DESC(board3, "I/O port for (ISA) board #3");
-module_param(board4, ulong, 0);
+module_param_hw(board4, ulong, ioport, 0);
MODULE_PARM_DESC(board4, "I/O port for (ISA) board #4");
-module_param(controller, ulong, 0);
+module_param_hw(controller, ulong, ioport, 0);
MODULE_PARM_DESC(controller, "I/O port for (ISA) rocketport controller");
module_param(support_low_speed, bool, 0);
MODULE_PARM_DESC(support_low_speed, "1 means support 50 baud, 0 means support 460400 baud");
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 240a361b674f..414af45dc16e 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1188,7 +1188,7 @@ module_exit(serial8250_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Generic 8250/16x50 serial driver");
-module_param(share_irqs, uint, 0644);
+module_param_hw(share_irqs, uint, other, 0644);
MODULE_PARM_DESC(share_irqs, "Share IRQs with other non-8250/16x50 devices (unsafe)");
module_param(nr_uarts, uint, 0644);
@@ -1198,7 +1198,7 @@ module_param(skip_txen_test, uint, 0644);
MODULE_PARM_DESC(skip_txen_test, "Skip checking for the TXEN bug at init time");
#ifdef CONFIG_SERIAL_8250_RSA
-module_param_array(probe_rsa, ulong, &probe_rsa_count, 0444);
+module_param_hw_array(probe_rsa, ulong, ioport, &probe_rsa_count, 0444);
MODULE_PARM_DESC(probe_rsa, "Probe I/O ports for RSA");
#endif
MODULE_ALIAS_CHARDEV_MAJOR(TTY_MAJOR);
diff --git a/drivers/tty/synclink.c b/drivers/tty/synclink.c
index c13e27ecb0b7..71dd598d76a0 100644
--- a/drivers/tty/synclink.c
+++ b/drivers/tty/synclink.c
@@ -869,9 +869,9 @@ static int txholdbufs[MAX_TOTAL_DEVICES];
module_param(break_on_load, bool, 0);
module_param(ttymajor, int, 0);
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
-module_param_array(dma, 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(dma, int, dma, NULL, 0);
module_param(debug_level, int, 0);
module_param_array(maxframe, int, NULL, 0);
module_param_array(txdmabufs, int, NULL, 0);
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 32/39] Annotate hardware config module parameters in drivers/tty/
2016-12-01 12:33 ` [PATCH 32/39] Annotate hardware config module parameters in drivers/tty/ David Howells
@ 2016-12-01 15:02 ` Greg Kroah-Hartman
0 siblings, 0 replies; 78+ messages in thread
From: Greg Kroah-Hartman @ 2016-12-01 15:02 UTC (permalink / raw)
To: David Howells
Cc: linux-kernel, gnomes, minyard, linux-security-module, keyrings,
linux-serial, Jiri Slaby
On Thu, Dec 01, 2016 at 12:33:54PM +0000, David Howells wrote:
> 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/tty/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> cc: Jiri Slaby <jslaby@suse.com>
> cc: linux-serial@vger.kernel.org
> ---
>
> 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 +++---
> 6 files changed, 14 insertions(+), 14 deletions(-)
NAK, see my response to patch 1 of this series.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 33/39] Annotate hardware config module parameters in drivers/video/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (31 preceding siblings ...)
2016-12-01 12:33 ` [PATCH 32/39] Annotate hardware config module parameters in drivers/tty/ David Howells
@ 2016-12-01 12:34 ` David Howells
2016-12-01 12:34 ` [PATCH 34/39] Annotate hardware config module parameters in drivers/watchdog/ David Howells
` (5 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:34 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, linux-fbdev, minyard, dhowells, linux-security-module,
Tomi Valkeinen, keyrings, Jaya Kumar
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/video/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jaya Kumar <jayalk@intworks.biz>
cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
cc: linux-fbdev@vger.kernel.org
---
drivers/video/fbdev/arcfb.c | 8 ++++----
drivers/video/fbdev/n411.c | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
index 1928cb2b5386..7e87d0d61658 100644
--- a/drivers/video/fbdev/arcfb.c
+++ b/drivers/video/fbdev/arcfb.c
@@ -645,17 +645,17 @@ module_param(nosplash, uint, 0);
MODULE_PARM_DESC(nosplash, "Disable doing the splash screen");
module_param(arcfb_enable, uint, 0);
MODULE_PARM_DESC(arcfb_enable, "Enable communication with Arc board");
-module_param(dio_addr, ulong, 0);
+module_param_hw(dio_addr, ulong, ioport, 0);
MODULE_PARM_DESC(dio_addr, "IO address for data, eg: 0x480");
-module_param(cio_addr, ulong, 0);
+module_param_hw(cio_addr, ulong, ioport, 0);
MODULE_PARM_DESC(cio_addr, "IO address for control, eg: 0x400");
-module_param(c2io_addr, ulong, 0);
+module_param_hw(c2io_addr, ulong, ioport, 0);
MODULE_PARM_DESC(c2io_addr, "IO address for secondary control, eg: 0x408");
module_param(splashval, ulong, 0);
MODULE_PARM_DESC(splashval, "Splash pattern: 0xFF is black, 0x00 is green");
module_param(tuhold, ulong, 0);
MODULE_PARM_DESC(tuhold, "Time to hold between strobing data to Arc board");
-module_param(irq, uint, 0);
+module_param_hw(irq, uint, irq, 0);
MODULE_PARM_DESC(irq, "IRQ for the Arc board");
module_init(arcfb_init);
diff --git a/drivers/video/fbdev/n411.c b/drivers/video/fbdev/n411.c
index 053deacad7cc..a3677313396e 100644
--- a/drivers/video/fbdev/n411.c
+++ b/drivers/video/fbdev/n411.c
@@ -193,11 +193,11 @@ module_exit(n411_exit);
module_param(nosplash, uint, 0);
MODULE_PARM_DESC(nosplash, "Disable doing the splash screen");
-module_param(dio_addr, ulong, 0);
+module_param_hw(dio_addr, ulong, ioport, 0);
MODULE_PARM_DESC(dio_addr, "IO address for data, eg: 0x480");
-module_param(cio_addr, ulong, 0);
+module_param_hw(cio_addr, ulong, ioport, 0);
MODULE_PARM_DESC(cio_addr, "IO address for control, eg: 0x400");
-module_param(c2io_addr, ulong, 0);
+module_param_hw(c2io_addr, ulong, ioport, 0);
MODULE_PARM_DESC(c2io_addr, "IO address for secondary control, eg: 0x408");
module_param(splashval, ulong, 0);
MODULE_PARM_DESC(splashval, "Splash pattern: 0x00 is black, 0x01 is white");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 34/39] Annotate hardware config module parameters in drivers/watchdog/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (32 preceding siblings ...)
2016-12-01 12:34 ` [PATCH 33/39] Annotate hardware config module parameters in drivers/video/ David Howells
@ 2016-12-01 12:34 ` David Howells
2016-12-01 12:58 ` Guenter Roeck
2016-12-01 12:34 ` [PATCH 35/39] Annotate hardware config module parameters in fs/pstore/ David Howells
` (4 subsequent siblings)
38 siblings, 1 reply; 78+ messages in thread
From: David Howells @ 2016-12-01 12:34 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, linux-watchdog, minyard, Zwane Mwaikambo,
linux-security-module, dhowells, Wim Van Sebroeck, keyrings
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/watchdog/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Wim Van Sebroeck <wim@iguana.be>
cc: Zwane Mwaikambo <zwanem@gmail.com>
cc: linux-watchdog@vger.kernel.org
---
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 ++--
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/watchdog/cpu5wdt.c b/drivers/watchdog/cpu5wdt.c
index 6d03e8e30f8b..6c3f78e45c26 100644
--- a/drivers/watchdog/cpu5wdt.c
+++ b/drivers/watchdog/cpu5wdt.c
@@ -289,7 +289,7 @@ MODULE_DESCRIPTION("sma cpu5 watchdog driver");
MODULE_SUPPORTED_DEVICE("sma cpu5 watchdog");
MODULE_LICENSE("GPL");
-module_param(port, int, 0);
+module_param_hw(port, int, ioport, 0);
MODULE_PARM_DESC(port, "base address of watchdog card, default is 0x91");
module_param(verbose, int, 0);
diff --git a/drivers/watchdog/eurotechwdt.c b/drivers/watchdog/eurotechwdt.c
index 23ee53240c4c..38e96712264f 100644
--- a/drivers/watchdog/eurotechwdt.c
+++ b/drivers/watchdog/eurotechwdt.c
@@ -97,9 +97,9 @@ MODULE_PARM_DESC(nowayout,
#define WDT_TIMER_CFG 0xf3
-module_param(io, int, 0);
+module_param_hw(io, int, ioport, 0);
MODULE_PARM_DESC(io, "Eurotech WDT io port (default=0x3f0)");
-module_param(irq, int, 0);
+module_param_hw(irq, int, irq, 0);
MODULE_PARM_DESC(irq, "Eurotech WDT irq (default=10)");
module_param(ev, charp, 0);
MODULE_PARM_DESC(ev, "Eurotech WDT event type (default is `int')");
diff --git a/drivers/watchdog/pc87413_wdt.c b/drivers/watchdog/pc87413_wdt.c
index 9f15dd9435d1..06a892e36a8d 100644
--- a/drivers/watchdog/pc87413_wdt.c
+++ b/drivers/watchdog/pc87413_wdt.c
@@ -579,7 +579,7 @@ MODULE_AUTHOR("Marcus Junker <junker@anduras.de>");
MODULE_DESCRIPTION("PC87413 WDT driver");
MODULE_LICENSE("GPL");
-module_param(io, int, 0);
+module_param_hw(io, int, ioport, 0);
MODULE_PARM_DESC(io, MODNAME " I/O port (default: "
__MODULE_STRING(IO_DEFAULT) ").");
diff --git a/drivers/watchdog/sc1200wdt.c b/drivers/watchdog/sc1200wdt.c
index 131193a7acdf..b34d3d5ba632 100644
--- a/drivers/watchdog/sc1200wdt.c
+++ b/drivers/watchdog/sc1200wdt.c
@@ -88,7 +88,7 @@ MODULE_PARM_DESC(isapnp,
"When set to 0 driver ISA PnP support will be disabled");
#endif
-module_param(io, int, 0);
+module_param_hw(io, int, ioport, 0);
MODULE_PARM_DESC(io, "io port");
module_param(timeout, int, 0);
MODULE_PARM_DESC(timeout, "range is 0-255 minutes, default is 1");
diff --git a/drivers/watchdog/wdt.c b/drivers/watchdog/wdt.c
index e0206b5b7d89..e481fbbc4ae7 100644
--- a/drivers/watchdog/wdt.c
+++ b/drivers/watchdog/wdt.c
@@ -78,9 +78,9 @@ static int irq = 11;
static DEFINE_SPINLOCK(wdt_lock);
-module_param(io, int, 0);
+module_param_hw(io, int, ioport, 0);
MODULE_PARM_DESC(io, "WDT io port (default=0x240)");
-module_param(irq, int, 0);
+module_param_hw(irq, int, irq, 0);
MODULE_PARM_DESC(irq, "WDT irq (default=11)");
/* Support for the Fan Tachometer on the WDT501-P */
^ permalink raw reply related [flat|nested] 78+ messages in thread* Re: [PATCH 34/39] Annotate hardware config module parameters in drivers/watchdog/
2016-12-01 12:34 ` [PATCH 34/39] Annotate hardware config module parameters in drivers/watchdog/ David Howells
@ 2016-12-01 12:58 ` Guenter Roeck
0 siblings, 0 replies; 78+ messages in thread
From: Guenter Roeck @ 2016-12-01 12:58 UTC (permalink / raw)
To: David Howells, linux-kernel
Cc: gnomes, linux-watchdog, minyard, Zwane Mwaikambo,
linux-security-module, Wim Van Sebroeck, keyrings
On 12/01/2016 04:34 AM, David Howells wrote:
> 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/watchdog/.
>
> Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Wim Van Sebroeck <wim@iguana.be>
> cc: Zwane Mwaikambo <zwanem@gmail.com>
> cc: linux-watchdog@vger.kernel.org
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
>
> 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 ++--
> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/watchdog/cpu5wdt.c b/drivers/watchdog/cpu5wdt.c
> index 6d03e8e30f8b..6c3f78e45c26 100644
> --- a/drivers/watchdog/cpu5wdt.c
> +++ b/drivers/watchdog/cpu5wdt.c
> @@ -289,7 +289,7 @@ MODULE_DESCRIPTION("sma cpu5 watchdog driver");
> MODULE_SUPPORTED_DEVICE("sma cpu5 watchdog");
> MODULE_LICENSE("GPL");
>
> -module_param(port, int, 0);
> +module_param_hw(port, int, ioport, 0);
> MODULE_PARM_DESC(port, "base address of watchdog card, default is 0x91");
>
> module_param(verbose, int, 0);
> diff --git a/drivers/watchdog/eurotechwdt.c b/drivers/watchdog/eurotechwdt.c
> index 23ee53240c4c..38e96712264f 100644
> --- a/drivers/watchdog/eurotechwdt.c
> +++ b/drivers/watchdog/eurotechwdt.c
> @@ -97,9 +97,9 @@ MODULE_PARM_DESC(nowayout,
> #define WDT_TIMER_CFG 0xf3
>
>
> -module_param(io, int, 0);
> +module_param_hw(io, int, ioport, 0);
> MODULE_PARM_DESC(io, "Eurotech WDT io port (default=0x3f0)");
> -module_param(irq, int, 0);
> +module_param_hw(irq, int, irq, 0);
> MODULE_PARM_DESC(irq, "Eurotech WDT irq (default=10)");
> module_param(ev, charp, 0);
> MODULE_PARM_DESC(ev, "Eurotech WDT event type (default is `int')");
> diff --git a/drivers/watchdog/pc87413_wdt.c b/drivers/watchdog/pc87413_wdt.c
> index 9f15dd9435d1..06a892e36a8d 100644
> --- a/drivers/watchdog/pc87413_wdt.c
> +++ b/drivers/watchdog/pc87413_wdt.c
> @@ -579,7 +579,7 @@ MODULE_AUTHOR("Marcus Junker <junker@anduras.de>");
> MODULE_DESCRIPTION("PC87413 WDT driver");
> MODULE_LICENSE("GPL");
>
> -module_param(io, int, 0);
> +module_param_hw(io, int, ioport, 0);
> MODULE_PARM_DESC(io, MODNAME " I/O port (default: "
> __MODULE_STRING(IO_DEFAULT) ").");
>
> diff --git a/drivers/watchdog/sc1200wdt.c b/drivers/watchdog/sc1200wdt.c
> index 131193a7acdf..b34d3d5ba632 100644
> --- a/drivers/watchdog/sc1200wdt.c
> +++ b/drivers/watchdog/sc1200wdt.c
> @@ -88,7 +88,7 @@ MODULE_PARM_DESC(isapnp,
> "When set to 0 driver ISA PnP support will be disabled");
> #endif
>
> -module_param(io, int, 0);
> +module_param_hw(io, int, ioport, 0);
> MODULE_PARM_DESC(io, "io port");
> module_param(timeout, int, 0);
> MODULE_PARM_DESC(timeout, "range is 0-255 minutes, default is 1");
> diff --git a/drivers/watchdog/wdt.c b/drivers/watchdog/wdt.c
> index e0206b5b7d89..e481fbbc4ae7 100644
> --- a/drivers/watchdog/wdt.c
> +++ b/drivers/watchdog/wdt.c
> @@ -78,9 +78,9 @@ static int irq = 11;
>
> static DEFINE_SPINLOCK(wdt_lock);
>
> -module_param(io, int, 0);
> +module_param_hw(io, int, ioport, 0);
> MODULE_PARM_DESC(io, "WDT io port (default=0x240)");
> -module_param(irq, int, 0);
> +module_param_hw(irq, int, irq, 0);
> MODULE_PARM_DESC(irq, "WDT irq (default=11)");
>
> /* Support for the Fan Tachometer on the WDT501-P */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 78+ messages in thread
* [PATCH 35/39] Annotate hardware config module parameters in fs/pstore/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (33 preceding siblings ...)
2016-12-01 12:34 ` [PATCH 34/39] Annotate hardware config module parameters in drivers/watchdog/ David Howells
@ 2016-12-01 12:34 ` David Howells
2016-12-01 12:34 ` [PATCH 36/39] Annotate hardware config module parameters in sound/drivers/ David Howells
` (3 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:34 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, Tony Luck, Kees Cook, minyard, Anton Vorontsov, dhowells,
linux-security-module, keyrings, Colin Cross
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 fs/pstore/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Anton Vorontsov <anton@enomsg.org>
cc: Colin Cross <ccross@android.com>
cc: Kees Cook <keescook@chromium.org>
cc: Tony Luck <tony.luck@intel.com>
---
fs/pstore/ram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 6ad831b9d1b8..37e5a265b03d 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -58,7 +58,7 @@ module_param_named(pmsg_size, ramoops_pmsg_size, ulong, 0400);
MODULE_PARM_DESC(pmsg_size, "size of user space message log");
static unsigned long long mem_address;
-module_param(mem_address, ullong, 0400);
+module_param_hw(mem_address, ullong, other, 0400);
MODULE_PARM_DESC(mem_address,
"start of reserved RAM used to store oops/panic logs");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 36/39] Annotate hardware config module parameters in sound/drivers/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (34 preceding siblings ...)
2016-12-01 12:34 ` [PATCH 35/39] Annotate hardware config module parameters in fs/pstore/ David Howells
@ 2016-12-01 12:34 ` David Howells
2016-12-01 12:34 ` [PATCH 37/39] Annotate hardware config module parameters in sound/isa/ David Howells
` (2 subsequent siblings)
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:34 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, alsa-devel, minyard, Takashi Iwai, Jaroslav Kysela,
dhowells, linux-security-module, keyrings
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 sound/drivers/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jaroslav Kysela <perex@perex.cz>
cc: Takashi Iwai <tiwai@suse.com>
cc: alsa-devel@alsa-project.org
---
sound/drivers/mpu401/mpu401.c | 4 ++--
sound/drivers/mtpav.c | 4 ++--
sound/drivers/serial-u16550.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/sound/drivers/mpu401/mpu401.c b/sound/drivers/mpu401/mpu401.c
index fed7e7e2177b..9b86e00d7d95 100644
--- a/sound/drivers/mpu401/mpu401.c
+++ b/sound/drivers/mpu401/mpu401.c
@@ -53,9 +53,9 @@ MODULE_PARM_DESC(enable, "Enable MPU-401 device.");
module_param_array(pnp, bool, NULL, 0444);
MODULE_PARM_DESC(pnp, "PnP detection for MPU-401 device.");
#endif
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for MPU-401 device.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for MPU-401 device.");
module_param_array(uart_enter, bool, NULL, 0444);
MODULE_PARM_DESC(uart_enter, "Issue UART_ENTER command at open.");
diff --git a/sound/drivers/mtpav.c b/sound/drivers/mtpav.c
index 30e8a1d5bc87..c6bab7cf4fe7 100644
--- a/sound/drivers/mtpav.c
+++ b/sound/drivers/mtpav.c
@@ -86,9 +86,9 @@ module_param(index, int, 0444);
MODULE_PARM_DESC(index, "Index value for MotuMTPAV MIDI.");
module_param(id, charp, 0444);
MODULE_PARM_DESC(id, "ID string for MotuMTPAV MIDI.");
-module_param(port, long, 0444);
+module_param_hw(port, long, ioport, 0444);
MODULE_PARM_DESC(port, "Parallel port # for MotuMTPAV MIDI.");
-module_param(irq, int, 0444);
+module_param_hw(irq, int, irq, 0444);
MODULE_PARM_DESC(irq, "Parallel IRQ # for MotuMTPAV MIDI.");
module_param(hwports, int, 0444);
MODULE_PARM_DESC(hwports, "Hardware ports # for MotuMTPAV MIDI.");
diff --git a/sound/drivers/serial-u16550.c b/sound/drivers/serial-u16550.c
index 1927b89e1d1f..04be126fe4e6 100644
--- a/sound/drivers/serial-u16550.c
+++ b/sound/drivers/serial-u16550.c
@@ -84,9 +84,9 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for Serial MIDI.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable UART16550A chip.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for UART16550A chip.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for UART16550A chip.");
module_param_array(speed, int, NULL, 0444);
MODULE_PARM_DESC(speed, "Speed in bauds.");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 37/39] Annotate hardware config module parameters in sound/isa/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (35 preceding siblings ...)
2016-12-01 12:34 ` [PATCH 36/39] Annotate hardware config module parameters in sound/drivers/ David Howells
@ 2016-12-01 12:34 ` David Howells
2016-12-01 12:34 ` [PATCH 38/39] Annotate hardware config module parameters in sound/oss/ David Howells
2016-12-01 12:34 ` [PATCH 39/39] Annotate hardware config module parameters in sound/pci/ David Howells
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:34 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, alsa-devel, minyard, Takashi Iwai, Jaroslav Kysela,
dhowells, linux-security-module, keyrings
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 sound/isa/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jaroslav Kysela <perex@perex.cz>
cc: Takashi Iwai <tiwai@suse.com>
cc: alsa-devel@alsa-project.org
---
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 +++++++++---------
23 files changed, 145 insertions(+), 145 deletions(-)
diff --git a/sound/isa/ad1848/ad1848.c b/sound/isa/ad1848/ad1848.c
index a302d1f8d14f..e739b1c85c25 100644
--- a/sound/isa/ad1848/ad1848.c
+++ b/sound/isa/ad1848/ad1848.c
@@ -55,11 +55,11 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for " CRD_NAME " soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable " CRD_NAME " soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for " CRD_NAME " driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for " CRD_NAME " driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "DMA1 # for " CRD_NAME " driver.");
module_param_array(thinkpad, bool, NULL, 0444);
MODULE_PARM_DESC(thinkpad, "Enable only for the onboard CS4248 of IBM Thinkpad 360/750/755 series.");
diff --git a/sound/isa/adlib.c b/sound/isa/adlib.c
index 8d3060fd7ad7..5fb619eca5c8 100644
--- a/sound/isa/adlib.c
+++ b/sound/isa/adlib.c
@@ -27,7 +27,7 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for " CRD_NAME " soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable " CRD_NAME " soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for " CRD_NAME " driver.");
static int snd_adlib_match(struct device *dev, unsigned int n)
diff --git a/sound/isa/cmi8328.c b/sound/isa/cmi8328.c
index 787475084f46..8e1756c3b9bb 100644
--- a/sound/isa/cmi8328.c
+++ b/sound/isa/cmi8328.c
@@ -51,18 +51,18 @@ MODULE_PARM_DESC(index, "Index value for CMI8328 soundcard.");
module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for CMI8328 soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for CMI8328 driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for CMI8328 driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "DMA1 for CMI8328 driver.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA2 for CMI8328 driver.");
-module_param_array(mpuport, long, NULL, 0444);
+module_param_hw_array(mpuport, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpuport, "MPU-401 port # for CMI8328 driver.");
-module_param_array(mpuirq, int, NULL, 0444);
+module_param_hw_array(mpuirq, int, irq, NULL, 0444);
MODULE_PARM_DESC(mpuirq, "IRQ # for CMI8328 MPU-401 port.");
#ifdef SUPPORT_JOYSTICK
module_param_array(gameport, bool, NULL, 0444);
diff --git a/sound/isa/cmi8330.c b/sound/isa/cmi8330.c
index dfedfd85f205..f64b29ab5cc7 100644
--- a/sound/isa/cmi8330.c
+++ b/sound/isa/cmi8330.c
@@ -95,27 +95,27 @@ module_param_array(isapnp, bool, NULL, 0444);
MODULE_PARM_DESC(isapnp, "PnP detection for specified soundcard.");
#endif
-module_param_array(sbport, long, NULL, 0444);
+module_param_hw_array(sbport, long, ioport, NULL, 0444);
MODULE_PARM_DESC(sbport, "Port # for CMI8330/CMI8329 SB driver.");
-module_param_array(sbirq, int, NULL, 0444);
+module_param_hw_array(sbirq, int, irq, NULL, 0444);
MODULE_PARM_DESC(sbirq, "IRQ # for CMI8330/CMI8329 SB driver.");
-module_param_array(sbdma8, int, NULL, 0444);
+module_param_hw_array(sbdma8, int, dma, NULL, 0444);
MODULE_PARM_DESC(sbdma8, "DMA8 for CMI8330/CMI8329 SB driver.");
-module_param_array(sbdma16, int, NULL, 0444);
+module_param_hw_array(sbdma16, int, dma, NULL, 0444);
MODULE_PARM_DESC(sbdma16, "DMA16 for CMI8330/CMI8329 SB driver.");
-module_param_array(wssport, long, NULL, 0444);
+module_param_hw_array(wssport, long, ioport, NULL, 0444);
MODULE_PARM_DESC(wssport, "Port # for CMI8330/CMI8329 WSS driver.");
-module_param_array(wssirq, int, NULL, 0444);
+module_param_hw_array(wssirq, int, irq, NULL, 0444);
MODULE_PARM_DESC(wssirq, "IRQ # for CMI8330/CMI8329 WSS driver.");
-module_param_array(wssdma, int, NULL, 0444);
+module_param_hw_array(wssdma, int, dma, NULL, 0444);
MODULE_PARM_DESC(wssdma, "DMA for CMI8330/CMI8329 WSS driver.");
-module_param_array(fmport, long, NULL, 0444);
+module_param_hw_array(fmport, long, ioport, NULL, 0444);
MODULE_PARM_DESC(fmport, "FM port # for CMI8330/CMI8329 driver.");
-module_param_array(mpuport, long, NULL, 0444);
+module_param_hw_array(mpuport, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpuport, "MPU-401 port # for CMI8330/CMI8329 driver.");
-module_param_array(mpuirq, int, NULL, 0444);
+module_param_hw_array(mpuirq, int, irq, NULL, 0444);
MODULE_PARM_DESC(mpuirq, "IRQ # for CMI8330/CMI8329 MPU-401 port.");
#ifdef CONFIG_PNP
static int isa_registered;
diff --git a/sound/isa/cs423x/cs4231.c b/sound/isa/cs423x/cs4231.c
index ef7448e9f813..e8edd9017a2f 100644
--- a/sound/isa/cs423x/cs4231.c
+++ b/sound/isa/cs423x/cs4231.c
@@ -55,17 +55,17 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for " CRD_NAME " soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable " CRD_NAME " soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for " CRD_NAME " driver.");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for " CRD_NAME " driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for " CRD_NAME " driver.");
-module_param_array(mpu_irq, int, NULL, 0444);
+module_param_hw_array(mpu_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(mpu_irq, "MPU-401 IRQ # for " CRD_NAME " driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "DMA1 # for " CRD_NAME " driver.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA2 # for " CRD_NAME " driver.");
static int snd_cs4231_match(struct device *dev, unsigned int n)
diff --git a/sound/isa/cs423x/cs4236.c b/sound/isa/cs423x/cs4236.c
index 9d7582c90a95..1f9a3b2be7a1 100644
--- a/sound/isa/cs423x/cs4236.c
+++ b/sound/isa/cs423x/cs4236.c
@@ -98,23 +98,23 @@ MODULE_PARM_DESC(enable, "Enable " IDENT " soundcard.");
module_param_array(isapnp, bool, NULL, 0444);
MODULE_PARM_DESC(isapnp, "ISA PnP detection for specified soundcard.");
#endif
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for " IDENT " driver.");
-module_param_array(cport, long, NULL, 0444);
+module_param_hw_array(cport, long, ioport, NULL, 0444);
MODULE_PARM_DESC(cport, "Control port # for " IDENT " driver.");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for " IDENT " driver.");
-module_param_array(fm_port, long, NULL, 0444);
+module_param_hw_array(fm_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(fm_port, "FM port # for " IDENT " driver.");
-module_param_array(sb_port, long, NULL, 0444);
+module_param_hw_array(sb_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(sb_port, "SB port # for " IDENT " driver (optional).");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for " IDENT " driver.");
-module_param_array(mpu_irq, int, NULL, 0444);
+module_param_hw_array(mpu_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(mpu_irq, "MPU-401 IRQ # for " IDENT " driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "DMA1 # for " IDENT " driver.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA2 # for " IDENT " driver.");
#ifdef CONFIG_PNP
diff --git a/sound/isa/es1688/es1688.c b/sound/isa/es1688/es1688.c
index 1901c2bb6c3b..36320e7f2789 100644
--- a/sound/isa/es1688/es1688.c
+++ b/sound/isa/es1688/es1688.c
@@ -71,17 +71,17 @@ module_param_array(isapnp, bool, NULL, 0444);
MODULE_PARM_DESC(isapnp, "PnP detection for specified soundcard.");
#endif
MODULE_PARM_DESC(enable, "Enable " CRD_NAME " soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for " CRD_NAME " driver.");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for " CRD_NAME " driver.");
-module_param_array(irq, int, NULL, 0444);
-module_param_array(fm_port, long, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
+module_param_hw_array(fm_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(fm_port, "FM port # for ES1688 driver.");
MODULE_PARM_DESC(irq, "IRQ # for " CRD_NAME " driver.");
-module_param_array(mpu_irq, int, NULL, 0444);
+module_param_hw_array(mpu_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(mpu_irq, "MPU-401 IRQ # for " CRD_NAME " driver.");
-module_param_array(dma8, int, NULL, 0444);
+module_param_hw_array(dma8, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma8, "8-bit DMA # for " CRD_NAME " driver.");
#ifdef CONFIG_PNP
diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c
index 5094b62d8f77..0cabe2b8974f 100644
--- a/sound/isa/es18xx.c
+++ b/sound/isa/es18xx.c
@@ -1999,17 +1999,17 @@ MODULE_PARM_DESC(enable, "Enable ES18xx soundcard.");
module_param_array(isapnp, bool, NULL, 0444);
MODULE_PARM_DESC(isapnp, "PnP detection for specified soundcard.");
#endif
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for ES18xx driver.");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for ES18xx driver.");
-module_param_array(fm_port, long, NULL, 0444);
+module_param_hw_array(fm_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(fm_port, "FM port # for ES18xx driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for ES18xx driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "DMA 1 # for ES18xx driver.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA 2 # for ES18xx driver.");
#ifdef CONFIG_PNP
diff --git a/sound/isa/galaxy/galaxy.c b/sound/isa/galaxy/galaxy.c
index 379abe2cbeb2..b9994cc9f5fb 100644
--- a/sound/isa/galaxy/galaxy.c
+++ b/sound/isa/galaxy/galaxy.c
@@ -53,21 +53,21 @@ static int mpu_irq[SNDRV_CARDS] = SNDRV_DEFAULT_IRQ;
static int dma1[SNDRV_CARDS] = SNDRV_DEFAULT_DMA;
static int dma2[SNDRV_CARDS] = SNDRV_DEFAULT_DMA;
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for " CRD_NAME " driver.");
-module_param_array(wss_port, long, NULL, 0444);
+module_param_hw_array(wss_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(wss_port, "WSS port # for " CRD_NAME " driver.");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for " CRD_NAME " driver.");
-module_param_array(fm_port, long, NULL, 0444);
+module_param_hw_array(fm_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(fm_port, "FM port # for " CRD_NAME " driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for " CRD_NAME " driver.");
-module_param_array(mpu_irq, int, NULL, 0444);
+module_param_hw_array(mpu_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(mpu_irq, "MPU-401 IRQ # for " CRD_NAME " driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "Playback DMA # for " CRD_NAME " driver.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "Capture DMA # for " CRD_NAME " driver.");
/*
diff --git a/sound/isa/gus/gusclassic.c b/sound/isa/gus/gusclassic.c
index c169be49ed71..92a997ab1229 100644
--- a/sound/isa/gus/gusclassic.c
+++ b/sound/isa/gus/gusclassic.c
@@ -58,13 +58,13 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for " CRD_NAME " soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable " CRD_NAME " soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for " CRD_NAME " driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for " CRD_NAME " driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "DMA1 # for " CRD_NAME " driver.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA2 # for " CRD_NAME " driver.");
module_param_array(joystick_dac, int, NULL, 0444);
MODULE_PARM_DESC(joystick_dac, "Joystick DAC level 0.59V-4.52V or 0.389V-2.98V for " CRD_NAME " driver.");
diff --git a/sound/isa/gus/gusextreme.c b/sound/isa/gus/gusextreme.c
index 77ac2fd723b4..beb52c0f70ea 100644
--- a/sound/isa/gus/gusextreme.c
+++ b/sound/isa/gus/gusextreme.c
@@ -66,21 +66,21 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for " CRD_NAME " soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable " CRD_NAME " soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for " CRD_NAME " driver.");
-module_param_array(gf1_port, long, NULL, 0444);
+module_param_hw_array(gf1_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(gf1_port, "GF1 port # for " CRD_NAME " driver (optional).");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for " CRD_NAME " driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for " CRD_NAME " driver.");
-module_param_array(mpu_irq, int, NULL, 0444);
+module_param_hw_array(mpu_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(mpu_irq, "MPU-401 IRQ # for " CRD_NAME " driver.");
-module_param_array(gf1_irq, int, NULL, 0444);
+module_param_hw_array(gf1_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(gf1_irq, "GF1 IRQ # for " CRD_NAME " driver.");
-module_param_array(dma8, int, NULL, 0444);
+module_param_hw_array(dma8, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma8, "8-bit DMA # for " CRD_NAME " driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "GF1 DMA # for " CRD_NAME " driver.");
module_param_array(joystick_dac, int, NULL, 0444);
MODULE_PARM_DESC(joystick_dac, "Joystick DAC level 0.59V-4.52V or 0.389V-2.98V for " CRD_NAME " driver.");
diff --git a/sound/isa/gus/gusmax.c b/sound/isa/gus/gusmax.c
index dd88c9d33492..63309a453140 100644
--- a/sound/isa/gus/gusmax.c
+++ b/sound/isa/gus/gusmax.c
@@ -56,13 +56,13 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for GUS MAX soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable GUS MAX soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for GUS MAX driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for GUS MAX driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "DMA1 # for GUS MAX driver.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA2 # for GUS MAX driver.");
module_param_array(joystick_dac, int, NULL, 0444);
MODULE_PARM_DESC(joystick_dac, "Joystick DAC level 0.59V-4.52V or 0.389V-2.98V for GUS MAX driver.");
diff --git a/sound/isa/gus/interwave.c b/sound/isa/gus/interwave.c
index 70d0040484c8..0687b7ef3e53 100644
--- a/sound/isa/gus/interwave.c
+++ b/sound/isa/gus/interwave.c
@@ -92,17 +92,17 @@ MODULE_PARM_DESC(enable, "Enable InterWave soundcard.");
module_param_array(isapnp, bool, NULL, 0444);
MODULE_PARM_DESC(isapnp, "ISA PnP detection for specified soundcard.");
#endif
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for InterWave driver.");
#ifdef SNDRV_STB
-module_param_array(port_tc, long, NULL, 0444);
+module_param_hw_array(port_tc, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port_tc, "Tone control (TEA6330T - i2c bus) port # for InterWave driver.");
#endif
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for InterWave driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "DMA1 # for InterWave driver.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA2 # for InterWave driver.");
module_param_array(joystick_dac, int, NULL, 0444);
MODULE_PARM_DESC(joystick_dac, "Joystick DAC level 0.59V-4.52V or 0.389V-2.98V for InterWave driver.");
diff --git a/sound/isa/msnd/msnd_pinnacle.c b/sound/isa/msnd/msnd_pinnacle.c
index 4c072666115d..ad4897337df5 100644
--- a/sound/isa/msnd/msnd_pinnacle.c
+++ b/sound/isa/msnd/msnd_pinnacle.c
@@ -800,22 +800,22 @@ MODULE_LICENSE("GPL");
MODULE_FIRMWARE(INITCODEFILE);
MODULE_FIRMWARE(PERMCODEFILE);
-module_param_array(io, long, NULL, S_IRUGO);
+module_param_hw_array(io, long, ioport, NULL, S_IRUGO);
MODULE_PARM_DESC(io, "IO port #");
-module_param_array(irq, int, NULL, S_IRUGO);
-module_param_array(mem, long, NULL, S_IRUGO);
+module_param_hw_array(irq, int, irq, NULL, S_IRUGO);
+module_param_hw_array(mem, long, iomem, NULL, S_IRUGO);
module_param_array(write_ndelay, int, NULL, S_IRUGO);
module_param(calibrate_signal, int, S_IRUGO);
#ifndef MSND_CLASSIC
module_param_array(digital, int, NULL, S_IRUGO);
-module_param_array(cfg, long, NULL, S_IRUGO);
+module_param_hw_array(cfg, long, ioport, NULL, S_IRUGO);
module_param_array(reset, int, 0, S_IRUGO);
-module_param_array(mpu_io, long, NULL, S_IRUGO);
-module_param_array(mpu_irq, int, NULL, S_IRUGO);
-module_param_array(ide_io0, long, NULL, S_IRUGO);
-module_param_array(ide_io1, long, NULL, S_IRUGO);
-module_param_array(ide_irq, int, NULL, S_IRUGO);
-module_param_array(joystick_io, long, NULL, S_IRUGO);
+module_param_hw_array(mpu_io, long, ioport, NULL, S_IRUGO);
+module_param_hw_array(mpu_irq, int, irq, NULL, S_IRUGO);
+module_param_hw_array(ide_io0, long, ioport, NULL, S_IRUGO);
+module_param_hw_array(ide_io1, long, ioport, NULL, S_IRUGO);
+module_param_hw_array(ide_irq, int, irq, NULL, S_IRUGO);
+module_param_hw_array(joystick_io, long, ioport, NULL, S_IRUGO);
#endif
diff --git a/sound/isa/opl3sa2.c b/sound/isa/opl3sa2.c
index ae133633a420..4098e3e0353d 100644
--- a/sound/isa/opl3sa2.c
+++ b/sound/isa/opl3sa2.c
@@ -69,21 +69,21 @@ MODULE_PARM_DESC(enable, "Enable OPL3-SA soundcard.");
module_param_array(isapnp, bool, NULL, 0444);
MODULE_PARM_DESC(isapnp, "PnP detection for specified soundcard.");
#endif
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for OPL3-SA driver.");
-module_param_array(sb_port, long, NULL, 0444);
+module_param_hw_array(sb_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(sb_port, "SB port # for OPL3-SA driver.");
-module_param_array(wss_port, long, NULL, 0444);
+module_param_hw_array(wss_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(wss_port, "WSS port # for OPL3-SA driver.");
-module_param_array(fm_port, long, NULL, 0444);
+module_param_hw_array(fm_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(fm_port, "FM port # for OPL3-SA driver.");
-module_param_array(midi_port, long, NULL, 0444);
+module_param_hw_array(midi_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(midi_port, "MIDI port # for OPL3-SA driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for OPL3-SA driver.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "DMA1 # for OPL3-SA driver.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA2 # for OPL3-SA driver.");
module_param_array(opl3sa3_ymode, int, NULL, 0444);
MODULE_PARM_DESC(opl3sa3_ymode, "Speaker size selection for 3D Enhancement mode: Desktop/Large Notebook/Small Notebook/HiFi.");
diff --git a/sound/isa/opti9xx/miro.c b/sound/isa/opti9xx/miro.c
index 3a9067db1a84..bcbff56f060d 100644
--- a/sound/isa/opti9xx/miro.c
+++ b/sound/isa/opti9xx/miro.c
@@ -69,19 +69,19 @@ module_param(index, int, 0444);
MODULE_PARM_DESC(index, "Index value for miro soundcard.");
module_param(id, charp, 0444);
MODULE_PARM_DESC(id, "ID string for miro soundcard.");
-module_param(port, long, 0444);
+module_param_hw(port, long, ioport, 0444);
MODULE_PARM_DESC(port, "WSS port # for miro driver.");
-module_param(mpu_port, long, 0444);
+module_param_hw(mpu_port, long, ioport, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for miro driver.");
-module_param(fm_port, long, 0444);
+module_param_hw(fm_port, long, ioport, 0444);
MODULE_PARM_DESC(fm_port, "FM Port # for miro driver.");
-module_param(irq, int, 0444);
+module_param_hw(irq, int, irq, 0444);
MODULE_PARM_DESC(irq, "WSS irq # for miro driver.");
-module_param(mpu_irq, int, 0444);
+module_param_hw(mpu_irq, int, irq, 0444);
MODULE_PARM_DESC(mpu_irq, "MPU-401 irq # for miro driver.");
-module_param(dma1, int, 0444);
+module_param_hw(dma1, int, dma, 0444);
MODULE_PARM_DESC(dma1, "1st dma # for miro driver.");
-module_param(dma2, int, 0444);
+module_param_hw(dma2, int, dma, 0444);
MODULE_PARM_DESC(dma2, "2nd dma # for miro driver.");
module_param(wss, int, 0444);
MODULE_PARM_DESC(wss, "wss mode");
diff --git a/sound/isa/opti9xx/opti92x-ad1848.c b/sound/isa/opti9xx/opti92x-ad1848.c
index 0a5266003786..ceddb392b1e3 100644
--- a/sound/isa/opti9xx/opti92x-ad1848.c
+++ b/sound/isa/opti9xx/opti92x-ad1848.c
@@ -88,20 +88,20 @@ MODULE_PARM_DESC(id, "ID string for opti9xx based soundcard.");
module_param(isapnp, bool, 0444);
MODULE_PARM_DESC(isapnp, "Enable ISA PnP detection for specified soundcard.");
#endif
-module_param(port, long, 0444);
+module_param_hw(port, long, ioport, 0444);
MODULE_PARM_DESC(port, "WSS port # for opti9xx driver.");
-module_param(mpu_port, long, 0444);
+module_param_hw(mpu_port, long, ioport, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for opti9xx driver.");
-module_param(fm_port, long, 0444);
+module_param_hw(fm_port, long, ioport, 0444);
MODULE_PARM_DESC(fm_port, "FM port # for opti9xx driver.");
-module_param(irq, int, 0444);
+module_param_hw(irq, int, irq, 0444);
MODULE_PARM_DESC(irq, "WSS irq # for opti9xx driver.");
-module_param(mpu_irq, int, 0444);
+module_param_hw(mpu_irq, int, irq, 0444);
MODULE_PARM_DESC(mpu_irq, "MPU-401 irq # for opti9xx driver.");
-module_param(dma1, int, 0444);
+module_param_hw(dma1, int, dma, 0444);
MODULE_PARM_DESC(dma1, "1st dma # for opti9xx driver.");
#if defined(CS4231) || defined(OPTi93X)
-module_param(dma2, int, 0444);
+module_param_hw(dma2, int, dma, 0444);
MODULE_PARM_DESC(dma2, "2nd dma # for opti9xx driver.");
#endif /* CS4231 || OPTi93X */
diff --git a/sound/isa/sb/jazz16.c b/sound/isa/sb/jazz16.c
index 4d909971eedb..bfa0055e1fd6 100644
--- a/sound/isa/sb/jazz16.c
+++ b/sound/isa/sb/jazz16.c
@@ -50,17 +50,17 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for Media Vision Jazz16 based soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable Media Vision Jazz16 based soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for jazz16 driver.");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for jazz16 driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for jazz16 driver.");
-module_param_array(mpu_irq, int, NULL, 0444);
+module_param_hw_array(mpu_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(mpu_irq, "MPU-401 IRQ # for jazz16 driver.");
-module_param_array(dma8, int, NULL, 0444);
+module_param_hw_array(dma8, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma8, "DMA8 # for jazz16 driver.");
-module_param_array(dma16, int, NULL, 0444);
+module_param_hw_array(dma16, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma16, "DMA16 # for jazz16 driver.");
#define SB_JAZZ16_WAKEUP 0xaf
diff --git a/sound/isa/sb/sb16.c b/sound/isa/sb/sb16.c
index 4a7d7c89808f..3b2e4f405ff2 100644
--- a/sound/isa/sb/sb16.c
+++ b/sound/isa/sb/sb16.c
@@ -99,21 +99,21 @@ MODULE_PARM_DESC(enable, "Enable SoundBlaster 16 soundcard.");
module_param_array(isapnp, bool, NULL, 0444);
MODULE_PARM_DESC(isapnp, "PnP detection for specified soundcard.");
#endif
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for SB16 driver.");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for SB16 driver.");
-module_param_array(fm_port, long, NULL, 0444);
+module_param_hw_array(fm_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(fm_port, "FM port # for SB16 PnP driver.");
#ifdef SNDRV_SBAWE_EMU8000
-module_param_array(awe_port, long, NULL, 0444);
+module_param_hw_array(awe_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(awe_port, "AWE port # for SB16 PnP driver.");
#endif
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for SB16 driver.");
-module_param_array(dma8, int, NULL, 0444);
+module_param_hw_array(dma8, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma8, "8-bit DMA # for SB16 driver.");
-module_param_array(dma16, int, NULL, 0444);
+module_param_hw_array(dma16, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma16, "16-bit DMA # for SB16 driver.");
module_param_array(mic_agc, int, NULL, 0444);
MODULE_PARM_DESC(mic_agc, "Mic Auto-Gain-Control switch.");
diff --git a/sound/isa/sb/sb8.c b/sound/isa/sb/sb8.c
index ad42d2364199..d77dcba276b5 100644
--- a/sound/isa/sb/sb8.c
+++ b/sound/isa/sb/sb8.c
@@ -47,11 +47,11 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for Sound Blaster soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable Sound Blaster soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for SB8 driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for SB8 driver.");
-module_param_array(dma8, int, NULL, 0444);
+module_param_hw_array(dma8, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma8, "8-bit DMA # for SB8 driver.");
struct snd_sb8 {
diff --git a/sound/isa/sc6000.c b/sound/isa/sc6000.c
index b61a6633d8f2..c09d9b914efe 100644
--- a/sound/isa/sc6000.c
+++ b/sound/isa/sc6000.c
@@ -64,17 +64,17 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for sc-6000 based soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable sc-6000 based soundcard.");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for sc-6000 driver.");
-module_param_array(mss_port, long, NULL, 0444);
+module_param_hw_array(mss_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mss_port, "MSS Port # for sc-6000 driver.");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port # for sc-6000 driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for sc-6000 driver.");
-module_param_array(mpu_irq, int, NULL, 0444);
+module_param_hw_array(mpu_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(mpu_irq, "MPU-401 IRQ # for sc-6000 driver.");
-module_param_array(dma, int, NULL, 0444);
+module_param_hw_array(dma, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma, "DMA # for sc-6000 driver.");
module_param_array(joystick, bool, NULL, 0444);
MODULE_PARM_DESC(joystick, "Enable gameport.");
diff --git a/sound/isa/sscape.c b/sound/isa/sscape.c
index fdcfa29e2205..54f5758a1bb3 100644
--- a/sound/isa/sscape.c
+++ b/sound/isa/sscape.c
@@ -63,22 +63,22 @@ MODULE_PARM_DESC(index, "Index number for SoundScape soundcard");
module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "Description for SoundScape card");
-module_param_array(port, long, NULL, 0444);
+module_param_hw_array(port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(port, "Port # for SoundScape driver.");
-module_param_array(wss_port, long, NULL, 0444);
+module_param_hw_array(wss_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(wss_port, "WSS Port # for SoundScape driver.");
-module_param_array(irq, int, NULL, 0444);
+module_param_hw_array(irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(irq, "IRQ # for SoundScape driver.");
-module_param_array(mpu_irq, int, NULL, 0444);
+module_param_hw_array(mpu_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(mpu_irq, "MPU401 IRQ # for SoundScape driver.");
-module_param_array(dma, int, NULL, 0444);
+module_param_hw_array(dma, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma, "DMA # for SoundScape driver.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA2 # for SoundScape driver.");
module_param_array(joystick, bool, NULL, 0444);
diff --git a/sound/isa/wavefront/wavefront.c b/sound/isa/wavefront/wavefront.c
index a0987a57c8a9..da4e9a85f0af 100644
--- a/sound/isa/wavefront/wavefront.c
+++ b/sound/isa/wavefront/wavefront.c
@@ -63,23 +63,23 @@ MODULE_PARM_DESC(enable, "Enable WaveFront soundcard.");
module_param_array(isapnp, bool, NULL, 0444);
MODULE_PARM_DESC(isapnp, "ISA PnP detection for WaveFront soundcards.");
#endif
-module_param_array(cs4232_pcm_port, long, NULL, 0444);
+module_param_hw_array(cs4232_pcm_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(cs4232_pcm_port, "Port # for CS4232 PCM interface.");
-module_param_array(cs4232_pcm_irq, int, NULL, 0444);
+module_param_hw_array(cs4232_pcm_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(cs4232_pcm_irq, "IRQ # for CS4232 PCM interface.");
-module_param_array(dma1, int, NULL, 0444);
+module_param_hw_array(dma1, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma1, "DMA1 # for CS4232 PCM interface.");
-module_param_array(dma2, int, NULL, 0444);
+module_param_hw_array(dma2, int, dma, NULL, 0444);
MODULE_PARM_DESC(dma2, "DMA2 # for CS4232 PCM interface.");
-module_param_array(cs4232_mpu_port, long, NULL, 0444);
+module_param_hw_array(cs4232_mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(cs4232_mpu_port, "port # for CS4232 MPU-401 interface.");
-module_param_array(cs4232_mpu_irq, int, NULL, 0444);
+module_param_hw_array(cs4232_mpu_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(cs4232_mpu_irq, "IRQ # for CS4232 MPU-401 interface.");
-module_param_array(ics2115_irq, int, NULL, 0444);
+module_param_hw_array(ics2115_irq, int, irq, NULL, 0444);
MODULE_PARM_DESC(ics2115_irq, "IRQ # for ICS2115.");
-module_param_array(ics2115_port, long, NULL, 0444);
+module_param_hw_array(ics2115_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(ics2115_port, "Port # for ICS2115.");
-module_param_array(fm_port, long, NULL, 0444);
+module_param_hw_array(fm_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(fm_port, "FM port #.");
module_param_array(use_cs4232_midi, bool, NULL, 0444);
MODULE_PARM_DESC(use_cs4232_midi, "Use CS4232 MPU-401 interface (inaccessibly located inside your computer)");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 38/39] Annotate hardware config module parameters in sound/oss/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (36 preceding siblings ...)
2016-12-01 12:34 ` [PATCH 37/39] Annotate hardware config module parameters in sound/isa/ David Howells
@ 2016-12-01 12:34 ` David Howells
2016-12-01 12:34 ` [PATCH 39/39] Annotate hardware config module parameters in sound/pci/ David Howells
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:34 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, alsa-devel, minyard, Andrew Veliath, Takashi Iwai,
Jaroslav Kysela, dhowells, linux-security-module, keyrings,
Riccardo Facchetti
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 sound/oss/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jaroslav Kysela <perex@perex.cz>
cc: Takashi Iwai <tiwai@suse.com>
cc: Riccardo Facchetti <fizban@tin.it>
cc: Andrew Veliath <andrewtv@usa.net>
cc: alsa-devel@alsa-project.org
---
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 ++++----
12 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/sound/oss/ad1848.c b/sound/oss/ad1848.c
index 6368e5c7d0ba..6cae59c4e3c4 100644
--- a/sound/oss/ad1848.c
+++ b/sound/oss/ad1848.c
@@ -2810,10 +2810,10 @@ static int __initdata dma = -1;
static int __initdata dma2 = -1;
static int __initdata type = 0;
-module_param(io, int, 0); /* I/O for a raw AD1848 card */
-module_param(irq, int, 0); /* IRQ to use */
-module_param(dma, int, 0); /* First DMA channel */
-module_param(dma2, int, 0); /* Second DMA channel */
+module_param_hw(io, int, ioport, 0); /* I/O for a raw AD1848 card */
+module_param_hw(irq, int, irq, 0); /* IRQ to use */
+module_param_hw(dma, int, dma, 0); /* First DMA channel */
+module_param_hw(dma2, int, dma, 0); /* Second DMA channel */
module_param(type, int, 0); /* Card type */
module_param(deskpro_xl, bool, 0); /* Special magic for Deskpro XL boxen */
module_param(deskpro_m, bool, 0); /* Special magic for Deskpro M box */
diff --git a/sound/oss/aedsp16.c b/sound/oss/aedsp16.c
index bb477d5c8528..f058ed6bdb69 100644
--- a/sound/oss/aedsp16.c
+++ b/sound/oss/aedsp16.c
@@ -1303,17 +1303,17 @@ static int __initdata mpu_irq = -1;
static int __initdata mss_base = -1;
static int __initdata mpu_base = -1;
-module_param(io, int, 0);
+module_param_hw(io, int, ioport, 0);
MODULE_PARM_DESC(io, "I/O base address (0x220 0x240)");
-module_param(irq, int, 0);
+module_param_hw(irq, int, irq, 0);
MODULE_PARM_DESC(irq, "IRQ line (5 7 9 10 11)");
-module_param(dma, int, 0);
+module_param_hw(dma, int, dma, 0);
MODULE_PARM_DESC(dma, "dma line (0 1 3)");
-module_param(mpu_irq, int, 0);
+module_param_hw(mpu_irq, int, irq, 0);
MODULE_PARM_DESC(mpu_irq, "MPU-401 IRQ line (5 7 9 10 0)");
-module_param(mss_base, int, 0);
+module_param_hw(mss_base, int, ioport, 0);
MODULE_PARM_DESC(mss_base, "MSS emulation I/O base address (0x530 0xE80)");
-module_param(mpu_base, int, 0);
+module_param_hw(mpu_base, int, ioport, 0);
MODULE_PARM_DESC(mpu_base,"MPU-401 I/O base address (0x300 0x310 0x320 0x330)");
MODULE_AUTHOR("Riccardo Facchetti <fizban@tin.it>");
MODULE_DESCRIPTION("Audio Excel DSP 16 Driver Version " VERSION);
diff --git a/sound/oss/mpu401.c b/sound/oss/mpu401.c
index 862735005b43..20e8fa46f647 100644
--- a/sound/oss/mpu401.c
+++ b/sound/oss/mpu401.c
@@ -1748,8 +1748,8 @@ static struct address_info cfg;
static int io = -1;
static int irq = -1;
-module_param(irq, int, 0);
-module_param(io, int, 0);
+module_param_hw(irq, int, irq, 0);
+module_param_hw(io, int, ioport, 0);
static int __init init_mpu401(void)
{
diff --git a/sound/oss/msnd_pinnacle.c b/sound/oss/msnd_pinnacle.c
index a8bb4a06ba6f..8e5221d15066 100644
--- a/sound/oss/msnd_pinnacle.c
+++ b/sound/oss/msnd_pinnacle.c
@@ -1725,22 +1725,22 @@ static int
calibrate_signal __initdata = CONFIG_MSND_CALSIGNAL;
#endif /* MODULE */
-module_param (io, int, 0);
-module_param (irq, int, 0);
-module_param (mem, int, 0);
+module_param_hw (io, int, ioport, 0);
+module_param_hw (irq, int, irq, 0);
+module_param_hw (mem, int, iomem, 0);
module_param (write_ndelay, int, 0);
module_param (fifosize, int, 0);
module_param (calibrate_signal, int, 0);
#ifndef MSND_CLASSIC
module_param (digital, bool, 0);
-module_param (cfg, int, 0);
+module_param_hw (cfg, int, ioport, 0);
module_param (reset, int, 0);
-module_param (mpu_io, int, 0);
-module_param (mpu_irq, int, 0);
-module_param (ide_io0, int, 0);
-module_param (ide_io1, int, 0);
-module_param (ide_irq, int, 0);
-module_param (joystick_io, int, 0);
+module_param_hw (mpu_io, int, ioport, 0);
+module_param_hw (mpu_irq, int, irq, 0);
+module_param_hw (ide_io0, int, ioport, 0);
+module_param_hw (ide_io1, int, ioport, 0);
+module_param_hw (ide_irq, int, irq, 0);
+module_param_hw (joystick_io, int, ioport, 0);
#endif
static int __init msnd_init(void)
diff --git a/sound/oss/opl3.c b/sound/oss/opl3.c
index b6d19adf8f41..f0f5b5be6314 100644
--- a/sound/oss/opl3.c
+++ b/sound/oss/opl3.c
@@ -1200,7 +1200,7 @@ static int me;
static int io = -1;
-module_param(io, int, 0);
+module_param_hw(io, int, ioport, 0);
static int __init init_opl3 (void)
{
diff --git a/sound/oss/pas2_card.c b/sound/oss/pas2_card.c
index b07954a79536..769fca692d2a 100644
--- a/sound/oss/pas2_card.c
+++ b/sound/oss/pas2_card.c
@@ -383,15 +383,15 @@ static int __initdata sb_irq = -1;
static int __initdata sb_dma = -1;
static int __initdata sb_dma16 = -1;
-module_param(io, int, 0);
-module_param(irq, int, 0);
-module_param(dma, int, 0);
-module_param(dma16, int, 0);
-
-module_param(sb_io, int, 0);
-module_param(sb_irq, int, 0);
-module_param(sb_dma, int, 0);
-module_param(sb_dma16, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
+module_param_hw(dma, int, dma, 0);
+module_param_hw(dma16, int, dma, 0);
+
+module_param_hw(sb_io, int, ioport, 0);
+module_param_hw(sb_irq, int, irq, 0);
+module_param_hw(sb_dma, int, dma, 0);
+module_param_hw(sb_dma16, int, dma, 0);
module_param(joystick, bool, 0);
module_param(symphony, bool, 0);
diff --git a/sound/oss/pss.c b/sound/oss/pss.c
index 81314f9e2ccb..33c3a442e162 100644
--- a/sound/oss/pss.c
+++ b/sound/oss/pss.c
@@ -1139,19 +1139,19 @@ static bool pss_no_sound = 0; /* Just configure non-sound components */
static bool pss_keep_settings = 1; /* Keep hardware settings at module exit */
static char *pss_firmware = "/etc/sound/pss_synth";
-module_param(pss_io, int, 0);
+module_param_hw(pss_io, int, ioport, 0);
MODULE_PARM_DESC(pss_io, "Set i/o base of PSS card (probably 0x220 or 0x240)");
-module_param(mss_io, int, 0);
+module_param_hw(mss_io, int, ioport, 0);
MODULE_PARM_DESC(mss_io, "Set WSS (audio) i/o base (0x530, 0x604, 0xE80, 0xF40, or other. Address must end in 0 or 4 and must be from 0x100 to 0xFF4)");
-module_param(mss_irq, int, 0);
+module_param_hw(mss_irq, int, irq, 0);
MODULE_PARM_DESC(mss_irq, "Set WSS (audio) IRQ (3, 5, 7, 9, 10, 11, 12)");
-module_param(mss_dma, int, 0);
+module_param_hw(mss_dma, int, dma, 0);
MODULE_PARM_DESC(mss_dma, "Set WSS (audio) DMA (0, 1, 3)");
-module_param(mpu_io, int, 0);
+module_param_hw(mpu_io, int, ioport, 0);
MODULE_PARM_DESC(mpu_io, "Set MIDI i/o base (0x330 or other. Address must be on 4 location boundaries and must be from 0x100 to 0xFFC)");
-module_param(mpu_irq, int, 0);
+module_param_hw(mpu_irq, int, irq, 0);
MODULE_PARM_DESC(mpu_irq, "Set MIDI IRQ (3, 5, 7, 9, 10, 11, 12)");
-module_param(pss_cdrom_port, int, 0);
+module_param_hw(pss_cdrom_port, int, ioport, 0);
MODULE_PARM_DESC(pss_cdrom_port, "Set the PSS CDROM port i/o base (0x340 or other)");
module_param(pss_enable_joystick, bool, 0);
MODULE_PARM_DESC(pss_enable_joystick, "Enables the PSS joystick port (1 to enable, 0 to disable)");
diff --git a/sound/oss/sb_card.c b/sound/oss/sb_card.c
index fb5d7250de38..2a92cfe6cfe9 100644
--- a/sound/oss/sb_card.c
+++ b/sound/oss/sb_card.c
@@ -61,15 +61,15 @@ static int __initdata uart401 = 0;
static int __initdata pnp = 0;
#endif
-module_param(io, int, 000);
+module_param_hw(io, int, ioport, 000);
MODULE_PARM_DESC(io, "Soundblaster i/o base address (0x220,0x240,0x260,0x280)");
-module_param(irq, int, 000);
+module_param_hw(irq, int, irq, 000);
MODULE_PARM_DESC(irq, "IRQ (5,7,9,10)");
-module_param(dma, int, 000);
+module_param_hw(dma, int, dma, 000);
MODULE_PARM_DESC(dma, "8-bit DMA channel (0,1,3)");
-module_param(dma16, int, 000);
+module_param_hw(dma16, int, dma, 000);
MODULE_PARM_DESC(dma16, "16-bit DMA channel (5,6,7)");
-module_param(mpu_io, int, 000);
+module_param_hw(mpu_io, int, ioport, 000);
MODULE_PARM_DESC(mpu_io, "MPU base address");
module_param(type, int, 000);
MODULE_PARM_DESC(type, "You can set this to specific card type (doesn't " \
diff --git a/sound/oss/trix.c b/sound/oss/trix.c
index 3c494dc93b93..a57bc635d758 100644
--- a/sound/oss/trix.c
+++ b/sound/oss/trix.c
@@ -413,15 +413,15 @@ static int __initdata sb_irq = -1;
static int __initdata mpu_io = -1;
static int __initdata mpu_irq = -1;
-module_param(io, int, 0);
-module_param(irq, int, 0);
-module_param(dma, int, 0);
-module_param(dma2, int, 0);
-module_param(sb_io, int, 0);
-module_param(sb_dma, int, 0);
-module_param(sb_irq, int, 0);
-module_param(mpu_io, int, 0);
-module_param(mpu_irq, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
+module_param_hw(dma, int, dma, 0);
+module_param_hw(dma2, int, dma, 0);
+module_param_hw(sb_io, int, ioport, 0);
+module_param_hw(sb_dma, int, dma, 0);
+module_param_hw(sb_irq, int, irq, 0);
+module_param_hw(mpu_io, int, ioport, 0);
+module_param_hw(mpu_irq, int, irq, 0);
module_param(joystick, bool, 0);
static int __init init_trix(void)
diff --git a/sound/oss/uart401.c b/sound/oss/uart401.c
index dae4d4344407..83dcc85b8688 100644
--- a/sound/oss/uart401.c
+++ b/sound/oss/uart401.c
@@ -429,8 +429,8 @@ static struct address_info cfg_mpu;
static int io = -1;
static int irq = -1;
-module_param(io, int, 0444);
-module_param(irq, int, 0444);
+module_param_hw(io, int, ioport, 0444);
+module_param_hw(irq, int, irq, 0444);
static int __init init_uart401(void)
diff --git a/sound/oss/uart6850.c b/sound/oss/uart6850.c
index 1079133dd6ab..eda32d7eddbd 100644
--- a/sound/oss/uart6850.c
+++ b/sound/oss/uart6850.c
@@ -315,8 +315,8 @@ static struct address_info cfg_mpu;
static int __initdata io = -1;
static int __initdata irq = -1;
-module_param(io, int, 0);
-module_param(irq, int, 0);
+module_param_hw(io, int, ioport, 0);
+module_param_hw(irq, int, irq, 0);
static int __init init_uart6850(void)
{
diff --git a/sound/oss/waveartist.c b/sound/oss/waveartist.c
index 0b8d0de87273..4f0c3a232e41 100644
--- a/sound/oss/waveartist.c
+++ b/sound/oss/waveartist.c
@@ -2036,8 +2036,8 @@ __setup("waveartist=", setup_waveartist);
#endif
MODULE_DESCRIPTION("Rockwell WaveArtist RWA-010 sound driver");
-module_param(io, int, 0); /* IO base */
-module_param(irq, int, 0); /* IRQ */
-module_param(dma, int, 0); /* DMA */
-module_param(dma2, int, 0); /* DMA2 */
+module_param_hw(io, int, ioport, 0); /* IO base */
+module_param_hw(irq, int, irq, 0); /* IRQ */
+module_param_hw(dma, int, dma, 0); /* DMA */
+module_param_hw(dma2, int, dma, 0); /* DMA2 */
MODULE_LICENSE("GPL");
^ permalink raw reply related [flat|nested] 78+ messages in thread* [PATCH 39/39] Annotate hardware config module parameters in sound/pci/
2016-12-01 12:29 [PATCH 00/39] Annotate hw config module params for future lockdown David Howells
` (37 preceding siblings ...)
2016-12-01 12:34 ` [PATCH 38/39] Annotate hardware config module parameters in sound/oss/ David Howells
@ 2016-12-01 12:34 ` David Howells
38 siblings, 0 replies; 78+ messages in thread
From: David Howells @ 2016-12-01 12:34 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, alsa-devel, minyard, Takashi Iwai, Jaroslav Kysela,
dhowells, linux-security-module, keyrings
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 sound/pci/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jaroslav Kysela <perex@perex.cz>
cc: Takashi Iwai <tiwai@suse.com>
cc: alsa-devel@alsa-project.org
---
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 +++---
7 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/sound/pci/als4000.c b/sound/pci/als4000.c
index edabe1371660..e17d1742057d 100644
--- a/sound/pci/als4000.c
+++ b/sound/pci/als4000.c
@@ -102,7 +102,7 @@ MODULE_PARM_DESC(id, "ID string for ALS4000 soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable ALS4000 soundcard.");
#ifdef SUPPORT_JOYSTICK
-module_param_array(joystick_port, int, NULL, 0444);
+module_param_hw_array(joystick_port, int, ioport, NULL, 0444);
MODULE_PARM_DESC(joystick_port, "Joystick port address for ALS4000 soundcard. (0 = disabled)");
#endif
diff --git a/sound/pci/cmipci.c b/sound/pci/cmipci.c
index 73f593526b2d..8a217752a5f8 100644
--- a/sound/pci/cmipci.c
+++ b/sound/pci/cmipci.c
@@ -68,14 +68,14 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for C-Media PCI soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable C-Media PCI soundcard.");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port.");
-module_param_array(fm_port, long, NULL, 0444);
+module_param_hw_array(fm_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(fm_port, "FM port.");
module_param_array(soft_ac3, bool, NULL, 0444);
MODULE_PARM_DESC(soft_ac3, "Software-conversion of raw SPDIF packets (model 033 only).");
#ifdef SUPPORT_JOYSTICK
-module_param_array(joystick_port, int, NULL, 0444);
+module_param_hw_array(joystick_port, int, ioport, NULL, 0444);
MODULE_PARM_DESC(joystick_port, "Joystick port address.");
#endif
diff --git a/sound/pci/ens1370.c b/sound/pci/ens1370.c
index 7e760fed0728..cdb3637a2bb1 100644
--- a/sound/pci/ens1370.c
+++ b/sound/pci/ens1370.c
@@ -106,7 +106,7 @@ module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable Ensoniq AudioPCI soundcard.");
#ifdef SUPPORT_JOYSTICK
#ifdef CHIP1371
-module_param_array(joystick_port, int, NULL, 0444);
+module_param_hw_array(joystick_port, int, ioport, NULL, 0444);
MODULE_PARM_DESC(joystick_port, "Joystick port address.");
#else
module_param_array(joystick, bool, NULL, 0444);
diff --git a/sound/pci/riptide/riptide.c b/sound/pci/riptide/riptide.c
index ada5f01d479c..8b39f03f2144 100644
--- a/sound/pci/riptide/riptide.c
+++ b/sound/pci/riptide/riptide.c
@@ -137,12 +137,12 @@ MODULE_PARM_DESC(id, "ID string for Riptide soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable Riptide soundcard.");
#ifdef SUPPORT_JOYSTICK
-module_param_array(joystick_port, int, NULL, 0444);
+module_param_hw_array(joystick_port, int, ioport, NULL, 0444);
MODULE_PARM_DESC(joystick_port, "Joystick port # for Riptide soundcard.");
#endif
-module_param_array(mpu_port, int, NULL, 0444);
+module_param_hw_array(mpu_port, int, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU401 port # for Riptide driver.");
-module_param_array(opl3_port, int, NULL, 0444);
+module_param_hw_array(opl3_port, int, ioport, NULL, 0444);
MODULE_PARM_DESC(opl3_port, "OPL3 port # for Riptide driver.");
/*
diff --git a/sound/pci/sonicvibes.c b/sound/pci/sonicvibes.c
index e1a13870bb80..01ace45d9405 100644
--- a/sound/pci/sonicvibes.c
+++ b/sound/pci/sonicvibes.c
@@ -66,7 +66,7 @@ module_param_array(reverb, bool, NULL, 0444);
MODULE_PARM_DESC(reverb, "Enable reverb (SRAM is present) for S3 SonicVibes soundcard.");
module_param_array(mge, bool, NULL, 0444);
MODULE_PARM_DESC(mge, "MIC Gain Enable for S3 SonicVibes soundcard.");
-module_param(dmaio, uint, 0444);
+module_param_hw(dmaio, uint, ioport, 0444);
MODULE_PARM_DESC(dmaio, "DDMA i/o base address for S3 SonicVibes soundcard.");
/*
diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c
index 38a17b4342a6..2dc8f1a86aa2 100644
--- a/sound/pci/via82xx.c
+++ b/sound/pci/via82xx.c
@@ -92,7 +92,7 @@ module_param(index, int, 0444);
MODULE_PARM_DESC(index, "Index value for VIA 82xx bridge.");
module_param(id, charp, 0444);
MODULE_PARM_DESC(id, "ID string for VIA 82xx bridge.");
-module_param(mpu_port, long, 0444);
+module_param_hw(mpu_port, long, ioport, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 port. (VT82C686x only)");
#ifdef SUPPORT_JOYSTICK
module_param(joystick, bool, 0444);
diff --git a/sound/pci/ymfpci/ymfpci.c b/sound/pci/ymfpci/ymfpci.c
index 812e27a1bcbc..4faf3e1ed06a 100644
--- a/sound/pci/ymfpci/ymfpci.c
+++ b/sound/pci/ymfpci/ymfpci.c
@@ -55,12 +55,12 @@ module_param_array(id, charp, NULL, 0444);
MODULE_PARM_DESC(id, "ID string for the Yamaha DS-1 PCI soundcard.");
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, "Enable Yamaha DS-1 soundcard.");
-module_param_array(mpu_port, long, NULL, 0444);
+module_param_hw_array(mpu_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(mpu_port, "MPU-401 Port.");
-module_param_array(fm_port, long, NULL, 0444);
+module_param_hw_array(fm_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(fm_port, "FM OPL-3 Port.");
#ifdef SUPPORT_JOYSTICK
-module_param_array(joystick_port, long, NULL, 0444);
+module_param_hw_array(joystick_port, long, ioport, NULL, 0444);
MODULE_PARM_DESC(joystick_port, "Joystick port address");
#endif
module_param_array(rear_switch, bool, NULL, 0444);
^ permalink raw reply related [flat|nested] 78+ messages in thread