linux-toradex.git/drivers/firmware, branch v3.2.68

dmi: add support for exact DMI matches in addition to substring matching

2014-05-18T13:58:06+00:00

commit 5017b2851373ee15c7035151853bb1448800cae2 upstream.

dmi_match() considers a substring match to be a successful match.  This is
not always sufficient to distinguish between DMI data for different
systems.  Add support for exact string matching using strcmp() in addition
to the substring matching using strstr().

The specific use case in the i915 driver is to allow us to use an exact
match for D510MO, without also incorrectly matching D510MOV:

  {
	.ident = "Intel D510MO",
	.matches = {
		DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
		DMI_EXACT_MATCH(DMI_BOARD_NAME, "D510MO"),
	},
  }

Signed-off-by: Jani Nikula 
Cc: 
Cc: Chris Wilson 
Cc: Cornel Panceac 
Acked-by: Daniel Vetter 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

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

2013-05-30T13:35:10+00:00

commit a6e4d5a03e9e3587e88aba687d8f225f4f04c792 upstream.

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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

efivars: pstore: Do not check size when erasing variable

2013-03-27T02:41:24+00:00

In 3.2, unlike mainline, efi_pstore_erase() calls efi_pstore_write()
with a size of 0, as the underlying EFI interface treats a size of 0
as meaning deletion.

This was not taken into account in my backport of commit d80a361d779a
'efi_pstore: Check remaining space with QueryVariableInfo() before
writing data'.  The size check should be omitted when erasing.

Signed-off-by: Ben Hutchings

efivars: Handle duplicate names from get_next_variable()

2013-03-27T02:41:21+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.

Reported-by: Andre Heider 
Reported-by: Lingzhu Xiang 
Tested-by: Lingzhu Xiang 
Cc: Seiji Aguchi 
Signed-off-by: Matt Fleming 
[bwh: Backported to 3.2: reason is not checked in efi_pstore_write()]
Signed-off-by: Ben Hutchings

efivars: explicitly calculate length of VariableName

2013-03-27T02:41:21+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.

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: Ben Hutchings

efi_pstore: Introducing workqueue updating sysfs

2013-03-27T02:41:20+00:00

commit a93bc0c6e07ed9bac44700280e65e2945d864fd4 upstream.

[Problem]
efi_pstore creates sysfs entries, which enable users to access to NVRAM,
in a write callback. If a kernel panic happens in an interrupt context,
it may fail because it could sleep due to dynamic memory allocations during
creating sysfs entries.

[Patch Description]
This patch removes sysfs operations from a write callback by introducing
a workqueue updating sysfs entries which is scheduled after the write
callback is called.

Also, the workqueue is kicked in a just oops case.
A system will go down in other cases such as panic, clean shutdown and emergency
restart. And we don't need to create sysfs entries because there is no chance for
users to access to them.

efi_pstore will be robust against a kernel panic in an interrupt context with this patch.

Signed-off-by: Seiji Aguchi 
Acked-by: Matt Fleming 
Signed-off-by: Tony Luck 
[bwh: Backported to 3.2:
 - Adjust contest
 - Don't check reason in efi_pstore_write(), as it is not given as a
   parameter
 - Move up declaration of __efivars]
Signed-off-by: Ben Hutchings

efivars: Fix check for CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE

2013-03-27T02:41:20+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

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

2013-03-27T02:41:20+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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

efivars: Allow disabling use as a pstore backend

2013-03-27T02:41:19+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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

efi: be more paranoid about available space when creating variables

2013-03-20T15:03:28+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 
Signed-off-by: Matt Fleming 
[bwh: Backported to 3.2:
 - Drop efivarfs changes and unused check_var_size()
 - Add error codes to include/linux/efi.h, added upstream by
   commit 5d9db883761a ('efi: Add support for a UEFI variable filesystem')
 - Add efi_status_to_err(), added upstream by commit 7253eaba7b17
   ('efivarfs: Return an error if we fail to read a variable')]
Signed-off-by: Ben Hutchings