[GIT PULL 0/2] EFI pull requests for v5.20

[Ard Biesheuvel <ardb@kernel.org>]

Hello Linus,

I am sending this cycle's EFI changes as two separate pull requests:
- the first one covers the normal updates accumulated this cycle, including
  some cleanup of the 'efivars' layer;
- the second one removes the obsolete 'efivars' sysfs driver, and consolidates
  the remaining code related to manipulating arbitrary EFI variables from user
  space into the efivarfs pseudo-filesystem driver.

The 'efivars' sysfs interface and the 'efivarfs' (note the 'f')
pseudo-filesystem are both based on an abstraction which is also called
'efivars' that caches EFI variables, and permits the backend to be swapped out,
for backing the EFI variable store by, e.g., SMI calls or other secure firmware
calls. (only used by Google SMI at the moment, but new uses are being
proposed).

Using two cached views of the same variable store leads to the problems you
might expect, and other users also exist that (ab)use the efivars layer for
non-obvious reasons.

Most of the quirks are being cleaned up in 1/2 of this PR series. However, to
really address this thoroughly, we should get rid of the obsolete sysfs based
EFI variable interface for user space, and only keep the efivarfs
pseudo-filesystem. This is what is implemented by 2/2 of this PR series, which
also moves the remaining efivars logic that efivarfs relies on into the
efivarfs driver, and no longer exports it to other parts of the kernel.

Obviously, removing the sysfs interface could potentially break someone's
workflow somewhere, and so it is not without risk. However, as far as I can
infer from things like Debian code search etc, all support libraries that are
in use to access EFI variables will prefer the efivarfs pseudo-filesystem, and
fall back to the sysfs interface otherwise.

The efivarfs pseudo-FS is 'default m' when CONFIG_EFI=y, and all the distros
have switched to it a very long time ago. But individual cases might exist
where a script accesses /sys/firmware/efi/vars/... directly, and this will no
longer work after merging PR 2/2 of this series.

In summary, I am leaving it up to you to pull the trigger on PR 2/2 - if you
prefer to deal with this in a different way, please feel free to disregard the
second PR, and make a suggestion how to address this instead.

Note that the 2/2 changes were put at the end so reverting this should be quite
straight-forward, in case we do decide to merge them and they turn out to be
causing problems.

Thanks,
Ard.