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);
