Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/
On Thursday, December 01, 2016 02:19:29 PM David Howells wrote: > Rafael J. Wysockiwrote: > > > 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
Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/
On Thursday, December 01, 2016 02:19:29 PM David Howells wrote: > Rafael J. Wysocki 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
Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/
Rafael J. Wysockiwrote: > 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
Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/
Rafael J. Wysocki 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
Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/
On Thu, Dec 1, 2016 at 1:30 PM, David Howellswrote: > 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 > Signed-off-by: David Howells > cc: "Rafael J. Wysocki" > cc: Viresh Kumar > cc: linux...@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(_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
Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/
On Thu, Dec 1, 2016 at 1:30 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/cpufreq/. > > Suggested-by: One Thousand Gnomes > Signed-off-by: David Howells > cc: "Rafael J. Wysocki" > cc: Viresh Kumar > cc: linux...@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(_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