linux-stable.git/drivers/firmware, branch v4.1.41

efi: Expose non-blocking set_variable() wrapper to efivars

2016-07-11T03:07:11+00:00

[ Upstream commit 9c6672ac9c91f7eb1ec436be1442b8c26d098e55 ]

Commit 6d80dba1c9fe ("efi: Provide a non-blocking SetVariable()
operation") implemented a non-blocking alternative for the UEFI
SetVariable() invocation performed by efivars, since it may
occur in atomic context. However, this version of the function
was never exposed via the efivars struct, so the non-blocking
versions was not actually callable. Fix that.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Fixes: 6d80dba1c9fe ("efi: Provide a non-blocking SetVariable() operation")
Link: http://lkml.kernel.org/r/1454364428-494-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

efi: Fix out-of-bounds read in variable_matches()

2016-05-17T17:42:38+00:00

[ Upstream commit 630ba0cc7a6dbafbdee43795617c872b35cde1b4 ]

The variable_matches() function can currently read "var_name[len]", for
example when:

 - var_name[0] == 'a',
 - len == 1
 - match_name points to the NUL-terminated string "ab".

This function is supposed to accept "var_name" inputs that are not
NUL-terminated (hence the "len" parameter"). Document the function, and
access "var_name[*match]" only if "*match" is smaller than "len".

Reported-by: Chris Wilson 
Signed-off-by: Laszlo Ersek 
Cc: Peter Jones 
Cc: Matthew Garrett 
Cc: Jason Andryuk 
Cc: Jani Nikula 
Cc:  # v3.10+
Link: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin

efi: Add pstore variables to the deletion whitelist

2016-04-12T02:44:23+00:00

[ Upstream commit e246eb568bc4cbbdd8a30a3c11151ff9b7ca7312 ]

Laszlo explains why this is a good idea,

 'This is because the pstore filesystem can be backed by UEFI variables,
  and (for example) a crash might dump the last kilobytes of the dmesg
  into a number of pstore entries, each entry backed by a separate UEFI
  variable in the above GUID namespace, and with a variable name
  according to the above pattern.

  Please see "drivers/firmware/efi/efi-pstore.c".

  While this patch series will not prevent the user from deleting those
  UEFI variables via the pstore filesystem (i.e., deleting a pstore fs
  entry will continue to delete the backing UEFI variable), I think it
  would be nice to preserve the possibility for the sysadmin to delete
  Linux-created UEFI variables that carry portions of the crash log,
  *without* having to mount the pstore filesystem.'

There's also no chance of causing machines to become bricked by
deleting these variables, which is the whole purpose of excluding
things from the whitelist.

Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so
that we don't have to update the string in the future if new variable
name formats are created for crash dump variables.

Reported-by: Laszlo Ersek 
Acked-by: Peter Jones 
Tested-by: Peter Jones 
Cc: Matthew Garrett 
Cc: "Lee, Chun-Yi" 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin

efi: Make efivarfs entries immutable by default

2016-04-12T02:44:23+00:00

[ Upstream commit ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 ]

"rm -rf" is bricking some peoples' laptops because of variables being
used to store non-reinitializable firmware driver data that's required
to POST the hardware.

These are 100% bugs, and they need to be fixed, but in the mean time it
shouldn't be easy to *accidentally* brick machines.

We have to have delete working, and picking which variables do and don't
work for deletion is quite intractable, so instead make everything
immutable by default (except for a whitelist), and make tools that
aren't quite so broad-spectrum unset the immutable flag.

Signed-off-by: Peter Jones 
Tested-by: Lee, Chun-Yi 
Acked-by: Matthew Garrett 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin

efi: Make our variable validation list include the guid

2016-04-12T02:44:23+00:00

[ Upstream commit 8282f5d9c17fe15a9e658c06e3f343efae1a2a2f ]

All the variables in this list so far are defined to be in the global
namespace in the UEFI spec, so this just further ensures we're
validating the variables we think we are.

Including the guid for entries will become more important in future
patches when we decide whether or not to allow deletion of variables
based on presence in this list.

Signed-off-by: Peter Jones 
Tested-by: Lee, Chun-Yi 
Acked-by: Matthew Garrett 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin

efi: Do variable name validation tests in utf8

2016-04-12T02:44:22+00:00

[ Upstream commit 3dcb1f55dfc7631695e69df4a0d589ce5274bd07 ]

Actually translate from ucs2 to utf8 before doing the test, and then
test against our other utf8 data, instead of fudging it.

Signed-off-by: Peter Jones 
Acked-by: Matthew Garrett 
Tested-by: Lee, Chun-Yi 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin

efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version

2016-04-12T02:44:22+00:00

[ Upstream commit e0d64e6a880e64545ad7d55786aa84ab76bac475 ]

Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming
all variable names fit in ASCII.

Signed-off-by: Peter Jones 
Acked-by: Matthew Garrett 
Tested-by: Lee, Chun-Yi 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin

efi: efivar_create_sysfs_entry() should return negative error codes

2016-04-12T02:44:22+00:00

[ Upstream commit f7ef7e3e506023f826c1ee60b7e59b985316e180 ]

It's not very normal to return 1 on failure and 0 on success.  There
isn't a reason for it here, the callers don't care so long as it's
non-zero on failure.

Signed-off-by: Dan Carpenter 
Signed-off-by: Matt Fleming 
Signed-off-by: Sasha Levin

arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions

2015-10-22T21:43:25+00:00

commit 0ce3cc008ec04258b6a6314b09f1a6012810881a upstream.

The new Properties Table feature introduced in UEFIv2.5 may
split memory regions that cover PE/COFF memory images into
separate code and data regions. Since these regions only differ
in the type (runtime code vs runtime data) and the permission
bits, but not in the memory type attributes (UC/WC/WT/WB), the
spec does not require them to be aligned to 64 KB.

Since the relative offset of PE/COFF .text and .data segments
cannot be changed on the fly, this means that we can no longer
pad out those regions to be mappable using 64 KB pages.
Unfortunately, there is no annotation in the UEFI memory map
that identifies data regions that were split off from a code
region, so we must apply this logic to all adjacent runtime
regions whose attributes only differ in the permission bits.

So instead of rounding each memory region to 64 KB alignment at
both ends, only round down regions that are not directly
preceded by another runtime region with the same type
attributes. Since the UEFI spec does not mandate that the memory
map be sorted, this means we also need to sort it first.

Note that this change will result in all EFI_MEMORY_RUNTIME
regions whose start addresses are not aligned to the OS page
size to be mapped with executable permissions (i.e., on kernels
compiled with 64 KB pages). However, since these mappings are
only active during the time that UEFI Runtime Services are being
invoked, the window for abuse is rather small.

Tested-by: Mark Salter 
Tested-by: Mark Rutland  [UEFI 2.4 only]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming 
Reviewed-by: Mark Salter 
Reviewed-by: Mark Rutland 
Cc: Catalin Marinas 
Cc: Leif Lindholm 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443218539-7610-3-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

efi: Check for NULL efi kernel parameters

2015-08-10T19:21:57+00:00

commit 9115c7589b11349a1c3099758b4bded579ff69e0 upstream.

Even though it is documented how to specifiy efi parameters, it is
possible to cause a kernel panic due to a dereference of a NULL pointer when
parsing such parameters if "efi" alone is given:

PANIC: early exception 0e rip 10:ffffffff812fb361 error 0 cr2 0
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-rc1+ #450
[ 0.000000]  ffffffff81fe20a9 ffffffff81e03d50 ffffffff8184bb0f 00000000000003f8
[ 0.000000]  0000000000000000 ffffffff81e03e08 ffffffff81f371a1 64656c62616e6520
[ 0.000000]  0000000000000069 000000000000005f 0000000000000000 0000000000000000
[ 0.000000] Call Trace:
[ 0.000000]  [] dump_stack+0x45/0x57
[ 0.000000]  [] early_idt_handler_common+0x81/0xae
[ 0.000000]  [] ? parse_option_str+0x11/0x90
[ 0.000000]  [] arch_parse_efi_cmdline+0x15/0x42
[ 0.000000]  [] do_early_param+0x50/0x8a
[ 0.000000]  [] parse_args+0x1e3/0x400
[ 0.000000]  [] parse_early_options+0x24/0x28
[ 0.000000]  [] ? loglevel+0x31/0x31
[ 0.000000]  [] parse_early_param+0x31/0x3d
[ 0.000000]  [] setup_arch+0x2de/0xc08
[ 0.000000]  [] ? vprintk_default+0x1a/0x20
[ 0.000000]  [] start_kernel+0x90/0x423
[ 0.000000]  [] x86_64_start_reservations+0x2a/0x2c
[ 0.000000]  [] x86_64_start_kernel+0xeb/0xef
[ 0.000000] RIP 0xffffffff81ba2efc

This panic is not reproducible with "efi=" as this will result in a non-NULL
zero-length string.

Thus, verify that the pointer to the parameter string is not NULL. This is
consistent with other parameter-parsing functions which check for NULL pointers.

Signed-off-by: Ricardo Neri 
Cc: Dave Young 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman