user/sven/linux.git/drivers/base/firmware_loader, branch v5.18.3

firmware_loader: use kernel credentials when reading firmware

2022-05-06T08:00:03Z

Device drivers may decide to not load firmware when probed to avoid slowing down the boot process should the firmware filesystem not be available yet. In this case, the firmware loading request may be done when a device file associated with the driver is first accessed. The credentials of the userspace process accessing the device file may be used to validate access to the firmware files requested by the driver. Ensure that the kernel assumes the responsibility of reading the firmware. This was observed on Android for a graphic driver loading their firmware when the device file (e.g. /dev/mali0) was first opened by userspace (i.e. surfaceflinger). The security context of surfaceflinger was used to validate the access to the firmware file (e.g. /vendor/firmware/mali.bin). Previously, Android configurations were not setting up the firmware_class.path command line argument and were relying on the userspace fallback mechanism. In this case, the security context of the userspace daemon (i.e. ueventd) was consistently used to read firmware files. More Android devices are now found to set firmware_class.path which gives the kernel the opportunity to read the firmware directly (via kernel_read_file_from_path_initns). In this scenario, the current process credentials were used, even if unrelated to the loading of the firmware file. Signed-off-by: Thiébaud Weksteen Cc: # 5.10 Reviewed-by: Paul Moore Acked-by: Luis Chamberlain Link: https://lore.kernel.org/r/20220502004952.3970800-1-tweek@google.com Signed-off-by: Greg Kroah-Hartman

firmware_loader: EXTRA_FIRMWARE does not support compressed files

2022-02-25T11:14:42Z

Document in the firmware loader Kconfig help text that firmware image file compression is not supported for builtin EXTRA_FIRMWARE files so that someone does not waste time trying that. Cc: Luis Chamberlain Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Acked-by: Luis Chamberlain Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20220214222311.9758-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman

firmware_loader: move firmware sysctl to its own files

2022-01-22T06:33:35Z

Patch series "sysctl: 3rd set of kernel/sysctl cleanups", v2. This is the third set of patches to help address cleaning the kitchen seink in kernel/sysctl.c and to move sysctls away to where they are actually implemented / used. This patch (of 8): kernel/sysctl.c is a kitchen sink where everyone leaves their dirty dishes, this makes it very difficult to maintain. To help with this maintenance let's start by moving sysctls to places where they actually belong. The proc sysctl maintainers do not want to know what sysctl knobs you wish to add for your own piece of code, we just care about the core logic. So move the firmware configuration sysctl table to the only place where it is used, and make it clear that if sysctls are disabled this is not used. [akpm@linux-foundation.org: export register_firmware_config_sysctl and unregister_firmware_config_sysctl to modules] [akpm@linux-foundation.org: use EXPORT_SYMBOL_NS_GPL instead] [sfr@canb.auug.org.au: fix that so it compiles] Link: https://lkml.kernel.org/r/20211201160626.401d828d@canb.auug.org.au [mcgrof@kernel.org: major commit log update to justify the move] Link: https://lkml.kernel.org/r/20211124231435.1445213-1-mcgrof@kernel.org Link: https://lkml.kernel.org/r/20211124231435.1445213-2-mcgrof@kernel.org Signed-off-by: Xiaoming Ni Signed-off-by: Luis Chamberlain Signed-off-by: Stephen Rothwell Cc: Kees Cook Cc: Iurii Zaikin Cc: Eric Biederman Cc: Stephen Kitt Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: "Theodore Ts'o" Cc: Al Viro Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Steven Rostedt (VMware) Cc: John Ogness Cc: Douglas Gilbert Cc: James E.J. Bottomley Cc: Martin K. Petersen Cc: Lukas Middendorf Cc: Antti Palosaari Cc: Amir Goldstein Cc: Andy Shevchenko Cc: Arnd Bergmann Cc: Benjamin Herrenschmidt Cc: Benjamin LaHaise Cc: Clemens Ladisch Cc: David Airlie Cc: Jani Nikula Cc: Jani Nikula Cc: Jan Kara Cc: Joel Becker Cc: Joonas Lahtinen Cc: Joseph Qi Cc: Julia Lawall Cc: Mark Fasheh Cc: Paul Turner Cc: Peter Zijlstra Cc: Phillip Potter Cc: Qing Wang Cc: Rodrigo Vivi Cc: Sebastian Reichel Cc: Suren Baghdasaryan Cc: Tetsuo Handa Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

kbuild: do not quote string values in include/config/auto.conf

2022-01-08T09:03:57Z

The previous commit fixed up all shell scripts to not include include/config/auto.conf. Now that include/config/auto.conf is only included by Makefiles, we can change it into a more Make-friendly form. Previously, Kconfig output string values enclosed with double-quotes (both in the .config and include/config/auto.conf): CONFIG_X="foo bar" Unlike shell, Make handles double-quotes (and single-quotes as well) verbatim. We must rip them off when used. There are some patterns: [1] $(patsubst "%",%,$(CONFIG_X)) [2] $(CONFIG_X:"%"=%) [3] $(subst ",,$(CONFIG_X)) [4] $(shell echo $(CONFIG_X)) These are not only ugly, but also fragile. [1] and [2] do not work if the value contains spaces, like CONFIG_X=" foo bar " [3] does not work correctly if the value contains double-quotes like CONFIG_X="foo\"bar" [4] seems to work better, but has a cost of forking a process. Anyway, quoted strings were always PITA for our Makefiles. This commit changes Kconfig to stop quoting in include/config/auto.conf. These are the string type symbols referenced in Makefiles or scripts: ACPI_CUSTOM_DSDT_FILE ARC_BUILTIN_DTB_NAME ARC_TUNE_MCPU BUILTIN_DTB_SOURCE CC_IMPLICIT_FALLTHROUGH CC_VERSION_TEXT CFG80211_EXTRA_REGDB_KEYDIR EXTRA_FIRMWARE EXTRA_FIRMWARE_DIR EXTRA_TARGETS H8300_BUILTIN_DTB INITRAMFS_SOURCE LOCALVERSION MODULE_SIG_HASH MODULE_SIG_KEY NDS32_BUILTIN_DTB NIOS2_DTB_SOURCE OPENRISC_BUILTIN_DTB SOC_CANAAN_K210_DTB_SOURCE SYSTEM_BLACKLIST_HASH_LIST SYSTEM_REVOCATION_KEYS SYSTEM_TRUSTED_KEYS TARGET_CPU UNUSED_KSYMS_WHITELIST XILINX_MICROBLAZE0_FAMILY XILINX_MICROBLAZE0_HW_VER XTENSA_VARIANT_NAME I checked them one by one, and fixed up the code where necessary. Signed-off-by: Masahiro Yamada

firmware_loader: move struct builtin_fw to the only place used

2021-10-22T12:13:53Z

Now that x86 doesn't abuse picking at internals to the firmware loader move out the built-in firmware struct to its only user. Reviewed-by: Borislav Petkov Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20211021155843.1969401-5-mcgrof@kernel.org Signed-off-by: Greg Kroah-Hartman

firmware_loader: formalize built-in firmware API

2021-10-22T12:13:44Z

Formalize the built-in firmware with a proper API. This can later be used by other callers where all they need is built-in firmware. We export the firmware_request_builtin() call for now only under the TEST_FIRMWARE symbol namespace as there are no direct modular users for it. If they pop up they are free to export it generally. Built-in code always gets access to the callers and we'll demonstrate a hidden user which has been lurking in the kernel for a while and the reason why using a proper API was better long term. Reviewed-by: Borislav Petkov Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20211021155843.1969401-2-mcgrof@kernel.org Signed-off-by: Greg Kroah-Hartman

firmware_loader: add a sanity check for firmware_request_builtin()

2021-10-05T14:26:49Z

Right now firmware_request_builtin() is used internally only and so we have control over the callers. But if we want to expose that API more broadly we should ensure the firmware pointer is valid. This doesn't fix any known issue, it just prepares us to later expose this API to other users. Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20210917182226.3532898-4-mcgrof@kernel.org Signed-off-by: Greg Kroah-Hartman

firmware_loader: split built-in firmware call

2021-10-05T14:26:37Z

There are two ways the firmware_loader can use the built-in firmware: with or without the pre-allocated buffer. We already have one explicit use case for each of these, and so split them up so that it is clear what the intention is on the caller side. This also paves the way so that eventually other callers outside of the firmware loader can uses these if and when needed. While at it, adopt the firmware prefix for the routine names. Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20210917182226.3532898-3-mcgrof@kernel.org Signed-off-by: Greg Kroah-Hartman

firmware_loader: fix pre-allocated buf built-in firmware use

2021-10-05T14:26:29Z

The firmware_loader can be used with a pre-allocated buffer through the use of the API calls: o request_firmware_into_buf() o request_partial_firmware_into_buf() If the firmware was built-in and present, our current check for if the built-in firmware fits into the pre-allocated buffer does not return any errors, and we proceed to tell the caller that everything worked fine. It's a lie and no firmware would end up being copied into the pre-allocated buffer. So if the caller trust the result it may end up writing a bunch of 0's to a device! Fix this by making the function that checks for the pre-allocated buffer return non-void. Since the typical use case is when no pre-allocated buffer is provided make this return successfully for that case. If the built-in firmware does *not* fit into the pre-allocated buffer size return a failure as we should have been doing before. I'm not aware of users of the built-in firmware using the API calls with a pre-allocated buffer, as such I doubt this fixes any real life issue. But you never know... perhaps some oddball private tree might use it. In so far as upstream is concerned this just fixes our code for correctness. Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20210917182226.3532898-2-mcgrof@kernel.org Signed-off-by: Greg Kroah-Hartman

Merge 5.14-rc5 into driver-core-next

2021-08-09T07:03:47Z

We need the driver core fixes in here as well. Signed-off-by: Greg Kroah-Hartman