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

efi: stub: define DISABLE_BRANCH_PROFILING for all architectures

2019-04-03T04:23:20+00:00

[ Upstream commit b523e185bba36164ca48a190f5468c140d815414 ]

This moves the DISABLE_BRANCH_PROFILING define from the x86 specific
to the general CFLAGS definition for the stub. This fixes build errors
when building for arm64 with CONFIG_PROFILE_ALL_BRANCHES_ENABLED.

Reviewed-by: Matt Fleming 
Reported-by: Will Deacon 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

Revert "x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls"

2019-03-23T07:44:28+00:00

This reverts commit 7212e37cbdf99f48e4a6c689a42f4bda1ae69001.

Hedi Berriche  notes:

> In 4.4-stable efi_runtime_lock as defined in drivers/firmware/efi/runtime-wrappers.c
> is a spinlock (given it predates commit dce48e351c0d) and commit
>
>         f331e766c4be x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls
>
> which 7212e37cbdf9 is a backport of, needs it to be a semaphore.

Signed-off-by: Sasha Levin

iscsi_ibft: Fix missing break in switch statement

2019-03-23T07:44:28+00:00

commit df997abeebadaa4824271009e2d2b526a70a11cb upstream.

Add missing break statement in order to prevent the code from falling
through to case ISCSI_BOOT_TGT_NAME, which is unnecessary.

This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.

Fixes: b33a84a38477 ("ibft: convert iscsi_ibft module to iscsi boot lib")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls

2019-02-20T09:13:23+00:00

commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.

Calls into UV firmware must be protected against concurrency, expose the
efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
calls.

Signed-off-by: Hedi Berriche 
Signed-off-by: Borislav Petkov 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Mike Travis 
Cc: Andy Shevchenko 
Cc: Bhupesh Sharma 
Cc: Darren Hart 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: linux-efi 
Cc: platform-driver-x86@vger.kernel.org
Cc: stable@vger.kernel.org # v4.9+
Cc: Steve Wahl 
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berriche@hpe.com
Signed-off-by: Greg Kroah-Hartman

efi/libstub/arm64: Set -fpie when building the EFI stub

2018-11-27T15:07:58+00:00

commit 91ee5b21ee026c49e4e7483de69b55b8b47042be upstream.

Clang may emit absolute symbol references when building in non-PIC mode,
even when using the default 'small' code model, which is already mostly
position independent to begin with, due to its use of adrp/add pairs
that have a relative range of +/- 4 GB. The remedy is to pass the -fpie
flag, which can be done safely now that the code has been updated to avoid
GOT indirections (which may be emitted due to the compiler assuming that
the PIC/PIE code may end up in a shared library that is subject to ELF
symbol preemption)

Passing -fpie when building code that needs to execute at an a priori
unknown offset is arguably an improvement in any case, and given that
the recent visibility changes allow the PIC build to pass with GCC as
well, let's add -fpie for all arm64 builds rather than only for Clang.

Tested-by: Matthias Kaehlcke 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-5-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

efi/libstub/arm64: Force 'hidden' visibility for section markers

2018-11-27T15:07:58+00:00

commit 0426a4e68f18d75515414361de9e3e1445d2644e upstream.

To prevent the compiler from emitting absolute references to the section
markers when running in PIC mode, override the visibility to 'hidden' for
all contents of asm/sections.h

Tested-by: Matthias Kaehlcke 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar 
[nc: Fix conflict due to lack of commit 42b55734030c1 in linux-4.4.y]
Signed-off-by: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

firmware: dmi_scan: Fix handling of empty DMI strings

2018-05-30T05:48:56+00:00

[ Upstream commit a7770ae194569e96a93c48aceb304edded9cc648 ]

The handling of empty DMI strings looks quite broken to me:
* Strings from 1 to 7 spaces are not considered empty.
* True empty DMI strings (string index set to 0) are not considered
  empty, and result in allocating a 0-char string.
* Strings with invalid index also result in allocating a 0-char
  string.
* Strings starting with 8 spaces are all considered empty, even if
  non-space characters follow (sounds like a weird thing to do, but
  I have actually seen occurrences of this in DMI tables before.)
* Strings which are considered empty are reported as 8 spaces,
  instead of being actually empty.

Some of these issues are the result of an off-by-one error in memcmp,
the rest is incorrect by design.

So let's get it square: missing strings and strings made of only
spaces, regardless of their length, should be treated as empty and
no memory should be allocated for them. All other strings are
non-empty and should be allocated.

Signed-off-by: Jean Delvare 
Fixes: 79da4721117f ("x86: fix DMI out of memory problems")
Cc: Parag Warudkar 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

efi/esrt: Cleanup bad memory map log messages

2017-12-20T09:04:56+00:00

[ Upstream commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe ]

The Intel Compute Stick STCK1A8LFC and Weibu F3C platforms both
log 2 error messages during boot:

   efi: requested map not found.
   esrt: ESRT header is not in the memory map.

Searching the web, this seems to affect many other platforms too.
Since these messages are logged as errors, they appear on-screen during
the boot process even when using the "quiet" boot parameter used by
distros.

Demote the ESRT error to a warning so that it does not appear on-screen,
and delete the error logging from efi_mem_desc_lookup; both callsites
of that function log more specific messages upon failure.

Out of curiosity I looked closer at the Weibu F3C. There is no entry in
the UEFI-provided memory map which corresponds to the ESRT pointer, but
hacking the code to map it anyway, the ESRT does appear to be valid with
2 entries.

Signed-off-by: Daniel Drake 
Cc: Matt Fleming 
Acked-by: Peter Jones 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

efi: Move some sysfs files to be read-only by root

2017-12-16T09:33:48+00:00

commit af97a77bc01ce49a466f9d4c0125479e2e2230b6 upstream.

Thanks to the scripts/leaking_addresses.pl script, it was found that
some EFI values should not be readable by non-root users.

So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
make this easier, and use it in other places at the same time.

Reported-by: Linus Torvalds 
Tested-by: Dave Young 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ard Biesheuvel 
Cc: H. Peter Anvin 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20171206095010.24170-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/efi-bgrt: Fix kernel panic when mapping BGRT data

2017-12-05T10:22:50+00:00

commit 50a0cb565246f20d59cdb161778531e4b19d35ac upstream.

Starting with this commit 35eb8b81edd4 ("x86/efi: Build our own page
table structures") efi regions have a separate page directory called
"efi_pgd". In order to access any efi region we have to first shift %cr3
to this page table. In the bgrt code we are trying to copy bgrt_header
and image, but these regions fall under "EFI_BOOT_SERVICES_DATA"
and to access these regions we have to shift %cr3 to efi_pgd and not
doing so will cause page fault as shown below.

[    0.251599] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4
[    0.259126] Freeing SMP alternatives memory: 32K (ffffffff8230e000 - ffffffff82316000)
[    0.271803] BUG: unable to handle kernel paging request at fffffffefce35002
[    0.279740] IP: [] efi_bgrt_init+0x144/0x1fd
[    0.286383] PGD 300f067 PUD 0
[    0.289879] Oops: 0000 [#1] SMP
[    0.293566] Modules linked in:
[    0.297039] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc1-eywa-eywa-built-in-47041+ #2
[    0.306619] Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B104.B01.1511110114 11/11/2015
[    0.320925] task: ffffffff820134c0 ti: ffffffff82000000 task.ti: ffffffff82000000
[    0.329420] RIP: 0010:[]  [] efi_bgrt_init+0x144/0x1fd
[    0.338821] RSP: 0000:ffffffff82003f18  EFLAGS: 00010246
[    0.344852] RAX: fffffffefce35000 RBX: fffffffefce35000 RCX: fffffffefce2b000
[    0.352952] RDX: 000000008a82b000 RSI: ffffffff8235bb80 RDI: 000000008a835000
[    0.361050] RBP: ffffffff82003f30 R08: 000000008a865000 R09: ffffffffff202850
[    0.369149] R10: ffffffff811ad62f R11: 0000000000000000 R12: 0000000000000000
[    0.377248] R13: ffff88016dbaea40 R14: ffffffff822622c0 R15: ffffffff82003fb0
[    0.385348] FS:  0000000000000000(0000) GS:ffff88016d800000(0000) knlGS:0000000000000000
[    0.394533] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.401054] CR2: fffffffefce35002 CR3: 000000000300c000 CR4: 00000000003406f0
[    0.409153] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    0.417252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    0.425350] Stack:
[    0.427638]  ffffffffffffffff ffffffff82256900 ffff88016dbaea40 ffffffff82003f40
[    0.436086]  ffffffff821bbce0 ffffffff82003f88 ffffffff8219c0c2 0000000000000000
[    0.444533]  ffffffff8219ba4a ffffffff822622c0 0000000000083000 00000000ffffffff
[    0.452978] Call Trace:
[    0.455763]  [] efi_late_init+0x9/0xb
[    0.461697]  [] start_kernel+0x463/0x47f
[    0.467928]  [] ? set_init_arg+0x55/0x55
[    0.474159]  [] ? early_idt_handler_array+0x120/0x120
[    0.481669]  [] x86_64_start_reservations+0x2a/0x2c
[    0.488982]  [] x86_64_start_kernel+0x13d/0x14c
[    0.495897] Code: 00 41 b4 01 48 8b 78 28 e8 09 36 01 00 48 85 c0 48 89 c3 75 13 48 c7 c7 f8 ac d3 81 31 c0 e8 d7 3b fb fe e9 b5 00 00 00 45 84 e4 <44> 8b 6b 02 74 0d be 06 00 00 00 48 89 df e8 ae 34 0$
[    0.518151] RIP  [] efi_bgrt_init+0x144/0x1fd
[    0.524888]  RSP 
[    0.528851] CR2: fffffffefce35002
[    0.532615] ---[ end trace 7b06521e6ebf2aea ]---
[    0.537852] Kernel panic - not syncing: Attempted to kill the idle task!

As said above one way to fix this bug is to shift %cr3 to efi_pgd but we
are not doing that way because it leaks inner details of how we switch
to EFI page tables into a new call site and it also adds duplicate code.
Instead, we remove the call to efi_lookup_mapped_addr() and always
perform early_mem*() instead of early_io*() because we want to remap RAM
regions and not I/O regions. We also delete efi_lookup_mapped_addr()
because we are no longer using it.

Signed-off-by: Sai Praneeth Prakhya 
Reported-by: Wendy Wang 
Cc: Borislav Petkov 
Cc: Josh Triplett 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Signed-off-by: Matt Fleming 
Cc: "Ghannam, Yazen" 
Signed-off-by: Greg Kroah-Hartman