linux/drivers/firmware/efi/vars.c

260 lines
5.9 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0+
/*
* Originally from efivars.c
*
* Copyright (C) 2001,2003,2004 Dell <Matt_Domsch@dell.com>
* Copyright (C) 2004 Intel Corporation <matthew.e.tolentino@intel.com>
*/
#define pr_fmt(fmt) "efivars: " fmt
#include <linux/types.h>
#include <linux/sizes.h>
#include <linux/errno.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/string.h>
#include <linux/smp.h>
#include <linux/efi.h>
#include <linux/ucs2_string.h>
/* Private pointer to registered efivars */
static struct efivars *__efivars;
static DEFINE_SEMAPHORE(efivars_lock, 1);
static efi_status_t check_var_size(bool nonblocking, u32 attributes,
unsigned long size)
{
firmware/efi: Add NULL pointer checks in efivars API functions Since commit: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI variables") we have a device driver accessing the efivars API. Several functions in the efivars API assume __efivars is set, i.e., that they will be accessed only after efivars_register() has been called. However, the following NULL pointer access was reported calling efivar_entry_size() from the brcmfmac device driver: Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = 60bfa5f1 [00000008] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM ... Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) Workqueue: events request_firmware_work_func PC is at efivar_entry_size+0x28/0x90 LR is at brcmf_fw_complete_request+0x3f8/0x8d4 [brcmfmac] pc : [<c0c40718>] lr : [<bf2a3ef4>] psr: a00d0113 sp : ede7fe28 ip : ee983410 fp : c1787f30 r10: 00000000 r9 : 00000000 r8 : bf2b2258 r7 : ee983000 r6 : c1604c48 r5 : ede7fe88 r4 : edf337c0 r3 : 00000000 r2 : 00000000 r1 : ede7fe88 r0 : c17712c8 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: ad16804a DAC: 00000051 Disassembly showed that the local static variable __efivars is NULL, which is not entirely unexpected given that it is a non-EFI platform. So add a NULL pointer check to efivar_entry_size(), and to related functions while at it. In efivars_register() a couple of sanity checks are added as well. Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Bhupesh Sharma <bhsharma@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Eric Snowberg <eric.snowberg@oracle.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Joe Perches <joe@perches.com> Cc: Julien Thierry <julien.thierry@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Cc: Sedat Dilek <sedat.dilek@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: YiFei Zhu <zhuyifei1999@gmail.com> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20181129171230.18699-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-11-29 20:12:27 +03:00
const struct efivar_operations *fops;
efi_status_t status;
firmware/efi: Add NULL pointer checks in efivars API functions Since commit: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI variables") we have a device driver accessing the efivars API. Several functions in the efivars API assume __efivars is set, i.e., that they will be accessed only after efivars_register() has been called. However, the following NULL pointer access was reported calling efivar_entry_size() from the brcmfmac device driver: Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = 60bfa5f1 [00000008] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM ... Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) Workqueue: events request_firmware_work_func PC is at efivar_entry_size+0x28/0x90 LR is at brcmf_fw_complete_request+0x3f8/0x8d4 [brcmfmac] pc : [<c0c40718>] lr : [<bf2a3ef4>] psr: a00d0113 sp : ede7fe28 ip : ee983410 fp : c1787f30 r10: 00000000 r9 : 00000000 r8 : bf2b2258 r7 : ee983000 r6 : c1604c48 r5 : ede7fe88 r4 : edf337c0 r3 : 00000000 r2 : 00000000 r1 : ede7fe88 r0 : c17712c8 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: ad16804a DAC: 00000051 Disassembly showed that the local static variable __efivars is NULL, which is not entirely unexpected given that it is a non-EFI platform. So add a NULL pointer check to efivar_entry_size(), and to related functions while at it. In efivars_register() a couple of sanity checks are added as well. Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Bhupesh Sharma <bhsharma@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Eric Snowberg <eric.snowberg@oracle.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Joe Perches <joe@perches.com> Cc: Julien Thierry <julien.thierry@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Cc: Sedat Dilek <sedat.dilek@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: YiFei Zhu <zhuyifei1999@gmail.com> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20181129171230.18699-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-11-29 20:12:27 +03:00
fops = __efivars->ops;
if (!fops->query_variable_store)
status = EFI_UNSUPPORTED;
else
status = fops->query_variable_store(attributes, size,
nonblocking);
if (status == EFI_UNSUPPORTED)
return (size <= SZ_64K) ? EFI_SUCCESS : EFI_OUT_OF_RESOURCES;
return status;
}
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
/**
* efivar_is_available - check if efivars is available
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
*
* @return true iff evivars is currently registered
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
*/
bool efivar_is_available(void)
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
{
return __efivars != NULL;
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
}
EXPORT_SYMBOL_GPL(efivar_is_available);
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
/**
* efivars_register - register an efivars
* @efivars: efivars to register
* @ops: efivars operations
*
* Only a single efivars can be registered at any time.
*/
int efivars_register(struct efivars *efivars,
const struct efivar_operations *ops)
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
{
int rv;
if (down_interruptible(&efivars_lock))
return -EINTR;
if (__efivars) {
pr_warn("efivars already registered\n");
rv = -EBUSY;
goto out;
}
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
efivars->ops = ops;
__efivars = efivars;
pr_info("Registered efivars operations\n");
rv = 0;
out:
up(&efivars_lock);
return rv;
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
}
EXPORT_SYMBOL_GPL(efivars_register);
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
/**
* efivars_unregister - unregister an efivars
* @efivars: efivars to unregister
*
* The caller must have already removed every entry from the list,
* failure to do so is an error.
*/
int efivars_unregister(struct efivars *efivars)
{
int rv;
if (down_interruptible(&efivars_lock))
return -EINTR;
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
if (!__efivars) {
pr_err("efivars not registered\n");
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
rv = -EINVAL;
goto out;
}
if (__efivars != efivars) {
rv = -EINVAL;
goto out;
}
pr_info("Unregistered efivars operations\n");
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
__efivars = NULL;
rv = 0;
out:
up(&efivars_lock);
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
return rv;
}
efivars: efivar_entry API There isn't really a formal interface for dealing with EFI variables or struct efivar_entry. Historically, this has led to various bits of code directly accessing the generic EFI variable ops, which inherently ties it to specific EFI variable operations instead of indirectly using whatever ops were registered with register_efivars(). This lead to the efivarfs code only working with the generic EFI variable ops and not CONFIG_GOOGLE_SMI. Encapsulate everything that needs to access '__efivars' inside an efivar_entry_* API and use the new API in the pstore, sysfs and efivarfs code. Much of the efivars code had to be rewritten to use this new API. For instance, it is now up to the users of the API to build the initial list of EFI variables in their efivar_init() callback function. The variable list needs to be passed to efivar_init() which allows us to keep work arounds for things like implementation bugs in GetNextVariable() in a central location. Allowing users of the API to use a callback function to build the list greatly benefits the efivarfs code which needs to allocate inodes and dentries for every variable. It previously did this in a racy way because the code ran without holding the variable spinlock. Both the sysfs and efivarfs code maintain their own lists which means the two interfaces can be running simultaneously without interference, though it should be noted that because no synchronisation is performed it is very easy to create inconsistencies. efibootmgr doesn't currently use efivarfs and users are likely to also require the old sysfs interface, so it makes sense to allow both to be built. Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-02-04 00:16:40 +04:00
EXPORT_SYMBOL_GPL(efivars_unregister);
efi/efivars: Expose RT service availability via efivars abstraction Commit bf67fad19e493b ("efi: Use more granular check for availability for variable services") introduced a check into the efivarfs, efi-pstore and other drivers that aborts loading of the module if not all three variable runtime services (GetVariable, SetVariable and GetNextVariable) are supported. However, this results in efivarfs being unavailable entirely if only SetVariable support is missing, which is only needed if you want to make any modifications. Also, efi-pstore and the sysfs EFI variable interface could be backed by another implementation of the 'efivars' abstraction, in which case it is completely irrelevant which services are supported by the EFI firmware. So make the generic 'efivars' abstraction dependent on the availibility of the GetVariable and GetNextVariable EFI runtime services, and add a helper 'efivar_supports_writes()' to find out whether the currently active efivars abstraction supports writes (and wire it up to the availability of SetVariable for the generic one). Then, use the efivar_supports_writes() helper to decide whether to permit efivarfs to be mounted read-write, and whether to enable efi-pstore or the sysfs EFI variable interface altogether. Fixes: bf67fad19e493b ("efi: Use more granular check for availability for variable services") Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-07-08 13:01:57 +03:00
bool efivar_supports_writes(void)
efi/efivars: Expose RT service availability via efivars abstraction Commit bf67fad19e493b ("efi: Use more granular check for availability for variable services") introduced a check into the efivarfs, efi-pstore and other drivers that aborts loading of the module if not all three variable runtime services (GetVariable, SetVariable and GetNextVariable) are supported. However, this results in efivarfs being unavailable entirely if only SetVariable support is missing, which is only needed if you want to make any modifications. Also, efi-pstore and the sysfs EFI variable interface could be backed by another implementation of the 'efivars' abstraction, in which case it is completely irrelevant which services are supported by the EFI firmware. So make the generic 'efivars' abstraction dependent on the availibility of the GetVariable and GetNextVariable EFI runtime services, and add a helper 'efivar_supports_writes()' to find out whether the currently active efivars abstraction supports writes (and wire it up to the availability of SetVariable for the generic one). Then, use the efivar_supports_writes() helper to decide whether to permit efivarfs to be mounted read-write, and whether to enable efi-pstore or the sysfs EFI variable interface altogether. Fixes: bf67fad19e493b ("efi: Use more granular check for availability for variable services") Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-07-08 13:01:57 +03:00
{
return __efivars && __efivars->ops->set_variable;
}
EXPORT_SYMBOL_GPL(efivar_supports_writes);
/*
* efivar_lock() - obtain the efivar lock, wait for it if needed
* @return 0 on success, error code on failure
*/
int efivar_lock(void)
{
if (down_interruptible(&efivars_lock))
return -EINTR;
if (!__efivars->ops) {
up(&efivars_lock);
return -ENODEV;
}
return 0;
}
EXPORT_SYMBOL_NS_GPL(efivar_lock, EFIVAR);
/*
* efivar_lock() - obtain the efivar lock if it is free
* @return 0 on success, error code on failure
*/
int efivar_trylock(void)
{
if (down_trylock(&efivars_lock))
return -EBUSY;
if (!__efivars->ops) {
up(&efivars_lock);
return -ENODEV;
}
return 0;
}
EXPORT_SYMBOL_NS_GPL(efivar_trylock, EFIVAR);
/*
* efivar_unlock() - release the efivar lock
*/
void efivar_unlock(void)
{
up(&efivars_lock);
}
EXPORT_SYMBOL_NS_GPL(efivar_unlock, EFIVAR);
/*
* efivar_get_variable() - retrieve a variable identified by name/vendor
*
* Must be called with efivars_lock held.
*/
efi_status_t efivar_get_variable(efi_char16_t *name, efi_guid_t *vendor,
u32 *attr, unsigned long *size, void *data)
{
return __efivars->ops->get_variable(name, vendor, attr, size, data);
}
EXPORT_SYMBOL_NS_GPL(efivar_get_variable, EFIVAR);
/*
* efivar_get_next_variable() - enumerate the next name/vendor pair
*
* Must be called with efivars_lock held.
*/
efi_status_t efivar_get_next_variable(unsigned long *name_size,
efi_char16_t *name, efi_guid_t *vendor)
{
return __efivars->ops->get_next_variable(name_size, name, vendor);
}
EXPORT_SYMBOL_NS_GPL(efivar_get_next_variable, EFIVAR);
/*
* efivar_set_variable_locked() - set a variable identified by name/vendor
*
* Must be called with efivars_lock held. If @nonblocking is set, it will use
* non-blocking primitives so it is guaranteed not to sleep.
*/
efi_status_t efivar_set_variable_locked(efi_char16_t *name, efi_guid_t *vendor,
u32 attr, unsigned long data_size,
void *data, bool nonblocking)
{
efi_set_variable_t *setvar;
efi_status_t status;
if (data_size > 0) {
status = check_var_size(nonblocking, attr,
data_size + ucs2_strsize(name, 1024));
if (status != EFI_SUCCESS)
return status;
}
/*
* If no _nonblocking variant exists, the ordinary one
* is assumed to be non-blocking.
*/
setvar = __efivars->ops->set_variable_nonblocking;
if (!setvar || !nonblocking)
setvar = __efivars->ops->set_variable;
return setvar(name, vendor, attr, data_size, data);
}
EXPORT_SYMBOL_NS_GPL(efivar_set_variable_locked, EFIVAR);
/*
* efivar_set_variable() - set a variable identified by name/vendor
*
* Can be called without holding the efivars_lock. Will sleep on obtaining the
* lock, or on obtaining other locks that are needed in order to complete the
* call.
*/
efi_status_t efivar_set_variable(efi_char16_t *name, efi_guid_t *vendor,
u32 attr, unsigned long data_size, void *data)
{
efi_status_t status;
if (efivar_lock())
return EFI_ABORTED;
status = efivar_set_variable_locked(name, vendor, attr, data_size,
data, false);
efivar_unlock();
return status;
}
EXPORT_SYMBOL_NS_GPL(efivar_set_variable, EFIVAR);
efi_status_t efivar_query_variable_info(u32 attr,
u64 *storage_space,
u64 *remaining_space,
u64 *max_variable_size)
{
if (!__efivars->ops->query_variable_info)
return EFI_UNSUPPORTED;
return __efivars->ops->query_variable_info(attr, storage_space,
remaining_space, max_variable_size);
}
EXPORT_SYMBOL_NS_GPL(efivar_query_variable_info, EFIVAR);