On Wed, Feb 09, 2022 at 06:35:45PM +0000, Matthew Garrett wrote:
The LOAD_UEFI_KEYS code isn't doing anything special here - it's just trying to read some variables. If we simply disable that then the expectation would be that reading the same variables from userland would trigger the same failure. So the question is which of the variables that LOAD_UEFI_KEYS accesses is triggering the failure, and what's special about that? If it's a specific variable GUID or name that's failing, we should block that on Apple hardware in order to avoid issues caused by userland performing equivalent accesses.
ie, can you try something like this?
diff --git a/drivers/firmware/efi/runtime-wrappers.c b/drivers/firmware/efi/runtime-wrappers.c index f3e54f6616f0..01cbd4811d1e 100644 --- a/drivers/firmware/efi/runtime-wrappers.c +++ b/drivers/firmware/efi/runtime-wrappers.c @@ -32,6 +32,8 @@ #include <linux/stringify.h> #include <linux/workqueue.h> #include <linux/completion.h> +#include <linux/ucs2_string.h> +#include <linux/slab.h>
#include <asm/efi.h>
@@ -203,6 +205,21 @@ static void efi_call_rts(struct work_struct *work) (efi_time_t *)arg2); break; case EFI_GET_VARIABLE: + unsigned long utf8_name_size; + char *utf8_name; + char guid_str[sizeof(efi_guid_t)+1]; + + utf8_name_size = ucs2_utf8size((efi_char16_t *)arg1); + utf8_name = kmalloc(utf8_name_size+1, GFP_KERNEL); + if (!utf8_name) { + printk(KERN_INFO "failed to allocate UTF8 buffer\n"); + break; + } + + ucs2_as_utf8(utf8_name, (efi_char16_t *)arg1, utf8_name_size + 1); + efi_guid_to_str((efi_guid_t *)arg2, guid_str); + + printk(KERN_INFO "Reading EFI variable %s-%s\n", utf8_name, guid_str); status = efi_call_virt(get_variable, (efi_char16_t *)arg1, (efi_guid_t *)arg2, (u32 *)arg3, (unsigned long *)arg4, (void *)arg5);