From: Ard Biesheuvel <ardb@kernel.org>
To: linux-efi@vger.kernel.org
Cc: keescook@chromium.org, Ard Biesheuvel <ardb@kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Arend van Spriel <aspriel@gmail.com>,
Franky Lin <franky.lin@broadcom.com>,
Hante Meuleman <hante.meuleman@broadcom.com>,
Kalle Valo <kvalo@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Gregory Greenman <gregory.greenman@intel.com>,
linux-input@vger.kernel.org, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
Subject: [PATCH 1/4] efi: avoid efivars layer when loading SSDTs from variables
Date: Fri, 17 Jun 2022 19:48:48 +0200 [thread overview]
Message-ID: <20220617174851.1286026-2-ardb@kernel.org> (raw)
In-Reply-To: <20220617174851.1286026-1-ardb@kernel.org>
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>
---
drivers/firmware/efi/efi.c | 103 ++++++++------------
1 file changed, 41 insertions(+), 62 deletions(-)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 860534bcfdac..630c18618f6a 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -202,7 +202,7 @@ static void generic_ops_unregister(void)
}
#ifdef CONFIG_EFI_CUSTOM_SSDT_OVERLAYS
-#define EFIVAR_SSDT_NAME_MAX 16
+#define EFIVAR_SSDT_NAME_MAX 16UL
static char efivar_ssdt[EFIVAR_SSDT_NAME_MAX] __initdata;
static int __init efivar_ssdt_setup(char *str)
{
@@ -219,83 +219,62 @@ static int __init efivar_ssdt_setup(char *str)
}
__setup("efivar_ssdt=", efivar_ssdt_setup);
-static __init int efivar_ssdt_iter(efi_char16_t *name, efi_guid_t vendor,
- unsigned long name_size, void *data)
-{
- struct efivar_entry *entry;
- struct list_head *list = data;
- char utf8_name[EFIVAR_SSDT_NAME_MAX];
- int limit = min_t(unsigned long, EFIVAR_SSDT_NAME_MAX, name_size);
-
- ucs2_as_utf8(utf8_name, name, limit - 1);
- if (strncmp(utf8_name, efivar_ssdt, limit) != 0)
- return 0;
-
- entry = kmalloc(sizeof(*entry), GFP_KERNEL);
- if (!entry)
- return 0;
-
- memcpy(entry->var.VariableName, name, name_size);
- memcpy(&entry->var.VendorGuid, &vendor, sizeof(efi_guid_t));
-
- efivar_entry_add(entry, list);
-
- return 0;
-}
-
static __init int efivar_ssdt_load(void)
{
- LIST_HEAD(entries);
- struct efivar_entry *entry, *aux;
- unsigned long size;
- void *data;
- int ret;
+ unsigned long name_size = 256;
+ efi_char16_t *name = NULL;
+ efi_status_t status;
+ efi_guid_t guid;
if (!efivar_ssdt[0])
return 0;
- ret = efivar_init(efivar_ssdt_iter, &entries, true, &entries);
-
- list_for_each_entry_safe(entry, aux, &entries, list) {
- pr_info("loading SSDT from variable %s-%pUl\n", efivar_ssdt,
- &entry->var.VendorGuid);
+ name = kzalloc(name_size, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
- list_del(&entry->list);
+ for (;;) {
+ char utf8_name[EFIVAR_SSDT_NAME_MAX];
+ unsigned long data_size = 0;
+ void *data;
+ int limit;
- ret = efivar_entry_size(entry, &size);
- if (ret) {
- pr_err("failed to get var size\n");
- goto free_entry;
+ status = efi.get_next_variable(&name_size, name, &guid);
+ if (status == EFI_NOT_FOUND) {
+ break;
+ } else if (status == EFI_BUFFER_TOO_SMALL) {
+ name = krealloc(name, name_size, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
+ continue;
}
- data = kmalloc(size, GFP_KERNEL);
- if (!data) {
- ret = -ENOMEM;
- goto free_entry;
- }
+ limit = min(EFIVAR_SSDT_NAME_MAX, name_size);
+ ucs2_as_utf8(utf8_name, name, limit - 1);
+ if (strncmp(utf8_name, efivar_ssdt, limit) != 0)
+ continue;
- ret = efivar_entry_get(entry, NULL, &size, data);
- if (ret) {
- pr_err("failed to get var data\n");
- goto free_data;
- }
+ pr_info("loading SSDT from variable %s-%pUl\n", efivar_ssdt, &guid);
- ret = acpi_load_table(data, NULL);
- if (ret) {
- pr_err("failed to load table: %d\n", ret);
- goto free_data;
- }
+ status = efi.get_variable(name, &guid, NULL, &data_size, NULL);
+ if (status != EFI_BUFFER_TOO_SMALL || !data_size)
+ return -EIO;
- goto free_entry;
+ data = kmalloc(data_size, GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
-free_data:
+ status = efi.get_variable(name, &guid, NULL, &data_size, data);
+ if (status == EFI_SUCCESS) {
+ acpi_status ret = acpi_load_table(data, NULL);
+ if (ret)
+ pr_err("failed to load table: %u\n", ret);
+ } else {
+ pr_err("failed to get var data: 0x%lx\n", status);
+ }
kfree(data);
-
-free_entry:
- kfree(entry);
}
-
- return ret;
+ return 0;
}
#else
static inline int efivar_ssdt_load(void) { return 0; }
--
2.35.1
next prev parent reply other threads:[~2022-06-17 17:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-17 17:48 [PATCH 0/4] efivar: remove inappropriate uses of the efivar API Ard Biesheuvel
2022-06-17 17:48 ` Ard Biesheuvel [this message]
2022-06-17 17:48 ` [PATCH 2/4] Input: applespi - avoid efivars API and invoke EFI services directly Ard Biesheuvel
2022-06-17 17:48 ` [PATCH 3/4] iwlwifi: Switch to proper EFI variable store interface Ard Biesheuvel
2022-06-17 17:48 ` [PATCH 4/4] brcmfmac: Switch to appropriate helper to load EFI variable contents Ard Biesheuvel
2022-06-20 9:00 ` [PATCH 0/4] efivar: remove inappropriate uses of the efivar API Kalle Valo
2022-06-21 16:19 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220617174851.1286026-2-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=aspriel@gmail.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=davem@davemloft.net \
--cc=dmitry.torokhov@gmail.com \
--cc=edumazet@google.com \
--cc=franky.lin@broadcom.com \
--cc=gregory.greenman@intel.com \
--cc=hante.meuleman@broadcom.com \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).