linux-stable.git/drivers/firmware, branch v5.7.5

efi/libstub/random: Align allocate size to EFI_ALLOC_ALIGN

2020-06-22T07:32:32+00:00

[ Upstream commit e1df73e2d18b3b7d66f2ec38d81d9566b3a7fb21 ]

The EFI stub uses a per-architecture #define for the minimum base
and size alignment of page allocations, which is set to 4 KB for
all architecures except arm64, which uses 64 KB, to ensure that
allocations can always be (un)mapped efficiently, regardless of
the page size used by the kernel proper, which could be a kexec'ee

The API wrappers around page based allocations assume that this
alignment is always taken into account, and so efi_free() will
also round up its size argument to EFI_ALLOC_ALIGN.

Currently, efi_random_alloc() does not honour this alignment for
the allocated size, and so freeing such an allocation may result
in unrelated memory to be freed, potentially leading to issues
after boot. So let's round up size in efi_random_alloc() as well.

Fixes: 2ddbfc81eac84a29 ("efi: stub: add implementation of efi_random_alloc()")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

efi/libstub/x86: Work around LLVM ELF quirk build regression

2020-06-22T07:32:20+00:00

[ Upstream commit f77767ed5f4d398b29119563155e4ece2dfeee13 ]

When building the x86 EFI stub with Clang, the libstub Makefile rules
that manipulate the ELF object files may throw an error like:

    STUBCPY drivers/firmware/efi/libstub/efi-stub-helper.stub.o
  strip: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10
  objcopy: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10

This is the result of a LLVM feature [0] where symbol references are
stored in a LLVM specific .llvm_addrsig section in a non-transparent way,
causing generic ELF tools such as strip or objcopy to choke on them.

So force the compiler not to emit these sections, by passing the
appropriate command line option.

[0] https://sourceware.org/bugzilla/show_bug.cgi?id=23817

Cc: Nick Desaulniers 
Cc: Peter Collingbourne 
Cc: Sami Tolvanen 
Reported-by: Arnd Bergmann 
Suggested-by: Fangrui Song 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

firmware: imx: scu: Fix corruption of header

2020-06-17T14:42:56+00:00

[ Upstream commit f5f27b79eab80de0287c243a22169e4876b08d5e ]

The header of the message to send can be changed if the
response is longer than the request:
 - 1st word, the header is sent
 - the remaining words of the message are sent
 - the response is received asynchronously during the
   execution of the loop, changing the size field in
   the header
 - the for loop test the termination condition using
   the corrupted header

It is the case for the API build_info which has just a
header as request but 3 words in response.

This issue is fixed storing the header locally instead of
using a pointer on it.

Fixes: edbee095fafb (firmware: imx: add SCU firmware driver support)

Signed-off-by: Franck LENORMAND 
Reviewed-by: Leonard Crestez 
Signed-off-by: Leonard Crestez 
Cc: stable@vger.kernel.org
Reviewed-by: Dong Aisheng 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

firmware: imx-scu: Support one TX and one RX

2020-06-17T14:42:56+00:00

[ Upstream commit f25a066d1a07affb7bea4e5d9c179c3338338e23 ]

Current imx-scu requires four TX and four RX to communicate with
SCU. This is low efficient and causes lots of mailbox interrupts.

With imx-mailbox driver could support one TX to use all four transmit
registers and one RX to use all four receive registers, imx-scu
could use one TX and one RX.

Signed-off-by: Peng Fan 
Signed-off-by: Shawn Guo 
Signed-off-by: Sasha Levin

efi/efivars: Add missing kobject_put() in sysfs entry creation error path

2020-06-17T14:42:51+00:00

commit d8bd8c6e2cfab8b78b537715255be8d7557791c0 upstream.

The documentation provided by kobject_init_and_add() clearly spells out
the need to call kobject_put() on the kobject if an error is returned.
Add this missing call to the error path.

Cc: 
Reported-by: 亿一 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'efi-fixes-for-v5.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/urgent

2020-05-22T18:06:25+00:00

Pull EFI fixes from Ard Biesheuvel:

"- fix EFI framebuffer earlycon for wide fonts
 - avoid filling screen_info with garbage if the EFI framebuffer is not
   available
 - fix a potential host tool build error due to a symbol clash on x86
 - work around a EFI firmware bug regarding the binary format of the TPM
   final events table
 - fix a missing memory free by reworking the E820 table sizing routine to
   not do the allocation in the first place
 - add CPER parsing for firmware errors"

tpm: check event log version before reading final events

2020-05-17T09:46:50+00:00

This fixes the boot issues since 5.3 on several Dell models when the TPM
is enabled. Depending on the exact grub binary, booting the kernel would
freeze early, or just report an error parsing the final events log.

We get an event log in the SHA-1 format, which doesn't have a
tcg_efi_specid_event_head in the first event, and there is a final events
table which doesn't match the crypto agile format.
__calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and
either fails, or loops long enough for the machine to be appear frozen.

So we now only parse the final events table, which is per the spec always
supposed to be in the crypto agile format, when we got a event log in this
format.

Fixes: c46f3405692de ("tpm: Reserve the TPM final events table")
Fixes: 166a2809d65b2 ("tpm: Don't duplicate events from the final event log in the TCG2 log")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611
Signed-off-by: Loïc Yhuel 
Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yhuel@gmail.com
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Jerry Snitselaar 
Reviewed-by: Matthew Garrett 
[ardb: warn when final events table is missing or in the wrong format]
Signed-off-by: Ard Biesheuvel

efi: Pull up arch-specific prototype efi_systab_show_arch()

2020-05-17T09:46:50+00:00

Pull up arch-specific prototype efi_systab_show_arch() in order to
fix a -Wmissing-prototypes warning:

arch/x86/platform/efi/efi.c:957:7: warning: no previous prototype for
‘efi_systab_show_arch’ [-Wmissing-prototypes]
char *efi_systab_show_arch(char *str)

Signed-off-by: Benjamin Thiel 
Link: https://lore.kernel.org/r/20200516132647.14568-1-b.thiel@posteo.de
Signed-off-by: Ard Biesheuvel

efi: cper: Add support for printing Firmware Error Record Reference

2020-05-14T09:11:20+00:00

While debugging a boot failure, the following unknown error record was
seen in the boot logs.

    <...>
    BERT: Error records from previous boot:
    [Hardware Error]: event severity: fatal
    [Hardware Error]:  Error 0, type: fatal
    [Hardware Error]:   section type: unknown, 81212a96-09ed-4996-9471-8d729c8e69ed
    [Hardware Error]:   section length: 0x290
    [Hardware Error]:   00000000: 00000001 00000000 00000000 00020002  ................
    [Hardware Error]:   00000010: 00020002 0000001f 00000320 00000000  ........ .......
    [Hardware Error]:   00000020: 00000000 00000000 00000000 00000000  ................
    [Hardware Error]:   00000030: 00000000 00000000 00000000 00000000  ................
    <...>

On further investigation, it was found that the error record with
UUID (81212a96-09ed-4996-9471-8d729c8e69ed) has been defined in the
UEFI Specification at least since v2.4 and has recently had additional
fields defined in v2.7 Section N.2.10 Firmware Error Record Reference.

Add support for parsing and printing the defined fields to give users
a chance to figure out what went wrong.

Signed-off-by: Punit Agrawal 
Cc: Ard Biesheuvel 
Cc: "Rafael J. Wysocki" 
Cc: Borislav Petkov 
Cc: James Morse 
Cc: linux-acpi@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Link: https://lore.kernel.org/r/20200512045502.3810339-1-punit1.agrawal@toshiba.co.jp
Signed-off-by: Ard Biesheuvel

efi/libstub/x86: Avoid EFI map buffer alloc in allocate_e820()

2020-05-14T09:11:18+00:00

In allocate_e820(), call the EFI get_memory_map() service directly
instead of indirectly via efi_get_memory_map(). This avoids allocation
of a buffer and return of the full EFI memory map, which is not needed
here and would otherwise need to be freed.

Routine allocate_e820() only needs to know how many EFI memory
descriptors there are in the map to allocate an adequately sized
e820ext buffer, if it's needed. Note that since efi_get_memory_map()
returns a memory map buffer sized with extra headroom, allocate_e820()
now needs to explicitly factor that into the e820ext size calculation.

Signed-off-by: Lenny Szubowicz 
Suggested-by: Ard Biesheuvel 
Signed-off-by: Ard Biesheuvel