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

efivars: Handle duplicate names from get_next_variable()

2013-04-05T17:16:52+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.0-stable. Removed code related to pstore
workqueue but pulled in helper function variable_is_present
from a93bc0c; Moved the definition of __efivars to the top
for being referenced in variable_is_present.]

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-05T17:16:52+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

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

2013-03-14T18:32:11+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

drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists

2013-01-28T04:46:29+00:00

commit 9f9c9cbb60576a1518d0bf93fb8e499cffccf377 upstream.

The right dmi version is in SMBIOS if it's zero in DMI region

This issue was originally found from an oracle bug.
One customer noticed system UUID doesn't match between dmidecode & uek2.

 - HP ProLiant BL460c G6 :
   # cat /sys/devices/virtual/dmi/id/product_uuid
   00000000-0000-4C48-3031-4D5030333531
   # dmidecode | grep -i uuid
   UUID: 00000000-0000-484C-3031-4D5030333531

From SMBIOS 2.6 on, spec use little-endian encoding for UUID other than
network byte order.

So we need to get dmi version to distinguish.  If version is 0.0, the
real version is taken from the SMBIOS version.  This is part of original
kernel comment in code.

[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Zhenzhong Duan 
Cc: Feng Jin 
Cc: Jean Delvare 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Abdallah Chatila 
Signed-off-by: Greg Kroah-Hartman

drivers/firmware/dmi_scan.c: check dmi version when get system uuid

2013-01-28T04:46:29+00:00

commit f1d8e614d74b09531b9a85e812485340f3df7b1c upstream.

As of version 2.6 of the SMBIOS specification, the first 3 fields of the
UUID are supposed to be little-endian encoded.

Also a minor fix to match variable meaning and mute checkpatch.pl

[akpm@linux-foundation.org: tweak code comment]
Signed-off-by: Zhenzhong Duan 
Cc: Feng Jin 
Cc: Jean Delvare 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Abdallah Chatila 
Signed-off-by: Greg Kroah-Hartman

firmware: Add missing attributes to EFI variable attribute print out from sysfs

2012-10-07T15:27:25+00:00

commit 7083909023bbe29b3176e92d2d089def1aa7aa1e upstream.

Some of the EFI variable attributes are missing from print out from
/sys/firmware/efi/vars/*/attributes. This patch adds those in. It also
updates code to use pre-defined constants for masking current value
of attributes.

Signed-off-by: Khalid Aziz 
Reviewed-by: Kees Cook 
Acked-by: Matthew Garrett 
Signed-off-by: Greg Kroah-Hartman

dmi: Feed DMI table to /dev/random driver

2012-08-15T19:04:29+00:00

commit d114a33387472555188f142ed8e98acdb8181c6d upstream.

Send the entire DMI (SMBIOS) table to the /dev/random driver to
help seed its pools.

Signed-off-by: Tony Luck 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

pcdp: use early_ioremap/early_iounmap to access pcdp table

2012-08-15T19:04:10+00:00

commit 6c4088ac3a4d82779903433bcd5f048c58fb1aca upstream.

efi_setup_pcdp_console() is called during boot to parse the HCDP/PCDP
EFI system table and setup an early console for printk output.  The
routine uses ioremap/iounmap to setup access to the HCDP/PCDP table
information.

The call to ioremap is happening early in the boot process which leads
to a panic on x86_64 systems:

    panic+0x01ca
    do_exit+0x043c
    oops_end+0x00a7
    no_context+0x0119
    __bad_area_nosemaphore+0x0138
    bad_area_nosemaphore+0x000e
    do_page_fault+0x0321
    page_fault+0x0020
    reserve_memtype+0x02a1
    __ioremap_caller+0x0123
    ioremap_nocache+0x0012
    efi_setup_pcdp_console+0x002b
    setup_arch+0x03a9
    start_kernel+0x00d4
    x86_64_start_reservations+0x012c
    x86_64_start_kernel+0x00fe

This replaces the calls to ioremap/iounmap in efi_setup_pcdp_console()
with calls to early_ioremap/early_iounmap which can be called during
early boot.

This patch was tested on an x86_64 prototype system which uses the
HCDP/PCDP table for early console setup.

Signed-off-by: Greg Pearson 
Acked-by: Khalid Aziz 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

efivars: Improve variable validation

2012-05-07T15:56:38+00:00

commit 54b3a4d311c98ad94b737802a8b5f2c8c6bfd627 upstream.

Ben Hutchings pointed out that the validation in efivars was inadequate -
most obviously, an entry with size 0 would server as a DoS against the
kernel. Improve this based on his suggestions.

Signed-off-by: Matthew Garrett 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

efi: Validate UEFI boot variables

2012-05-07T15:56:38+00:00

commit fec6c20b570bcf541e581fc97f2e0cbdb9725b98 upstream.

A common flaw in UEFI systems is a refusal to POST triggered by a malformed
boot variable. Once in this state, machines may only be restored by
reflashing their firmware with an external hardware device. While this is
obviously a firmware bug, the serious nature of the outcome suggests that
operating systems should filter their variable writes in order to prevent
a malicious user from rendering the machine unusable.

Signed-off-by: Matthew Garrett 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman