This series adds a sanity check to make sure that the variable services are actually available before registering the generic efivar ops. This is used to address some potential races with custom efivars implementation such as the Google SMI or upcoming Qualcomm SCM ones. Specifically, efivarfs currently requires that the efivar ops have been registered before module init time even though the Google driver can be built as a module. Instead, the driver has so far relied on the fact that the generic ops have been registered by efi core only to later be overridden by the custom implementation (or Google doesn't use efivarfs). Instead, let's move the efivars sanity check to mount time to allow for late registration of efivars. Note that requiring that all efivars implementation to always be built-in and registered before module init time could be an alternative, but we'd still need to make sure that the custom implementation is then not overridden by the default (broken) one. To avoid such init call games, allowing late registration seems preferable. This would however require any drivers that use efivars to probe defer until it becomes available, which is also unfortunate, but possibly still better than having generic kernels carry multiple built-in efivars implementations. Note that there are currently no such (efivars consumer) drivers in-tree except for the efivars_pstore driver, which currently do rely on efivarfs being available at module init time (and hence may fail to initialise with the custom efivar implementations). Johan Johan Hovold (4): efi: efivars: add efivars printk prefix efivarfs: always register filesystem efi: verify that variable services are supported efi: efivars: prevent double registration drivers/firmware/efi/efi.c | 22 ++++++++++++++++++++++ drivers/firmware/efi/vars.c | 17 ++++++++++++++--- fs/efivarfs/super.c | 6 +++--- 3 files changed, 39 insertions(+), 6 deletions(-) -- 2.38.2
