linux/drivers/base/firmware_class.c, branch v3.19

firmware class: Deletion of an unnecessary check before the function call "vunmap"

2014-11-27T03:41:15Z

The vunmap() function performes also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring Signed-off-by: Greg Kroah-Hartman

firmware loader: fix hung task warning dump

2014-11-27T03:41:15Z

When using request_firmware_nowait() with FW_ACTION_NOHOTPLUG param to expose user helper interface, if the user do not react immediately, after 120 seconds there will be a hung task warning message dumped as below: [ 3000.784235] INFO: task kworker/0:0:8259 blocked for more than 120 seconds. [ 3000.791281] Tainted: G E 3.16.0-rc1-yocto-standard #41 [ 3000.798082] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 3000.806072] kworker/0:0 D cd0075c8 0 8259 2 0x00000000 [ 3000.812765] Workqueue: events request_firmware_work_func [ 3000.818253] cd375e18 00000046 0000000e cd0075c8 000000f0 cd40ea00 cd375fec 1b883e89 [ 3000.826374] 0000026b cd40ea00 80000000 00000001 cd0075c8 00000000 cd375de4 c119917f [ 3000.834492] cd563360 cd375df4 c119a0ab cd563360 00000000 cd375e24 c119a1d6 00000000 [ 3000.842616] Call Trace: [ 3000.845252] [] ? kernfs_next_descendant_post+0x3f/0x50 [ 3000.851543] [] ? kernfs_activate+0x6b/0xc0 [ 3000.856790] [] ? kernfs_add_one+0xd6/0x130 [ 3000.862047] [] schedule+0x22/0x60 [ 3000.866548] [] schedule_timeout+0x175/0x1d0 [ 3000.871887] [] ? __kernfs_create_file+0x71/0xa0 [ 3000.877574] [] ? sysfs_add_file_mode_ns+0xaa/0x180 [ 3000.883533] [] wait_for_completion+0x6f/0xb0 [ 3000.888961] [] ? wake_up_process+0x40/0x40 [ 3000.894219] [] _request_firmware+0x750/0x9f0 [ 3000.899666] [] ? n_tty_receive_buf2+0x1f/0x30 [ 3000.905200] [] request_firmware_work_func+0x22/0x50 [ 3000.911235] [] process_one_work+0x122/0x380 [ 3000.916571] [] worker_thread+0xf9/0x470 [ 3000.921555] [] ? create_and_start_worker+0x50/0x50 [ 3000.927497] [] ? create_and_start_worker+0x50/0x50 [ 3000.933448] [] kthread+0x9f/0xc0 [ 3000.937850] [] ret_from_kernel_thread+0x20/0x30 [ 3000.943548] [] ? kthread_worker_fn+0x100/0x100 This patch change the wait_for_completion() function call to wait_for_completion_interruptible() function call for solving the issue. Cc: Matt Fleming Signed-off-by: Kweh, Hock Leong Acked-by: Ming Lei Acked-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

firmware_class: make sure fw requests contain a name

2014-09-24T06:26:58Z

An empty firmware request name will trigger warnings when building device names. Make sure this is caught earlier and rejected. The warning was visible via the test_firmware.ko module interface: echo -ne "\x00" > /sys/devices/virtual/misc/test_firmware/trigger_request Reported-by: Sasha Levin Signed-off-by: Kees Cook Cc: stable@vger.kernel.org Tested-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

2014-08-06T15:06:39Z

Pull security subsystem updates from James Morris: "In this release: - PKCS#7 parser for the key management subsystem from David Howells - appoint Kees Cook as seccomp maintainer - bugfixes and general maintenance across the subsystem" * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (94 commits) X.509: Need to export x509_request_asymmetric_key() netlabel: shorter names for the NetLabel catmap funcs/structs netlabel: fix the catmap walking functions netlabel: fix the horribly broken catmap functions netlabel: fix a problem when setting bits below the previously lowest bit PKCS#7: X.509 certificate issuer and subject are mandatory fields in the ASN.1 tpm: simplify code by using %*phN specifier tpm: Provide a generic means to override the chip returned timeouts tpm: missing tpm_chip_put in tpm_get_random() tpm: Properly clean sysfs entries in error path tpm: Add missing tpm_do_selftest to ST33 I2C driver PKCS#7: Use x509_request_asymmetric_key() Revert "selinux: fix the default socket labeling in sock_graft()" X.509: x509_request_asymmetric_keys() doesn't need string length arguments PKCS#7: fix sparse non static symbol warning KEYS: revert encrypted key change ima: add support for measuring and appraising firmware firmware_class: perform new LSM checks security: introduce kernel_fw_from_file hook PKCS#7: Missing inclusion of linux/err.h ...

firmware_class: perform new LSM checks

2014-07-25T18:47:45Z

This attaches LSM hooks to the existing firmware loading interfaces: filesystem-found firmware and demand-loaded blobs. On errors, loads are aborted and the failure code is returned to userspace. Signed-off-by: Kees Cook Reviewed-by: Takashi Iwai Acked-by: Greg Kroah-Hartman

firmware loader: Fix _request_firmware_load() return val for fw load abort

2014-07-24T02:15:20Z

_request_firmware_load() returns -ENOMEM when fw load is aborted after timeout. Call is_fw_load_aborted() to check if fw load is aborted and if true return -EAGAIN. Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

firmware loader: inform direct failure when udev loader is disabled

2014-07-08T22:28:16Z

Now that the udev firmware loader is optional request_firmware() will not provide any information on the kernel ring buffer if direct firmware loading failed and udev firmware loading is disabled. If no information is needed request_firmware_direct() should be used for optional firmware, at which point drivers can take on the onus over informing of any failures, if udev firmware loading is disabled though we should at the very least provide some sort of information as when the udev loader was enabled by default back in the days. With this change with a simple firmware load test module [0]: Example output without FW_LOADER_USER_HELPER_FALLBACK platform fake-dev.0: Direct firmware load for fake.bin failed with error -2 Example with FW_LOADER_USER_HELPER_FALLBACK platform fake-dev.0: Direct firmware load for fake.bin failed with error -2 platform fake-dev.0: Falling back to user helper Without this change without FW_LOADER_USER_HELPER_FALLBACK we get no output logged upon failure. Cc: Tom Gundersen Cc: Ming Lei Cc: Abhay Salunke Cc: Stefan Roese Cc: Arnd Bergmann Cc: Kay Sievers Signed-off-by: Luis R. Rodriguez Reviewed-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

firmware: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN

2014-07-08T22:27:04Z

use mm.h definition Cc: Ming Lei Signed-off-by: Fabian Frederick Signed-off-by: Greg Kroah-Hartman

firmware: read firmware size using i_size_read()

2014-07-08T22:27:04Z

There is no need to read attr because inode structure contains size of the file. Use i_size_read() instead. Signed-off-by: Dmitry Kasatkin Acked-by: Ming Lei Signed-off-by: Greg Kroah-Hartman

firmware loader: allow disabling of udev as firmware loader

2014-07-08T22:24:39Z

[The patch was originally proposed by Tom Gundersen, and rewritten afterwards by me; most of changelogs below borrowed from Tom's original patch -- tiwai] Currently (at least) the dell-rbu driver selects FW_LOADER_USER_HELPER, which means that distros can't really stop loading firmware through udev without breaking other users (though some have). Ideally we would remove/disable the udev firmware helper in both the kernel and in udev, but if we were to disable it in udev and not the kernel, the result would be (seemingly) hung kernels as no one would be around to cancel firmware requests. This patch allows udev firmware loading to be disabled while still allowing non-udev firmware loading, as done by the dell-rbu driver, to continue working. This is achieved by only using the fallback mechanism when the uevent is suppressed. The patch renames the user-selectable Kconfig from FW_LOADER_USER_HELPER to FW_LOADER_USER_HELPER_FALLBACK, and the former is reverse-selected by the latter or the drivers that need userhelper like dell-rbu. Also, the "default y" is removed together with this change, since it's been deprecated in udev upstream, thus rather better to disable it nowadays. Tested with FW_LOADER_USER_HELPER=n LATTICE_ECP3_CONFIG=y DELL_RBU=y and udev without the firmware loading support, but I don't have the hardware to test the lattice/dell drivers, so additional testing would be appreciated. Reviewed-by: Tom Gundersen Cc: Ming Lei Cc: Abhay Salunke Cc: Stefan Roese Cc: Arnd Bergmann Cc: Kay Sievers Tested-by: Balaji Singh Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman