From: Tim Schumacher <timschumi@gmx.de>
To: linux-efi@vger.kernel.org
Cc: Tim Schumacher <timschumi@gmx.de>,
jk@ozlabs.org, ardb@kernel.org, mjg59@srcf.ucam.org,
pjones@redhat.com, linux-kernel@vger.kernel.org
Subject: [PATCH v2] efivarfs: Halve name buffer size until first successful response
Date: Tue, 23 Jan 2024 21:27:42 +0100 [thread overview]
Message-ID: <20240123202743.1591165-1-timschumi@gmx.de> (raw)
In-Reply-To: <20240122231507.1307793-1-timschumi@gmx.de>
This sidesteps a quirk in a few old (2011-ish) UEFI implementations,
where a call to `GetNextVariableName` with a buffer size larger than 512
bytes will always return `EFI_INVALID_PARAMETER`.
Additionally, remove a related but outdated comment that claims the
maximum variable name size to be 1024. The default buffer size of 1024
is kept to ensure that existing setups keep working.
Cc: stable@vger.kernel.org # 6.1+
Signed-off-by: Tim Schumacher <timschumi@gmx.de>
---
Changes since v1 ("efivarfs: Iterate variables with increasing name buffer sizes"):
- Redid the logic to start with the current limit of 1024 and continuously
halve it until we get a successful result.
- Added a warning line in case we find anything that is bigger than the limit.
- Removed an outdated (or never accurate?) comment about a specification-imposed
length limit.
---
fs/efivarfs/vars.c | 31 +++++++++++++++++++++++--------
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/fs/efivarfs/vars.c b/fs/efivarfs/vars.c
index 9e4f47808bd5..26a10ed4a116 100644
--- a/fs/efivarfs/vars.c
+++ b/fs/efivarfs/vars.c
@@ -372,13 +372,14 @@ static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
void *data, bool duplicates, struct list_head *head)
{
- unsigned long variable_name_size = 1024;
+ unsigned long maximum_variable_name_size = 1024;
efi_char16_t *variable_name;
efi_status_t status;
efi_guid_t vendor_guid;
int err = 0;
+ bool successful_once = false;
- variable_name = kzalloc(variable_name_size, GFP_KERNEL);
+ variable_name = kzalloc(maximum_variable_name_size, GFP_KERNEL);
if (!variable_name) {
printk(KERN_ERR "efivars: Memory allocation failed.\n");
return -ENOMEM;
@@ -388,19 +389,16 @@ int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
if (err)
goto free;
- /*
- * Per EFI spec, the maximum storage allocated for both
- * the variable name and variable data is 1024 bytes.
- */
-
do {
- variable_name_size = 1024;
+ unsigned long variable_name_size = maximum_variable_name_size;
status = efivar_get_next_variable(&variable_name_size,
variable_name,
&vendor_guid);
switch (status) {
case EFI_SUCCESS:
+ successful_once = true;
+
variable_name_size = var_name_strnsize(variable_name,
variable_name_size);
@@ -431,6 +429,23 @@ int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
break;
case EFI_NOT_FOUND:
break;
+ case EFI_BUFFER_TOO_SMALL:
+ printk(KERN_WARNING "efivars: Assumed maximum name size to be 0x%lx, got name of size 0x%lx\n",
+ maximum_variable_name_size, variable_name_size);
+ status = EFI_NOT_FOUND;
+ break;
+ case EFI_INVALID_PARAMETER:
+ if (!successful_once && maximum_variable_name_size > 1) {
+ /*
+ * A small set of old UEFI implementations reject sizes
+ * above a certain threshold. Halve the advertised size
+ * until we get the first successful response.
+ */
+ maximum_variable_name_size /= 2;
+ break;
+ }
+
+ fallthrough;
default:
printk(KERN_WARNING "efivars: get_next_variable: status=%lx\n",
status);
--
2.43.0
next prev parent reply other threads:[~2024-01-23 20:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 23:15 [PATCH] efivarfs: Iterate variables with increasing name buffer sizes Tim Schumacher
2024-01-23 11:24 ` Ard Biesheuvel
2024-01-23 13:55 ` Tim Schumacher
2024-01-23 14:09 ` Ard Biesheuvel
2024-01-23 17:33 ` Tim Schumacher
2024-01-24 21:25 ` Peter Jones
2024-01-25 8:12 ` Ard Biesheuvel
2024-04-13 10:47 ` Tim Schumacher
2024-01-23 20:27 ` Tim Schumacher [this message]
2024-01-26 16:25 ` [PATCH v3] efivarfs: Request at most 512 bytes for variable names Tim Schumacher
2024-01-26 16:35 ` Ard Biesheuvel
2024-01-26 18:02 ` Tim Schumacher
2024-01-30 16:00 ` Tim Schumacher
2024-02-14 15:18 ` 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=20240123202743.1591165-1-timschumi@gmx.de \
--to=timschumi@gmx.de \
--cc=ardb@kernel.org \
--cc=jk@ozlabs.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=pjones@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