diff mbox

[07/39] Annotate hardware config module parameters in drivers/cpufreq/

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

Commit Message

David Howells Dec. 1, 2016, 12:30 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/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(-)


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

Rafael J. Wysocki Dec. 1, 2016, 2:02 p.m. UTC | #1
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
--
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 Dec. 1, 2016, 2:19 p.m. UTC | #2
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
--
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
Rafael J. Wysocki Dec. 1, 2016, 2:21 p.m. UTC | #3
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

--
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/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);