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

efi/esrt: Only call efi_mem_reserve() for boot services memory

2018-09-26T06:36:38+00:00

[ Upstream commit 61f0d55569463a1af897117ff47d202b0ccb2e24 ]

The following commit:

  7e1550b8f208 ("efi: Drop type and attribute checks in efi_mem_desc_lookup()")

refactored the implementation of efi_mem_desc_lookup() so that the type
check is moved to the callers, one of which is the x86 version of
efi_arch_mem_reserve(), where we added a modified check that only takes
EFI_BOOT_SERVICES_DATA regions into account.

This is reasonable, since it is the only memory type that requires this,
but doing so uncovered some unexpected behavior in the ESRT code, which
permits the ESRT table to reside in other types of memory than what the
UEFI spec mandates (i.e., EFI_BOOT_SERVICES_DATA), and unconditionally
calls efi_mem_reserve() on the region in question. This may result in
errors such as

  esrt: Reserving ESRT space from 0x000000009c810318 to 0x000000009c810350.
  efi: Failed to lookup EFI memory descriptor for 0x000000009c810318

when the ESRT table is not in EFI_BOOT_SERVICES_DATA memory, but we try
to reserve it nonetheless.

So make the call to efi_mem_reserve() conditional on the memory type.

Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

efi/arm: preserve early mapping of UEFI memory map longer for BGRT

2018-09-26T06:36:33+00:00

[ Upstream commit 3ea86495aef2f6de26b7cb1599ba350dd6a0c521 ]

The BGRT code validates the contents of the table against the UEFI
memory map, and so it expects it to be mapped when the code runs.

On ARM, this is currently not the case, since we tear down the early
mapping after efi_init() completes, and only create the permanent
mapping in arm_enable_runtime_services(), which executes as an early
initcall, but still leaves a window where the UEFI memory map is not
mapped.

So move the call to efi_memmap_unmap() from efi_init() to
arm_enable_runtime_services().

Signed-off-by: Ard Biesheuvel 
[will: fold in EFI_MEMMAP attribute check from Ard]
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

firmware: dmi_scan: Fix handling of empty DMI strings

2018-05-30T05:50:24+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

firmware/psci: Expose SMCCC version through psci_ops

2018-04-20T06:21:05+00:00

From: Marc Zyngier 

commit e78eef554a912ef6c1e0bbf97619dafbeae3339f upstream.

Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed,
let's do that at boot time, and expose the version of the calling
convention as part of the psci_ops structure.

Acked-by: Lorenzo Pieralisi 
Reviewed-by: Robin Murphy 
Tested-by: Ard Biesheuvel 
Signed-off-by: Marc Zyngier 
Signed-off-by: Catalin Marinas 
Signed-off-by: Mark Rutland  [v4.9 backport]
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman

firmware/psci: Expose PSCI conduit

2018-04-20T06:21:05+00:00

From: Marc Zyngier 

commit 09a8d6d48499f93e2abde691f5800081cd858726 upstream.

In order to call into the firmware to apply workarounds, it is
useful to find out whether we're using HVC or SMC. Let's expose
this through the psci_ops.

Acked-by: Lorenzo Pieralisi 
Reviewed-by: Robin Murphy 
Tested-by: Ard Biesheuvel 
Signed-off-by: Marc Zyngier 
Signed-off-by: Catalin Marinas 
Signed-off-by: Mark Rutland  [v4.9 backport]
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman

drivers/firmware: Expose psci_get_version through psci_ops structure

2018-04-20T06:20:43+00:00

From: Will Deacon 

commit d68e3ba5303f7e1099f51fdcd155f5263da8569b upstream.

Entry into recent versions of ARM Trusted Firmware will invalidate the CPU
branch predictor state in order to protect against aliasing attacks.

This patch exposes the PSCI "VERSION" function via psci_ops, so that it
can be invoked outside of the PSCI driver where necessary.

Acked-by: Lorenzo Pieralisi 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Mark Rutland  [v4.9 backport]
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman

efi/esrt: Cleanup bad memory map log messages

2017-12-20T09:07:26+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/esrt: Use memunmap() instead of kfree() to free the remapping

2017-12-14T08:28:11+00:00

commit 89c5a2d34bda58319e3075e8e7dd727ea25a435c upstream.

The remapping result of memremap() should be freed with memunmap(), not kfree().

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

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

2017-12-14T08:28:11+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

efi/libstub: Skip GOP with PIXEL_BLT_ONLY format

2017-04-21T07:31:20+00:00

commit 540f4c0e894f7e46a66dfa424b16424cbdc12c38 upstream.

The UEFI Specification permits Graphics Output Protocol (GOP) instances
without direct framebuffer access. This is indicated in the Mode structure
with a PixelFormat enumeration value of PIXEL_BLT_ONLY. Given that the
kernel does not know how to drive a Blt() only framebuffer (which is only
permitted before ExitBootServices() anyway), we should disregard such
framebuffers when looking for a GOP instance that is suitable for use as
the boot console.

So modify the EFI GOP initialization to not use a PIXEL_BLT_ONLY instance,
preventing attempts later in boot to use an invalid screen_info.lfb_base
address.

Signed-off-by: Eugene Cohen 
[ Moved the Blt() only check into the loop and clarified that Blt() only GOPs are unusable by the kernel. ]
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: leif.lindholm@linaro.org
Cc: linux-efi@vger.kernel.org
Cc: lorenzo.pieralisi@arm.com
Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...")
Link: http://lkml.kernel.org/r/20170404152744.26687-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman