Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1534016 > unrolled thread
| Started by | David Howells <dhowells@redhat.com> |
|---|---|
| First post | 2016-12-01 13:30 +0100 |
| Last post | 2016-12-01 13:40 +0100 |
| Articles | 20 on this page of 77 — 19 participants |
Back to article view | Back to linux.kernel
[PATCH 00/39] Annotate hw config module params for future lockdown David Howells <dhowells@redhat.com> - 2016-12-01 13:30 +0100
[PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) David Howells <dhowells@redhat.com> - 2016-12-01 13:30 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) Greg KH <gregkh@linuxfoundation.org> - 2016-12-01 16:10 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) David Howells <dhowells@redhat.com> - 2016-12-01 17:10 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-12-05 22:20 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) Greg KH <gregkh@linuxfoundation.org> - 2016-12-06 08:20 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) David Howells <dhowells@redhat.com> - 2016-12-06 11:50 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) Greg KH <gregkh@linuxfoundation.org> - 2016-12-06 12:00 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) Matthew Garrett <mjg59@srcf.ucam.org> - 2016-12-02 04:50 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) Greg KH <gregkh@linuxfoundation.org> - 2016-12-02 08:00 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) Matthew Garrett <mjg59@srcf.ucam.org> - 2016-12-02 08:20 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-12-05 22:30 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) David Howells <dhowells@redhat.com> - 2016-12-02 16:00 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) Greg KH <gregkh@linuxfoundation.org> - 2016-12-05 16:50 +0100
Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) David Howells <dhowells@redhat.com> - 2016-12-06 12:00 +0100
[PATCH 20/39] Annotate hardware config module parameters in drivers/net/hamradio/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 34/39] Annotate hardware config module parameters in drivers/watchdog/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 34/39] Annotate hardware config module parameters in drivers/watchdog/ Guenter Roeck <linux@roeck-us.net> - 2016-12-01 14:00 +0100
[PATCH 03/39] Annotate hardware config module parameters in drivers/char/ipmi/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 03/39] Annotate hardware config module parameters in drivers/char/ipmi/ Corey Minyard <minyard@acm.org> - 2016-12-01 14:20 +0100
[PATCH 05/39] Annotate hardware config module parameters in drivers/char/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 28/39] Annotate hardware config module parameters in drivers/staging/i4l/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/ "Rafael J. Wysocki" <rafael@kernel.org> - 2016-12-01 15:10 +0100
Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/ David Howells <dhowells@redhat.com> - 2016-12-01 15:20 +0100
Re: [PATCH 07/39] Annotate hardware config module parameters in drivers/cpufreq/ "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-12-01 15:30 +0100
[PATCH 39/39] Annotate hardware config module parameters in sound/pci/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 35/39] Annotate hardware config module parameters in fs/pstore/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 11/39] Annotate hardware config module parameters in drivers/input/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 11/39] Annotate hardware config module parameters in drivers/input/ Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-12-03 20:00 +0100
[PATCH 21/39] Annotate hardware config module parameters in drivers/net/irda/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 31/39] Annotate hardware config module parameters in drivers/staging/vme/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 33/39] Annotate hardware config module parameters in drivers/video/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 04/39] Annotate hardware config module parameters in drivers/char/mwave/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 38/39] Annotate hardware config module parameters in sound/oss/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 06/39] Annotate hardware config module parameters in drivers/clocksource/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 12/39] Annotate hardware config module parameters in drivers/isdn/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/ Kalle Valo <kvalo@codeaurora.org> - 2016-12-02 06:10 +0100
Re: [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/ David Howells <dhowells@redhat.com> - 2016-12-07 14:50 +0100
[PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/ Mauro Carvalho Chehab <mchehab@s-opensource.com> - 2016-12-01 16:00 +0100
Re: [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/ David Howells <dhowells@redhat.com> - 2016-12-01 16:10 +0100
Re: [PATCH 29/39] Annotate hardware config module parameters in drivers/staging/media/ Mauro Carvalho Chehab <mchehab@s-opensource.com> - 2016-12-01 16:20 +0100
[PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/ Jean Delvare <jdelvare@suse.de> - 2016-12-01 14:50 +0100
Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/ David Howells <dhowells@redhat.com> - 2016-12-01 15:20 +0100
Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/ Jean Delvare <jdelvare@suse.de> - 2016-12-01 17:10 +0100
Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/ One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-12-05 22:20 +0100
[PATCH 19/39] Annotate hardware config module parameters in drivers/net/ethernet/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 18/39] Annotate hardware config module parameters in drivers/net/can/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 18/39] Annotate hardware config module parameters in drivers/net/can/ Marc Kleine-Budde <mkl@pengutronix.de> - 2016-12-01 14:10 +0100
[PATCH 25/39] Annotate hardware config module parameters in drivers/pci/hotplug/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 25/39] Annotate hardware config module parameters in drivers/pci/hotplug/ Bjorn Helgaas <helgaas@kernel.org> - 2016-12-07 19:40 +0100
[PATCH 27/39] Annotate hardware config module parameters in drivers/scsi/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 27/39] Annotate hardware config module parameters in drivers/scsi/ Finn Thain <fthain@telegraphics.com.au> - 2016-12-01 23:10 +0100
[PATCH 26/39] Annotate hardware config module parameters in drivers/pcmcia/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 08/39] Annotate hardware config module parameters in drivers/gpio/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 08/39] Annotate hardware config module parameters in drivers/gpio/ William Breathitt Gray <vilhelm.gray@gmail.com> - 2016-12-01 14:50 +0100
Re: [PATCH 08/39] Annotate hardware config module parameters in drivers/gpio/ Linus Walleij <linus.walleij@linaro.org> - 2016-12-02 14:00 +0100
[PATCH 32/39] Annotate hardware config module parameters in drivers/tty/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 32/39] Annotate hardware config module parameters in drivers/tty/ Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-12-01 16:10 +0100
[PATCH 13/39] Annotate hardware config module parameters in drivers/media/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 36/39] Annotate hardware config module parameters in sound/drivers/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 17/39] Annotate hardware config module parameters in drivers/net/arcnet/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 24/39] Annotate hardware config module parameters in drivers/parport/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 15/39] Annotate hardware config module parameters in drivers/mmc/host/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 02/39] Annotate hardware config module parameters in arch/x86/mm/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 16/39] Annotate hardware config module parameters in drivers/net/appletalk/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 37/39] Annotate hardware config module parameters in sound/isa/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 30/39] Annotate hardware config module parameters in drivers/staging/speakup/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 22/39] Annotate hardware config module parameters in drivers/net/wan/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
[PATCH 10/39] Annotate hardware config module parameters in drivers/iio/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Re: [PATCH 10/39] Annotate hardware config module parameters in drivers/iio/ William Breathitt Gray <vilhelm.gray@gmail.com> - 2016-12-01 15:00 +0100
Re: [PATCH 10/39] Annotate hardware config module parameters in drivers/iio/ Jonathan Cameron <jic23@kernel.org> - 2016-12-03 15:40 +0100
Re: [PATCH 10/39] Annotate hardware config module parameters in drivers/iio/ David Howells <dhowells@redhat.com> - 2016-12-07 14:50 +0100
[PATCH 14/39] Annotate hardware config module parameters in drivers/misc/ David Howells <dhowells@redhat.com> - 2016-12-01 13:40 +0100
Page 1 of 4 [1] 2 3 4 Next page →
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-12-01 13:30 +0100 |
| Subject | [PATCH 00/39] Annotate hw config module params for future lockdown |
| Message-ID | <sJyEV-3Or-7@gated-at.bofh.it> |
Here's a set of patches that annotate module parameters that configure
hardware resources including ioports, iomem addresses, irq lines and dma
channels.
This will be used in a future patch to prohibit the use of such module
parameters so that hardware can't be abused to gain access to the running
kernel image.
This is done by changing:
module_param(n, t, p)
module_param_named(n, v, t, p)
module_param_array(n, t, m, p)
to:
module_param_hw(n, t, hwtype, p)
module_param_hw_named(n, v, t, hwtype, p)
module_param_hw_array(n, t, hwtype, m, p)
where hwtype specifies the type of the resource being configured.
Note that the hwtype is compile checked, but not currently stored (the
lockdown code probably won't require it). It is, however, there for future
use.
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=hwparam
at tag:
hwparam-20161201
David
---
David Howells (39):
Annotate module params that specify hardware parameters (eg. ioport)
Annotate hardware config module parameters in arch/x86/mm/
Annotate hardware config module parameters in drivers/char/ipmi/
Annotate hardware config module parameters in drivers/char/mwave/
Annotate hardware config module parameters in drivers/char/
Annotate hardware config module parameters in drivers/clocksource/
Annotate hardware config module parameters in drivers/cpufreq/
Annotate hardware config module parameters in drivers/gpio/
Annotate hardware config module parameters in drivers/i2c/
Annotate hardware config module parameters in drivers/iio/
Annotate hardware config module parameters in drivers/input/
Annotate hardware config module parameters in drivers/isdn/
Annotate hardware config module parameters in drivers/media/
Annotate hardware config module parameters in drivers/misc/
Annotate hardware config module parameters in drivers/mmc/host/
Annotate hardware config module parameters in drivers/net/appletalk/
Annotate hardware config module parameters in drivers/net/arcnet/
Annotate hardware config module parameters in drivers/net/can/
Annotate hardware config module parameters in drivers/net/ethernet/
Annotate hardware config module parameters in drivers/net/hamradio/
Annotate hardware config module parameters in drivers/net/irda/
Annotate hardware config module parameters in drivers/net/wan/
Annotate hardware config module parameters in drivers/net/wireless/
Annotate hardware config module parameters in drivers/parport/
Annotate hardware config module parameters in drivers/pci/hotplug/
Annotate hardware config module parameters in drivers/pcmcia/
Annotate hardware config module parameters in drivers/scsi/
Annotate hardware config module parameters in drivers/staging/i4l/
Annotate hardware config module parameters in drivers/staging/media/
Annotate hardware config module parameters in drivers/staging/speakup/
Annotate hardware config module parameters in drivers/staging/vme/
Annotate hardware config module parameters in drivers/tty/
Annotate hardware config module parameters in drivers/video/
Annotate hardware config module parameters in drivers/watchdog/
Annotate hardware config module parameters in fs/pstore/
Annotate hardware config module parameters in sound/drivers/
Annotate hardware config module parameters in sound/isa/
Annotate hardware config module parameters in sound/oss/
Annotate hardware config module parameters in sound/pci/
arch/x86/mm/testmmiotrace.c | 2 -
drivers/char/applicom.c | 4 +-
drivers/char/ipmi/ipmi_si_intf.c | 14 +++---
drivers/char/mwave/mwavedd.c | 8 ++-
drivers/clocksource/cs5535-clockevt.c | 2 -
drivers/cpufreq/speedstep-smi.c | 2 -
drivers/gpio/gpio-104-dio-48e.c | 4 +-
drivers/gpio/gpio-104-idi-48.c | 4 +-
drivers/gpio/gpio-104-idio-16.c | 4 +-
drivers/gpio/gpio-gpio-mm.c | 2 -
drivers/gpio/gpio-ws16c48.c | 4 +-
drivers/i2c/busses/i2c-elektor.c | 6 +-
drivers/i2c/busses/i2c-parport-light.c | 4 +-
drivers/i2c/busses/i2c-pca-isa.c | 4 +-
drivers/i2c/busses/scx200_acb.c | 2 -
drivers/iio/adc/stx104.c | 2 -
drivers/iio/dac/cio-dac.c | 2 -
drivers/input/mouse/inport.c | 2 -
drivers/input/mouse/logibm.c | 2 -
drivers/input/touchscreen/mk712.c | 4 +-
drivers/isdn/hardware/avm/b1isa.c | 4 +-
drivers/isdn/hardware/avm/t1isa.c | 4 +-
drivers/isdn/hisax/config.c | 10 ++--
drivers/media/pci/zoran/zoran_card.c | 2 -
drivers/misc/dummy-irq.c | 2 -
drivers/mmc/host/wbsd.c | 8 ++-
drivers/net/appletalk/cops.c | 6 +-
drivers/net/appletalk/ltpc.c | 6 +-
drivers/net/arcnet/com20020-isa.c | 4 +-
drivers/net/arcnet/com90io.c | 4 +-
drivers/net/arcnet/com90xx.c | 4 +-
drivers/net/can/cc770/cc770_isa.c | 8 ++-
drivers/net/can/sja1000/sja1000_isa.c | 8 ++-
drivers/net/ethernet/3com/3c509.c | 2 -
drivers/net/ethernet/3com/3c59x.c | 4 +-
drivers/net/ethernet/8390/ne.c | 4 +-
drivers/net/ethernet/8390/smc-ultra.c | 4 +-
drivers/net/ethernet/8390/wd.c | 8 ++-
drivers/net/ethernet/amd/lance.c | 6 +-
drivers/net/ethernet/amd/ni65.c | 6 +-
drivers/net/ethernet/cirrus/cs89x0.c | 6 +-
drivers/net/ethernet/dec/tulip/de4x5.c | 2 -
drivers/net/ethernet/hp/hp100.c | 2 -
drivers/net/ethernet/realtek/atp.c | 4 +-
drivers/net/ethernet/smsc/smc9194.c | 4 +-
drivers/net/hamradio/baycom_epp.c | 2 -
drivers/net/hamradio/baycom_par.c | 2 -
drivers/net/hamradio/baycom_ser_fdx.c | 4 +-
drivers/net/hamradio/baycom_ser_hdx.c | 4 +-
drivers/net/hamradio/dmascc.c | 2 -
drivers/net/irda/ali-ircc.c | 6 +-
drivers/net/irda/nsc-ircc.c | 6 +-
drivers/net/irda/smsc-ircc2.c | 10 ++--
drivers/net/irda/w83977af_ir.c | 4 +-
drivers/net/wan/cosa.c | 6 +-
drivers/net/wan/hostess_sv11.c | 6 +-
drivers/net/wan/sbni.c | 4 +-
drivers/net/wan/sealevel.c | 8 ++-
drivers/net/wireless/cisco/airo.c | 4 +-
drivers/parport/parport_pc.c | 8 ++-
drivers/pci/hotplug/cpcihp_generic.c | 2 -
drivers/pcmcia/i82365.c | 8 ++-
drivers/pcmcia/tcic.c | 8 ++-
drivers/scsi/aha152x.c | 4 +-
drivers/scsi/aha1542.c | 2 -
drivers/scsi/g_NCR5380.c | 8 ++-
drivers/scsi/gdth.c | 2 -
drivers/scsi/qlogicfas.c | 4 +-
drivers/staging/i4l/act2000/module.c | 6 +-
drivers/staging/i4l/icn/icn.c | 4 +-
drivers/staging/i4l/pcbit/module.c | 4 +-
drivers/staging/media/lirc/lirc_parallel.c | 4 +-
drivers/staging/media/lirc/lirc_serial.c | 10 ++--
drivers/staging/media/lirc/lirc_sir.c | 4 +-
drivers/staging/speakup/speakup_acntpc.c | 2 -
drivers/staging/speakup/speakup_dtlk.c | 2 -
drivers/staging/speakup/speakup_keypc.c | 2 -
drivers/staging/vme/devices/vme_pio2_core.c | 8 ++-
drivers/tty/cyclades.c | 4 +-
drivers/tty/moxa.c | 2 -
drivers/tty/mxser.c | 2 -
drivers/tty/rocket.c | 10 ++--
drivers/tty/serial/8250/8250_core.c | 4 +-
drivers/tty/synclink.c | 6 +-
drivers/video/fbdev/arcfb.c | 8 ++-
drivers/video/fbdev/n411.c | 6 +-
drivers/watchdog/cpu5wdt.c | 2 -
drivers/watchdog/eurotechwdt.c | 4 +-
drivers/watchdog/pc87413_wdt.c | 2 -
drivers/watchdog/sc1200wdt.c | 2 -
drivers/watchdog/wdt.c | 4 +-
fs/pstore/ram.c | 2 -
include/linux/moduleparam.h | 65 +++++++++++++++++++++++++++
sound/drivers/mpu401/mpu401.c | 4 +-
sound/drivers/mtpav.c | 4 +-
sound/drivers/serial-u16550.c | 4 +-
sound/isa/ad1848/ad1848.c | 6 +-
sound/isa/adlib.c | 2 -
sound/isa/cmi8328.c | 12 ++---
sound/isa/cmi8330.c | 20 ++++----
sound/isa/cs423x/cs4231.c | 12 ++---
sound/isa/cs423x/cs4236.c | 18 ++++---
sound/isa/es1688/es1688.c | 12 ++---
sound/isa/es18xx.c | 12 ++---
sound/isa/galaxy/galaxy.c | 16 +++----
sound/isa/gus/gusclassic.c | 8 ++-
sound/isa/gus/gusextreme.c | 16 +++----
sound/isa/gus/gusmax.c | 8 ++-
sound/isa/gus/interwave.c | 10 ++--
sound/isa/msnd/msnd_pinnacle.c | 20 ++++----
sound/isa/opl3sa2.c | 16 +++----
sound/isa/opti9xx/miro.c | 14 +++---
sound/isa/opti9xx/opti92x-ad1848.c | 14 +++---
sound/isa/sb/jazz16.c | 12 ++---
sound/isa/sb/sb16.c | 14 +++---
sound/isa/sb/sb8.c | 6 +-
sound/isa/sc6000.c | 12 ++---
sound/isa/sscape.c | 12 ++---
sound/isa/wavefront/wavefront.c | 18 ++++---
sound/oss/ad1848.c | 8 ++-
sound/oss/aedsp16.c | 12 ++---
sound/oss/mpu401.c | 4 +-
sound/oss/msnd_pinnacle.c | 20 ++++----
sound/oss/opl3.c | 2 -
sound/oss/pas2_card.c | 18 ++++---
sound/oss/pss.c | 14 +++---
sound/oss/sb_card.c | 10 ++--
sound/oss/trix.c | 18 ++++---
sound/oss/uart401.c | 4 +-
sound/oss/uart6850.c | 4 +-
sound/oss/waveartist.c | 8 ++-
sound/pci/als4000.c | 2 -
sound/pci/cmipci.c | 6 +-
sound/pci/ens1370.c | 2 -
sound/pci/riptide/riptide.c | 6 +-
sound/pci/sonicvibes.c | 2 -
sound/pci/via82xx.c | 2 -
sound/pci/ymfpci/ymfpci.c | 6 +-
138 files changed, 498 insertions(+), 435 deletions(-)
[toc] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-12-01 13:30 +0100 |
| Subject | [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sJyEV-3Or-25@gated-at.bofh.it> |
| In reply to | #1534016 |
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;
[toc] | [prev] | [next] | [standalone]
| From | Greg KH <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-12-01 16:10 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sJB9L-5sv-5@gated-at.bofh.it> |
| In reply to | #1534018 |
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...
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-12-01 17:10 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sJC5P-6gw-29@gated-at.bofh.it> |
| In reply to | #1534175 |
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
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-12-05 22:20 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sL8Q1-1iP-7@gated-at.bofh.it> |
| In reply to | #1534242 |
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
[toc] | [prev] | [next] | [standalone]
| From | Greg KH <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-12-06 08:20 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sLicG-7oX-21@gated-at.bofh.it> |
| In reply to | #1536422 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-12-06 11:50 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sLltU-UD-19@gated-at.bofh.it> |
| In reply to | #1536712 |
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
[toc] | [prev] | [next] | [standalone]
| From | Greg KH <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-12-06 12:00 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sLlDA-XN-17@gated-at.bofh.it> |
| In reply to | #1536846 |
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
[toc] | [prev] | [next] | [standalone]
| From | Matthew Garrett <mjg59@srcf.ucam.org> |
|---|---|
| Date | 2016-12-02 04:50 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sJN1f-6yi-1@gated-at.bofh.it> |
| In reply to | #1534175 |
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
[toc] | [prev] | [next] | [standalone]
| From | Greg KH <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-12-02 08:00 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sJPZ8-5Y-7@gated-at.bofh.it> |
| In reply to | #1534648 |
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
[toc] | [prev] | [next] | [standalone]
| From | Matthew Garrett <mjg59@srcf.ucam.org> |
|---|---|
| Date | 2016-12-02 08:20 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sJQit-uF-13@gated-at.bofh.it> |
| In reply to | #1534700 |
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
[toc] | [prev] | [next] | [standalone]
| From | One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> |
|---|---|
| Date | 2016-12-05 22:30 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sL8ZH-1lT-1@gated-at.bofh.it> |
| In reply to | #1534706 |
> 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
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-12-02 16:00 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sJXtE-5bN-39@gated-at.bofh.it> |
| In reply to | #1534700 |
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
[toc] | [prev] | [next] | [standalone]
| From | Greg KH <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2016-12-05 16:50 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sL3GG-6lh-9@gated-at.bofh.it> |
| In reply to | #1535005 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-12-06 12:00 +0100 |
| Subject | Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport) |
| Message-ID | <sLlDz-XN-7@gated-at.bofh.it> |
| In reply to | #1536183 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-12-01 13:40 +0100 |
| Subject | [PATCH 20/39] Annotate hardware config module parameters in drivers/net/hamradio/ |
| Message-ID | <sJyOB-3S3-1@gated-at.bofh.it> |
| In reply to | #1534016 |
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)
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-12-01 13:40 +0100 |
| Subject | [PATCH 34/39] Annotate hardware config module parameters in drivers/watchdog/ |
| Message-ID | <sJyOB-3S3-3@gated-at.bofh.it> |
| In reply to | #1534016 |
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 */
[toc] | [prev] | [next] | [standalone]
| From | Guenter Roeck <linux@roeck-us.net> |
|---|---|
| Date | 2016-12-01 14:00 +0100 |
| Subject | Re: [PATCH 34/39] Annotate hardware config module parameters in drivers/watchdog/ |
| Message-ID | <sJz7Y-3YF-27@gated-at.bofh.it> |
| In reply to | #1534021 |
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
>
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-12-01 13:40 +0100 |
| Subject | [PATCH 03/39] Annotate hardware config module parameters in drivers/char/ipmi/ |
| Message-ID | <sJyOB-3S3-13@gated-at.bofh.it> |
| In reply to | #1534016 |
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"
[toc] | [prev] | [next] | [standalone]
| From | Corey Minyard <minyard@acm.org> |
|---|---|
| Date | 2016-12-01 14:20 +0100 |
| Subject | Re: [PATCH 03/39] Annotate hardware config module parameters in drivers/char/ipmi/ |
| Message-ID | <sJzrj-4k9-5@gated-at.bofh.it> |
| In reply to | #1534022 |
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" >
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | linux.kernel
csiph-web