linux-stable.git/drivers/firmware, branch linux-3.8.y

efivars: Handle duplicate names from get_next_variable()

2013-04-05T16:26:16+00:00

commit e971318bbed610e28bb3fde9d548e6aaf0a6b02e upstream.

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.

[Backported for 3.8-stable. Removed code related to pstore
workqueue but pulled in helper function variable_is_present
from a93bc0c.]

Reported-by: Andre Heider 
Reported-by: Lingzhu Xiang 
Tested-by: Lingzhu Xiang 
Cc: Seiji Aguchi 
Signed-off-by: Matt Fleming 
Signed-off-by: Lingzhu Xiang 
Reviewed-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

efivars: explicitly calculate length of VariableName

2013-04-05T16:26:16+00:00

commit ec50bd32f1672d38ddce10fb1841cbfda89cfe9a upstream.

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.

[Backported for 3.8-stable. Removed workqueue code added in
a93bc0c 3.9-rc1.]

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 
Signed-off-by: Lingzhu Xiang 
Reviewed-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

efivars: Fix check for CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE

2013-03-28T19:18:13+00:00

commit ca0ba26fbbd2d81c43085df49ce0abfe34535a90 upstream.

The 'CONFIG_' prefix is not implicit in IS_ENABLED().

Signed-off-by: Ben Hutchings 
Cc: Seth Forshee 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

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

2013-03-28T19:18:13+00:00

commit ec0971ba5372a4dfa753f232449d23a8fd98490e upstream.

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 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

efivars: Allow disabling use as a pstore backend

2013-03-28T19:18:12+00:00

commit ed9dc8ce7a1c8115dba9483a9b51df8b63a2e0ef upstream.

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 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

efi: be more paranoid about available space when creating variables

2013-03-14T18:26:37+00:00

commit 68d929862e29a8b52a7f2f2f86a0600423b093cd upstream.

UEFI variables are typically stored in flash. For various reasons, avaiable
space is typically not reclaimed immediately upon the deletion of a
variable - instead, the system will garbage collect during initialisation
after a reboot.

Some systems appear to handle this garbage collection extremely poorly,
failing if more than 50% of the system flash is in use. This can result in
the machine refusing to boot. The safest thing to do for the moment is to
forbid writes if they'd end up using more than half of the storage space.
We can make this more finegrained later if we come up with a method for
identifying the broken machines.

Signed-off-by: Matthew Garrett 
Cc: Josh Boyer 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

efivars: Disable external interrupt while holding efivars->lock

2013-03-14T18:26:36+00:00

commit 81fa4e581d9283f7992a0d8c534bb141eb840a14 upstream.

[Problem]
There is a scenario which efi_pstore fails to log messages in a panic case.

 - CPUA holds an efi_var->lock in either efivarfs parts
   or efi_pstore with interrupt enabled.
 - CPUB panics and sends IPI to CPUA in smp_send_stop().
 - CPUA stops with holding the lock.
 - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC)
   but it returns without logging messages.

[Patch Description]
This patch disables an external interruption while holding efivars->lock
as follows.

In efi_pstore_write() and get_var_data(), spin_lock/spin_unlock is
replaced by spin_lock_irqsave/spin_unlock_irqrestore because they may
be called in an interrupt context.

In other functions, they are replaced by spin_lock_irq/spin_unlock_irq.
because they are all called from a process context.

By applying this patch, we can avoid the problem above with
a following senario.

 - CPUA holds an efi_var->lock with interrupt disabled.
 - CPUB panics and sends IPI to CPUA in smp_send_stop().
 - CPUA receives the IPI after releasing the lock because it is
   disabling interrupt while holding the lock.
 - CPUB waits for one sec until CPUA releases the lock.
 - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC)
   And it can hold the lock successfully.

Signed-off-by: Seiji Aguchi 
Acked-by: Mike Waychison 
Acked-by: Matt Fleming 
Signed-off-by: Tony Luck 
Cc: Josh Boyer 
Signed-off-by: Greg Kroah-Hartman

efivarfs: return accurate error code in efivarfs_fill_super()

2013-03-14T18:26:25+00:00

commit feff5dc4f98330d8152b521acc2e18c16712e6c8 upstream.

Joseph was hitting a failure case when mounting efivarfs which
resulted in an incorrect error message,

  $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory

triggered when efivarfs_valid_name() returned -EINVAL.

Make sure we pass accurate return values up the stack if
efivarfs_fill_super() fails to build inodes for EFI variables.

Reported-by: Joseph Yasi 
Reported-by: Lingzhu Xiang 
Cc: Josh Boyer 
Cc: Jeremy Kerr 
Cc: Matthew Garrett 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

efivars: efivarfs_valid_name() should handle pstore syntax

2013-03-14T18:26:25+00:00

commit 123abd76edf56c02a76b46d3d673897177ef067b upstream.

Stricter validation was introduced with commit da27a24383b2b
("efivarfs: guid part of filenames are case-insensitive") and commit
47f531e8ba3b ("efivarfs: Validate filenames much more aggressively"),
which is necessary for the guid portion of efivarfs filenames, but we
don't need to be so strict with the first part, the variable name. The
UEFI specification doesn't impose any constraints on variable names
other than they be a NULL-terminated string.

The above commits caused a regression that resulted in users seeing
the following message,

  $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory

whenever pstore EFI variables were present in the variable store,
since their variable names failed to pass the following check,

    /* GUID should be right after the first '-' */
    if (s - 1 != strchr(str, '-'))

as a typical pstore filename is of the form, dump-type0-10-1-.
The fix is trivial since the guid portion of the filename is GUID_LEN
bytes, we can use (len - GUID_LEN) to ensure the '-' character is
where we expect it to be.

(The bogus ENOMEM error value will be fixed in a separate patch.)

Reported-by: Joseph Yasi 
Tested-by: Joseph Yasi 
Reported-by: Lingzhu Xiang 
Cc: Josh Boyer 
Cc: Jeremy Kerr 
Cc: Matthew Garrett 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

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

2013-03-14T18:26:24+00:00

commit a40e7cf8f06b4e322ba902e4e9f6a6b0c2daa907 upstream.

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 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman