diff mbox

[06/38] Annotate hardware config module parameters in drivers/clocksource/

Message ID 149141145858.29162.13072730133817038218.stgit@warthog.procyon.org.uk (mailing list archive)
State New, archived
Headers show

Commit Message

David Howells April 5, 2017, 4:57 p.m. UTC
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: Alan Cox <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(-)


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

Comments

Thomas Gleixner April 14, 2017, 6:25 p.m. UTC | #1
On Wed, 5 Apr 2017, David Howells wrote:

$subject == crap

> 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/.

Sigh.

> Suggested-by: Alan Cox <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.");

I'm not sure about this. AFAIR the parameter is required to work on
anything else than some arbitrary hardware which has it mapped to 0.

Cc'ed people who might know.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Howells April 14, 2017, 10:59 p.m. UTC | #2
Thomas Gleixner <tglx@linutronix.de> wrote:

> > -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.");
> 
> I'm not sure about this. AFAIR the parameter is required to work on
> anything else than some arbitrary hardware which has it mapped to 0.

Should it then be set through in-kernel platform initialisation since the
AMD Geode is an embedded chip?

Btw, is it possible to use IRQ grants to prevent a device that has limited IRQ
options from being drivable?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thomas Gleixner April 15, 2017, 5:49 a.m. UTC | #3
On Fri, 14 Apr 2017, David Howells wrote:
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > > -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.");
> > 
> > I'm not sure about this. AFAIR the parameter is required to work on
> > anything else than some arbitrary hardware which has it mapped to 0.
> 
> Should it then be set through in-kernel platform initialisation since the
> AMD Geode is an embedded chip?

I think so. 

> Btw, is it possible to use IRQ grants to prevent a device that has limited IRQ
> options from being drivable?

What do you mean with 'IRQ grants' ?

Thanks

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Howells April 15, 2017, 5:51 a.m. UTC | #4
Thomas Gleixner <tglx@linutronix.de> wrote:

> > Btw, is it possible to use IRQ grants to prevent a device that has limited
> > IRQ options from being drivable?
> 
> What do you mean with 'IRQ grants' ?

request_irq().

David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thomas Gleixner April 15, 2017, 9:54 a.m. UTC | #5
On Sat, 15 Apr 2017, David Howells wrote:
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > > Btw, is it possible to use IRQ grants to prevent a device that has limited
> > > IRQ options from being drivable?
> > 
> > What do you mean with 'IRQ grants' ?
> 
> request_irq().

I still can't parse the sentence above. If request_irq() fails the device
initialization fails. If you request the wrong irq then request_irq() might
succeed but the device won't work.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Howells April 18, 2017, 12:43 p.m. UTC | #6
Thomas Gleixner <tglx@linutronix.de> wrote:

> > > > Btw, is it possible to use IRQ grants to prevent a device that has limited
> > > > IRQ options from being drivable?
> > > 
> > > What do you mean with 'IRQ grants' ?
> > 
> > request_irq().
> 
> I still can't parse the sentence above. If request_irq() fails the device
> initialization fails. If you request the wrong irq then request_irq() might
> succeed but the device won't work.

I was talking about having using a driver to make request_irq() grant an irq
to that driver so that another driver can't bind to its device because all its
irq options are taken and the irqs can't be shared.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thomas Gleixner April 18, 2017, 12:54 p.m. UTC | #7
On Tue, 18 Apr 2017, David Howells wrote:
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > > > > Btw, is it possible to use IRQ grants to prevent a device that has limited
> > > > > IRQ options from being drivable?
> > > > 
> > > > What do you mean with 'IRQ grants' ?
> > > 
> > > request_irq().
> > 
> > I still can't parse the sentence above. If request_irq() fails the device
> > initialization fails. If you request the wrong irq then request_irq() might
> > succeed but the device won't work.
> 
> I was talking about having using a driver to make request_irq() grant an irq
> to that driver so that another driver can't bind to its device because all its
> irq options are taken and the irqs can't be shared.

Yes. That's possible.

init_driver1()
	request_irq(X, flags,.....);

init_driver2()
	request_irq(X, flags,.....);

The second driver can fail, when flags are not matching. That might be
disagreement about SHARED or the trigger type, i.e. egde vs. level.

Thanks,

	tglx



       
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jens Rottmann April 18, 2017, 4:24 p.m. UTC | #8
Hi,

On 04/14/2017 20:25, Thomas Gleixner wrote:
>>  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.");
> 
> I'm not sure about this. AFAIR the parameter is required to work on
> anything else than some arbitrary hardware which has it mapped to 0.

Parameter defaults to 0, which means:
1. autodetect (=keep IRQ BIOS has set up)
2. if that fails use CONFIG_CS5535_MFGPT_DEFAULT_IRQ
(see drivers/misc/cs5535-mfgpt.c: cs5535_mfgpt_set_irq())

Autodetect works fine for our (ex-LiPPERT, now ADLINK) COTS boards:
Linux auto-uses IRQ chosen in BIOS Setup. Wouldn't know about other
companies, of course, but (2.) means parameter can be avoided via make
menuconfig.

On 04/15/2017 00:59, David Howells wrote:
> Should it then be set through in-kernel platform initialisation
> since the AMD Geode is an embedded chip?

Don't know what each and every of our COTS customers is doing, but I'm
not aware of anyone having written a platform driver. AFAIK many are
running pretty standard distros, e.g. Debian. I happen to have booted
Slackware with a vanilla kernel only a few hours ago.

Cheers,
Jens
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jens Rottmann April 18, 2017, 4:34 p.m. UTC | #9
On 04/15/2017 00:59, David Howells wrote:
> When the kernel is running in secure boot mode [...] prevent
> access by means of configuring driver modules

I may easily be wrong, but doesn't secure boot require EFI? Do secure
boot capable systems with old CS5535/36 even exist?

Thanks,
Jens
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Howells April 19, 2017, 3:29 p.m. UTC | #10
Jens Rottmann <Jens.Rottmann@ADLINKtech.com> wrote:

> > When the kernel is running in secure boot mode [...] prevent
> > access by means of configuring driver modules
> 
> I may easily be wrong, but doesn't secure boot require EFI?

For the patches I have, yes.  It could feasibly be done by some other
mechanism, though I don't know that such an alternative exists.

> Do secure boot capable systems with old CS5535/36 even exist?

No idea.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Howells April 19, 2017, 3:33 p.m. UTC | #11
Hi Thomas,

Thomas Gleixner <tglx@linutronix.de> wrote:

> > --- 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.");
> 
> I'm not sure about this. AFAIR the parameter is required to work on
> anything else than some arbitrary hardware which has it mapped to 0.
> 
> Cc'ed people who might know.

Given what Jens said:

	Parameter defaults to 0, which means:
	1. autodetect (=keep IRQ BIOS has set up)
	2. if that fails use CONFIG_CS5535_MFGPT_DEFAULT_IRQ
	(see drivers/misc/cs5535-mfgpt.c: cs5535_mfgpt_set_irq())

	Autodetect works fine for our (ex-LiPPERT, now ADLINK) COTS boards:
	Linux auto-uses IRQ chosen in BIOS Setup. Wouldn't know about other
	companies, of course, but (2.) means parameter can be avoided via make
	menuconfig.

are you willing to okay this?

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

Patch

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.");
 
 /*