linux/drivers/firmware, branch v3.9

efivars: only check for duplicates on the registered list

2013-04-26T15:02:03Z

variable_is_present() accesses '__efivars' directly, but when called via gsmi_init() Michel reports observing the following crash, BUG: unable to handle kernel NULL pointer dereference at (null) IP: variable_is_present+0x55/0x170 Call Trace: register_efivars+0x106/0x370 gsmi_init+0x2ad/0x3da do_one_initcall+0x3f/0x170 The reason for the crash is that '__efivars' hasn't been initialised nor has it been registered with register_efivars() by the time the google EFI SMI driver runs. The gsmi code uses its own struct efivars, and therefore, a different variable list. Fix the above crash by passing the registered struct efivars to variable_is_present(), so that we traverse the correct list. Reported-by: Michel Lespinasse Tested-by: Michel Lespinasse Cc: Mike Waychison Cc: Matthew Garrett Cc: Seiji Aguchi Signed-off-by: Matt Fleming Signed-off-by: Linus Torvalds

Move utf16 functions to kernel core and rename

2013-04-15T20:23:03Z

We want to be able to use the utf16 functions that are currently present in the EFI variables code in platform-specific code as well. Move them to the kernel core, and in the process rename them to accurately describe what they do - they don't handle UTF16, only UCS2. Signed-off-by: Matthew Garrett Signed-off-by: Matt Fleming

x86, efivars: firmware bug workarounds should be in platform code

2013-04-09T10:34:05Z

Let's not burden ia64 with checks in the common efivars code that we're not writing too much data to the variable store. That kind of thing is an x86 firmware bug, plain and simple. efi_query_variable_store() provides platforms with a wrapper in which they can perform checks and workarounds for EFI variable storage bugs. Cc: H. Peter Anvin Cc: Matthew Garrett Signed-off-by: Matt Fleming

efivars: Fix check for CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE

2013-03-22T20:08:01Z

The 'CONFIG_' prefix is not implicit in IS_ENABLED(). Signed-off-by: Ben Hutchings Cc: Seth Forshee Cc: Signed-off-by: Matt Fleming

efivars: Handle duplicate names from get_next_variable()

2013-03-21T12:43:46Z

Some firmware exhibits a bug where the same VariableName and VendorGuid values are returned on multiple invocations of GetNextVariableName(). See, https://bugzilla.kernel.org/show_bug.cgi?id=47631 As a consequence of such a bug, Andre reports hitting the following WARN_ON() in the sysfs code after updating the BIOS on his, "Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z77X-UD3H, BIOS F19e 11/21/2012)" machine, [ 0.581554] EFI Variables Facility v0.08 2004-May-17 [ 0.584914] ------------[ cut here ]------------ [ 0.585639] WARNING: at /home/andre/linux/fs/sysfs/dir.c:536 sysfs_add_one+0xd4/0x100() [ 0.586381] Hardware name: To be filled by O.E.M. [ 0.587123] sysfs: cannot create duplicate filename '/firmware/efi/vars/SbAslBufferPtrVar-01f33c25-764d-43ea-aeea-6b5a41f3f3e8' [ 0.588694] Modules linked in: [ 0.589484] Pid: 1, comm: swapper/0 Not tainted 3.8.0+ #7 [ 0.590280] Call Trace: [ 0.591066] [] ? sysfs_add_one+0xd4/0x100 [ 0.591861] [] warn_slowpath_common+0x7f/0xc0 [ 0.592650] [] warn_slowpath_fmt+0x4c/0x50 [ 0.593429] [] ? strlcat+0x65/0x80 [ 0.594203] [] sysfs_add_one+0xd4/0x100 [ 0.594979] [] create_dir+0x78/0xd0 [ 0.595753] [] sysfs_create_dir+0x86/0xe0 [ 0.596532] [] kobject_add_internal+0x9c/0x220 [ 0.597310] [] kobject_init_and_add+0x67/0x90 [ 0.598083] [] ? efivar_create_sysfs_entry+0x61/0x1c0 [ 0.598859] [] efivar_create_sysfs_entry+0x11b/0x1c0 [ 0.599631] [] register_efivars+0xde/0x420 [ 0.600395] [] ? edd_init+0x2f5/0x2f5 [ 0.601150] [] efivars_init+0xb8/0x104 [ 0.601903] [] do_one_initcall+0x12a/0x180 [ 0.602659] [] kernel_init_freeable+0x13e/0x1c6 [ 0.603418] [] ? loglevel+0x31/0x31 [ 0.604183] [] ? rest_init+0x80/0x80 [ 0.604936] [] kernel_init+0xe/0xf0 [ 0.605681] [] ret_from_fork+0x7c/0xb0 [ 0.606414] [] ? rest_init+0x80/0x80 [ 0.607143] ---[ end trace 1609741ab737eb29 ]--- There's not much we can do to work around and keep traversing the variable list once we hit this firmware bug. Our only solution is to terminate the loop because, as Lingzhu reports, some machines get stuck when they encounter duplicate names, > I had an IBM System x3100 M4 and x3850 X5 on which kernel would > get stuck in infinite loop creating duplicate sysfs files because, > for some reason, there are several duplicate boot entries in nvram > getting GetNextVariableName into a circle of iteration (with > period > 2). Also disable the workqueue, as efivar_update_sysfs_entries() uses GetNextVariableName() to figure out which variables have been created since the last iteration. That algorithm isn't going to work if GetNextVariableName() returns duplicates. Note that we don't disable EFI variable creation completely on the affected machines, it's just that any pstore dump-* files won't appear in sysfs until the next boot. Reported-by: Andre Heider Reported-by: Lingzhu Xiang Tested-by: Lingzhu Xiang Cc: Seiji Aguchi Cc: Signed-off-by: Matt Fleming

efivars: explicitly calculate length of VariableName

2013-03-21T12:43:46Z

It's not wise to assume VariableNameSize represents the length of VariableName, as not all firmware updates VariableNameSize in the same way (some don't update it at all if EFI_SUCCESS is returned). There are even implementations out there that update VariableNameSize with values that are both larger than the string returned in VariableName and smaller than the buffer passed to GetNextVariableName(), which resulted in the following bug report from Michael Schroeder, > On HP z220 system (firmware version 1.54), some EFI variables are > incorrectly named : > > ls -d /sys/firmware/efi/vars/*8be4d* | grep -v -- -8be returns > /sys/firmware/efi/vars/dbxDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c > /sys/firmware/efi/vars/KEKDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c > /sys/firmware/efi/vars/SecureBoot-pport8be4df61-93ca-11d2-aa0d-00e098032b8c > /sys/firmware/efi/vars/SetupMode-Information8be4df61-93ca-11d2-aa0d-00e098032b8c The issue here is that because we blindly use VariableNameSize without verifying its value, we can potentially read garbage values from the buffer containing VariableName if VariableNameSize is larger than the length of VariableName. Since VariableName is a string, we can calculate its size by searching for the terminating NULL character. Reported-by: Frederic Crozat Cc: Matthew Garrett Cc: Josh Boyer Cc: Michael Schroeder Cc: Lee, Chun-Yi Cc: Lingzhu Xiang Cc: Seiji Aguchi Signed-off-by: Matt Fleming

efivars: Add module parameter to disable use as a pstore backend

2013-03-21T12:43:46Z

We know that with some firmware implementations writing too much data to UEFI variables can lead to bricking machines. Recent changes attempt to address this issue, but for some it may still be prudent to avoid writing large amounts of data until the solution has been proven on a wide variety of hardware. Crash dumps or other data from pstore can potentially be a large data source. Add a pstore_module parameter to efivars to allow disabling its use as a backend for pstore. Also add a config option, CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE, to allow setting the default value of this paramter to true (i.e. disabled by default). Signed-off-by: Seth Forshee Cc: Josh Boyer Cc: Matthew Garrett Cc: Seiji Aguchi Cc: Tony Luck Cc: Signed-off-by: Matt Fleming

efivars: Allow disabling use as a pstore backend

2013-03-21T12:43:46Z

Add a new option, CONFIG_EFI_VARS_PSTORE, which can be set to N to avoid using efivars as a backend to pstore, as some users may want to compile out the code completely. Set the default to Y to maintain backwards compatability, since this feature has always been enabled until now. Signed-off-by: Seth Forshee Cc: Josh Boyer Cc: Matthew Garrett Cc: Seiji Aguchi Cc: Tony Luck Cc: Signed-off-by: Matt Fleming

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace

2013-03-10T00:51:13Z

Pull namespace bugfixes from Eric Biederman: "This is three simple fixes against 3.9-rc1. I have tested each of these fixes and verified they work correctly. The userns oops in key_change_session_keyring and the BUG_ON triggered by proc_ns_follow_link were found by Dave Jones. I am including the enhancement for mount to only trigger requests of filesystem modules here instead of delaying this for the 3.10 merge window because it is both trivial and the kind of change that tends to bit-rot if left untouched for two months." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: proc: Use nd_jump_link in proc_ns_follow_link fs: Limit sys_mount to only request filesystem modules (Part 2). fs: Limit sys_mount to only request filesystem modules. userns: Stop oopsing in key_change_session_keyring

dmi_scan: fix missing check for _DMI_ signature in smbios_present()

2013-03-08T23:05:34Z

Commit 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") hoisted the check for "_DMI_" into dmi_scan_machine(), which means that we don't bother to check for "_DMI_" at offset 16 in an SMBIOS entry. smbios_present() may also call dmi_present() for an address where we found "_SM_", if it failed further validation. Check for "_DMI_" in smbios_present() before calling dmi_present(). [akpm@linux-foundation.org: fix build] Signed-off-by: Ben Hutchings Reported-by: Tim McGrath Tested-by: Tim Mcgrath Cc: Zhenzhong Duan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds