Commits · 859748255b43460685e93a1f8a40b8cdc3be02f2 · Kirill Smelkov / linux

24 Jun, 2022 6 commits

efi: pstore: Omit efivars caching EFI varstore access layer · 85974825

Ard Biesheuvel authored Jun 20, 2022

Avoid the efivars layer and simply call the newly introduced EFI
varstore helpers instead. This simplifies the code substantially, and
also allows us to remove some hacks in the shared efivars layer that
were added for efi-pstore specifically.

In order to be able to delete the EFI variable associated with a record,
store the UTF-16 name of the variable in the pstore record's priv field.
That way, we don't have to make guesses regarding which variable the
record may have been loaded from.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

85974825

efi: vars: Add thin wrapper around EFI get/set variable interface · 472831d4

Ard Biesheuvel authored Jun 20, 2022

The current efivars layer is a jumble of list iterators, shadow data
structures and safe variable manipulation helpers that really belong in
the efivarfs pseudo file system once the obsolete sysfs access method to
EFI variables is removed.

So split off a minimal efivar get/set variable API that reuses the
existing efivars_lock semaphore to mediate access to the various runtime
services, primarily to ensure that performing a SetVariable() on one CPU
while another is calling GetNextVariable() in a loop to enumerate the
contents of the EFI variable store does not result in surprises.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

472831d4

efi: vars: Don't drop lock in the middle of efivar_init() · ec3507b2

Ard Biesheuvel authored Jun 20, 2022

Even though the efivars_lock lock is documented as protecting the
efivars->ops pointer (among other things), efivar_init() happily
releases and reacquires the lock for every EFI variable that it
enumerates. This used to be needed because the lock was originally a
spinlock, which prevented the callback that is invoked for every
variable from being able to sleep. However, releasing the lock could
potentially invalidate the ops pointer, but more importantly, it might
allow a SetVariable() runtime service call to take place concurrently,
and the UEFI spec does not define how this affects an enumeration that
is running in parallel using the GetNextVariable() runtime service,
which is what efivar_init() uses.

In the meantime, the lock has been converted into a semaphore, and the
only reason we need to drop the lock is because the efivarfs pseudo
filesystem driver will otherwise deadlock when it invokes the efivars
API from the callback to create the efivar_entry items and insert them
into the linked list. (EFI pstore is affected in a similar way)

So let's switch to helpers that can be used while the lock is already
taken. This way, we can hold on to the lock throughout the enumeration.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

ec3507b2

pstore: Add priv field to pstore_record for backend specific use · 8ca869b2

Ard Biesheuvel authored Jun 22, 2022

The EFI pstore backend will need to store per-record variable name data
when we switch away from the efivars layer. Add a priv field to struct
pstore_record, and document it as holding a backend specific pointer
that is assumed to be a kmalloc()d buffer, and will be kfree()d when the
entire record is freed.
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

8ca869b2

Input: applespi - avoid efivars API and invoke EFI services directly · f662092b

Ard Biesheuvel authored Jun 17, 2022

This driver abuses the efivar API, by using a few of its helpers on
entries that were not instantiated by the API itself. This is a problem
as future cleanup work on efivars is complicated by this.

So let's just switch to the get/set variable runtime wrappers directly.

Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

f662092b

selftests/kexec: remove broken EFI_VARS secure boot fallback check · c07d2475

Ard Biesheuvel authored Jun 08, 2022

Commit b433a52a ("selftests/kexec: update get_secureboot_mode")
refactored the code that discovers the EFI secure boot mode so it only
depends on either the efivars pseudo filesystem or the efivars sysfs
interface, but never both.

However, the latter version was not implemented correctly, given the
fact that the local 'efi_vars' variable never assumes a value. This
means the fallback has been dead code ever since it was introduced.

So let's drop the fallback altogether. The sysfs interface has been
deprecated for ~10 years now, and is only enabled on x86 to begin with,
so it is time to get rid of it entirely.
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

c07d2475

20 Jun, 2022 5 commits

brcmfmac: Switch to appropriate helper to load EFI variable contents · 98e152c1

Ard Biesheuvel authored Jun 17, 2022

Avoid abusing the efivar layer by invoking it with locally constructed
efivar_entry instances, and instead, just call the EFI routines directly
if available.
Acked-by: Kalle Valo <kvalo@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

98e152c1

iwlwifi: Switch to proper EFI variable store interface · 0c4bad7f

Ard Biesheuvel authored Jun 17, 2022

Using half of the efivar API with locally baked efivar_entry instances
is not the right way to use this API, and these uses impede planned work
on the efivar layer itself.

So switch to direct EFI variable store accesses: we don't need the
efivar layer anyway.
Acked-by: Kalle Valo <kvalo@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

0c4bad7f

media: atomisp_gmin_platform: stop abusing efivar API · 38d4f74b

Ard Biesheuvel authored Jun 20, 2022

As the code comment already suggests, using the efivar API in this way
is not how it is intended, and so let's switch to the right one, which
is simply to call efi.get_variable() directly after checking whether or
not the GetVariable() runtime service is supported.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

38d4f74b

efi: efibc: avoid efivar API for setting variables · 416581e4

Ard Biesheuvel authored Jun 20, 2022

Avoid abusing the efivar API by passing locally instantiated
efivar_entry structs into efivar_set_entry_safe(), rather than using the
API as intended. Instead, just call efi.set_variable() directly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

416581e4

efi: avoid efivars layer when loading SSDTs from variables · 3881ee0b

Ard Biesheuvel authored Jun 17, 2022

The efivars intermediate variable access layer provides an abstraction
that permits the EFI variable store to be replaced by something else
that implements a compatible interface, and caches all variables in the
variable store for fast access via the efivarfs pseudo-filesystem.

The SSDT override feature does not take advantage of either feature, as
it is only used when the generic EFI implementation of efivars is used,
and it traverses all variables only once to find the ones it is
interested in, and frees all data structures that the efivars layer
keeps right after.

So in this case, let's just call EFI's code directly, using the function
pointers in struct efi.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

3881ee0b

15 Jun, 2022 6 commits

efi: Correct comment on efi_memmap_alloc · db01ea88

Liu Zixian authored Jun 14, 2022

Returning zero means success now.
Signed-off-by: Liu Zixian <liuzixian4@huawei.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>