- 30 Jun, 2020 40 commits
-
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/scsi/. Suggested-by:
Alan Cox <gnomes@lxorguk.ukuu.org.uk> Signed-off-by:
David Howells <dhowells@redhat.com> cc: "Juergen E. Fischer" <fischer@norbit.de> cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com> cc: "Martin K. Petersen" <martin.petersen@oracle.com> cc: Dario Ballabio <ballabio_dario@emc.com> cc: Finn Thain <fthain@telegraphics.com.au> cc: Michael Schmitz <schmitzmic@gmail.com> cc: Achim Leubner <achim_leubner@adaptec.com> cc: linux-scsi@vger.kernel.org (backported from commit 88f06b76) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Andrea Righi <andrea.righi@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/pcmcia/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/pci/hotplug/. Suggested-by:
Bjorn Helgaas <bhelgaas@google.com> cc: Scott Murray <scott@spiteful.org> cc: linux-pci@vger.kernel.org (cherry picked from commit 01b961b7) Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/parport/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/net/wireless/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/net/wan/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/net/irda/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 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:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/net/ethernet/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/net/can/. Suggested-by:
Marc Kleine-Budde <mkl@pengutronix.de> cc: Wolfgang Grandegger <wg@grandegger.com> cc: linux-can@vger.kernel.org cc: netdev@vger.kernel.org (cherry picked from commit e43f2c52) Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/net/arcnet/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/net/appletalk/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/mmc/host/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/misc/. Suggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Arnd Bergmann <arnd@arndb.de> (cherry picked from commit 4f1927dc) Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/media/. Suggested-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> cc: mjpeg-users@lists.sourceforge.net cc: linux-media@vger.kernel.org (backported from commit 5a8fc6a3) Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/isdn/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/input/. Suggested-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> cc: linux-input@vger.kernel.org (cherry picked from commit f6b12d04) Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/i2c/. Suggested-by:
Wolfram Sang <wsa@the-dreams.de> Acked-by:
Jean Delvare <jdelvare@suse.de> cc: linux-i2c@vger.kernel.org (backported from commit c78babcc) Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/gpio/. Suggested-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> cc: Alexandre Courbot <gnurou@gmail.com> cc: linux-gpio@vger.kernel.org (backported from commit d759f906) Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 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:
"Rafael J. Wysocki" <rjw@rjwysocki.net> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> cc: linux-pm@vger.kernel.org (cherry picked from commit 40059ec6) Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 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/. [Note: With regard to cs5535-clockevt.c, Thomas Gleixner asked whether the timer_irq parameter is required for the driver to work on anything other than arbitrary hardware which has it mapped to 0. Jens Rottmann replied that the 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()) Jens further noted that there may not be any systems that have CS5535/36 devices that support EFI and secure boot.] Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/char/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/char/mwave/. Suggested-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 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:
Corey Minyard <cminyard@mvista.com> cc: openipmi-developer@lists.sourceforge.net (cherry picked from commit 684497bf) Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in arch/x86/mm/. [Note: With respect to testmmiotrace, an additional patch will be added separately that makes the module refuse to load if the kernel is locked down.] Suggested-by:
Steven Rostedt <rostedt@goodmis.org> cc: Ingo Molnar <mingo@kernel.org> cc: Thomas Gleixner <tglx@linutronix.de> cc: "H. Peter Anvin" <hpa@zytor.com> cc: x86@kernel.org cc: linux-kernel@vger.kernel.org cc: nouveau@lists.freedesktop.org (cherry picked from commit 3c2e2e68) Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 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:
-
Matthew Garrett authored
BugLink: https://bugs.launchpad.net/bugs/1884159 Allowing users to read and write to core kernel memory makes it possible for the kernel to be subverted, avoiding module loading restrictions, and also to steal cryptographic information. Disallow /dev/mem and /dev/kmem from being opened this when the kernel has been locked down to prevent this. Also disallow /dev/port from being opened to prevent raw ioport access and thus DMA from being used to accomplish the same thing. Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by:
"Lee, Chun-Yi" <jlee@suse.com> (backported from commit 2eada4c7af2d4e9522a47523d2a5106d96271cd9 git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by:
-
Seth Forshee authored
BugLink: https://bugs.launchpad.net/bugs/1884159 This reverts commit cc223b88 to backport an updated version. Signed-off-by:
-
Seth Forshee authored
BugLink: https://bugs.launchpad.net/bugs/1884159 This reverts commit 517d6c3a to backport an updated version. Signed-off-by:
-
David Howells authored
BugLink: https://bugs.launchpad.net/bugs/1884159 The testmmiotrace module shouldn't be permitted when the kernel is locked down as it can be used to arbitrarily read and write MMIO space. Suggested-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by: David Howells <dhowells@redhat.com cc: Thomas Gleixner <tglx@linutronix.de> cc: Steven Rostedt <rostedt@goodmis.org> cc: Ingo Molnar <mingo@kernel.org> cc: "H. Peter Anvin" <hpa@zytor.com> cc: x86@kernel.org (backported from commit 64ce4fc1ef16d4dd818eca47701f803e58444ab2 git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by:
-
Linn Crosetto authored
BugLink: https://bugs.launchpad.net/bugs/1884159 >From the kernel documentation (initrd_table_override.txt): If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to override nearly any ACPI table provided by the BIOS with an instrumented, modified one. When lockdown is enabled, the kernel should disallow any unauthenticated changes to kernel space. ACPI tables contain code invoked by the kernel, so do not allow ACPI tables to be overridden if the kernel is locked down. Signed-off-by:
Linn Crosetto <lcrosetto@gmail.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> cc: linux-acpi@vger.kernel.org Signed-off-by:
James Morris <jmorris@namei.org> (backported from commit 6ea0e815) Signed-off-by:
-
Kamal Mostafa authored
BugLink: https://bugs.launchpad.net/bugs/1883918 Ignore: yes Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1883918Signed-off-by:
-
Oleg Nesterov authored
BugLink: https://bugs.launchpad.net/bugs/1883918 commit 013b2deb upstream. uprobe_write_opcode() must not cross page boundary; prepare_uprobe() relies on arch_uprobe_analyze_insn() which should validate "vaddr" but some architectures (csky, s390, and sparc) don't do this. We can remove the BUG_ON() check in prepare_uprobe() and validate the offset early in __uprobe_register(). The new IS_ALIGNED() check matches the alignment check in arch_prepare_kprobe() on supported architectures, so I think that all insns must be aligned to UPROBE_SWBP_INSN_SIZE. Another problem is __update_ref_ctr() which was wrong from the very beginning, it can read/write outside of kmap'ed page unless "vaddr" is aligned to sizeof(short), __uprobe_register() should check this too. Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Suggested-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
Srikar Dronamraju <srikar@linux.vnet.ibm.com> Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Tested-by:
Sven Schnelle <svens@linux.ibm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Mathieu Othacehe authored
BugLink: https://bugs.launchpad.net/bugs/1883918 [ Upstream commit 18dfb532 ] The bytes returned by the i2c reading need to be swapped unconditionally. Otherwise, on be16 platforms, an incorrect value will be returned. Taking the slow path via next merge window as its been around a while and we have a patch set dependent on this which would be held up. Fixes: 62a1efb9 ("iio: add vcnl4000 combined ALS and proximity sensor") Signed-off-by:
Mathieu Othacehe <m.othacehe@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Josh Poimboeuf authored
BugLink: https://bugs.launchpad.net/bugs/1883918 commit 3798cc4d upstream Make the docs match the code. Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
-
Mark Gross authored
BugLink: https://bugs.launchpad.net/bugs/1883918 commit 7222a1b5 upstream Add documentation for the SRBDS vulnerability and its mitigation. [ bp: Massage. jpoimboe: sysfs table strings. ] Signed-off-by:
Mark Gross <mgross@linux.intel.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Tony Luck <tony.luck@intel.com> Reviewed-by:
-
Jia Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1883918 commit b399151c upstream. x86_mask is a confusing name which is hard to associate with the processor's stepping. Additionally, correct an indent issue in lib/cpu.c. [ Backport by Mark Gross to simplify the SRBDS backport ] Signed-off-by:
Jia Zhang <qianyue.zj@alibaba-inc.com> [ Updated it to more recent kernels. ] Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bp@alien8.de Cc: tony.luck@intel.com Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Pascal Terjan authored
BugLink: https://bugs.launchpad.net/bugs/1883918 commit 15ea976a upstream. The value in shared headers was fixed 9 years ago in commit 8d661f1e ("ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro") and while looking at using shared headers for other duplicated constants I noticed this driver uses the old value. The macros are also defined twice in this file so I am deleting the second definition. Signed-off-by:
Pascal Terjan <pterjan@google.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200523211247.23262-1-pterjan@google.comSigned-off-by:
-
Dmitry Torokhov authored
BugLink: https://bugs.launchpad.net/bugs/1883918 commit b86dab05 upstream. When k_ascii is invoked several times in a row there is a potential for signed integer overflow: UBSAN: Undefined behaviour in drivers/tty/vt/keyboard.c:888:19 signed integer overflow: 10 * 1111111111 cannot be represented in type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 ubsan_epilogue+0xe/0x30 lib/ubsan.c:154 handle_overflow+0xdc/0xf0 lib/ubsan.c:184 __ubsan_handle_mul_overflow+0x2a/0x40 lib/ubsan.c:205 k_ascii+0xbf/0xd0 drivers/tty/vt/keyboard.c:888 kbd_keycode drivers/tty/vt/keyboard.c:1477 [inline] kbd_event+0x888/0x3be0 drivers/tty/vt/keyboard.c:1495 While it can be worked around by using check_mul_overflow()/ check_add_overflow(), it is better to introduce a separate flag to signal that number pad is being used to compose a symbol, and change type of the accumulator from signed to unsigned, thus avoiding undefined behavior when it overflows. Reported-by:
Kyungtae Kim <kt0755@gmail.com> Signed-off-by:
-
