efi: implement mandatory locking for UEFI Runtime Services
PATCH v3 1/1 efi: implement mandatory locking for UEFI Runtime Services
According to section 7.1 of the UEFI spec, Runtime Services are not fully reentrant, and there are particular combinations of calls that need to be serialized. Use a spinlock to serialize all Runtime Services with respect to all others, even if this is more than strictly needed.
---
v3:
Keep value of in_nmi() cached in local scope to help the compiler understand that it cannot change while the function is active
v2:
So this is v2 of the UEFI Runtime Services serialization patch: this time, I use a single spinlock rather than a set of mutexes, resulting in all services to be serialized with respect to all others. Also added handling of NMI state, as this results in some of the restrictions being lifted (x86, ia64 only)
arch/x86/include/asm/efi.h | 2 + drivers/firmware/efi/runtime-wrappers.c | 175 +++++++++++++++++++++++++++++--- 2 files changed, 165 insertions(+), 12 deletions(-)
arch/x86/include/asm/efi.h +2 -0
@@ -86,6 +86,8 @@ extern void __iomem *efi_ioremap(unsigned long addr, unsigned long size,#endif /* CONFIG_X86_32 */ +#define efi_in_nmi () in_nmi() +extern int add_efi_memmap;extern struct efi_scratch efi_scratch;extern void efi_set_executable (efi_memory_desc_t *md,bool executable);
drivers/firmware/efi/runtime-wrappers.c +163 -12
273 lines not on this page · raw message
Signature · 1 line
1.8.3.2
PATCH v3 1/1 efi: implement mandatory locking for UEFI Runtime Services
Quoted 4 lines · Ard Biesheuvel
According to section 7.1 of the UEFI spec, Runtime Services are not fully reentrant, and there are particular combinations of calls that need to be serialized. Use a spinlock to serialize all Runtime Services with respect to all others, even if this is more than strictly needed.
It'd be good to include a point about why we're only using a spinlock, namely that anything else introduces complication to code that is unlikely to be performance critical.
[...]
drivers/firmware/efi/runtime-wrappers.c line 84
Quoted 7 lines
+ *
+ * In order to prevent deadlocks under NMI, the wrappers for these functions
+ * only grab theefi_runtime_lockorrtc_lockspinlocks if !efi_in_nmi().
+ */drivers/firmware/efi/runtime-wrappers.c +3
-0+#ifndef efi_in_nmi +#define efi_in_nmi () (0) +#endif
It shouldn't be necessary to do the NMI checking for *all* runtime services, unless you use, for instance, the timer functions on ARM64.
Quoted 25 lines
drivers/firmware/efi/runtime-wrappers.c +10
-2+/* * As per commit ef68c8f87ed1 ("x86: Serialize EFI time accesses on rtc_lock"), * the EFI specification requires that callers of the time related runtime * functions serialize with other CMOS accesses in the kernel, as the EFI time @@ -30,10 +95,17 @@ static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc) {unsigned long flags;efi_status_t status; +bool __in_nmi =efi_in_nmi (); -spin_lock_irqsave (&rtc_lock, flags); +if (!__in_nmi) { +spin_lock_irqsave (&rtc_lock, flags); +spin_lock (&efi_runtime_lock); + } status =efi_call_virt (get_time, tm, tc); -spin_unlock_irqrestore (&rtc_lock, flags); +if (!__in_nmi) { +spin_unlock (&efi_runtime_lock); +spin_unlock_irqrestore (&rtc_lock, flags); + }return status; }
drivers/firmware/efi/runtime-wrappers.c static efi_status_t virt_efi_set_time(efi_time_t *tm) · line 117
Quoted 4 lines
drivers/firmware/efi/runtime-wrappers.c +1
-0@@ -42,8 +114,11 @@ static efi_status_t virt_efi_set_time(efi_time_t *tm)unsigned long flags;efi_status_t status; +BUG_ON (efi_in_nmi ());
I think we can safely drop these BUG_ON()s. I would expect things to explode pretty spectacularly anyway, even without them if we're in NMI context. BUG_ON()s are usually reserved for "this is a fatal condition and we cannot make any forward progress at all, so stop".
But also see my earlier point about how most of these functions aren't called from NMI context.
Quoted 5 lines
drivers/firmware/efi/runtime-wrappers.c +0
-1static efi_status_t virt_efi_get_next_variable (unsigned long *name_size,efi_char16_t *name,efi_guid_t *vendor) { -return efi_call_virt (get_next_variable, name_size, name, vendor);
drivers/firmware/efi/runtime-wrappers.c static efi_status_t virt_efi_get_variable(efi_char16_t *name, · line 188
Quoted 10 lines
drivers/firmware/efi/runtime-wrappers.c +10
-0+unsigned long flags; +efi_status_t status; +bool __in_nmi =efi_in_nmi (); + +if (!__in_nmi) +spin_lock_irqsave (&efi_runtime_lock, flags); + status =efi_call_virt (get_next_variable, name_size, name, vendor); +if (!__in_nmi) +spin_unlock_irqrestore (&efi_runtime_lock, flags); +return status;
We shouldn't ever be in NMI context when calling get_next_variable(), right?
drivers/firmware/efi/runtime-wrappers.c static void virt_efi_reset_system(int reset_type, · line 256
Quoted 13 lines
drivers/firmware/efi/runtime-wrappers.c +7
-0@@ -119,17 +245,33 @@ static void virt_efi_reset_system(int reset_type,unsigned long data_size, efi_char16_t *data) { + unsigned long flags; +bool __in_nmi =efi_in_nmi (); + +if (!__in_nmi) +spin_lock_irqsave (&efi_runtime_lock, flags);__efi_call_virt (reset_system, reset_type, status, data_size, data); +if (!__in_nmi) +spin_unlock_irqrestore (&efi_runtime_lock, flags); }
Is it even possible to perform a reset through the usual machinery in NMI context? I don't think this is possible for x86. What about for arm64?
Quoted 9 lines
drivers/firmware/efi/runtime-wrappers.c +4
-0static efi_status_t virt_efi_update_capsule (efi_capsule_header_t **capsules,unsigned long count,unsigned long sg_list) { +unsigned long flags; +efi_status_t status; +bool __in_nmi =efi_in_nmi (); +if (efi.runtime_version <EFI_2_00_SYSTEM_TABLE_REVISION )
drivers/firmware/efi/runtime-wrappers.c static void virt_efi_reset_system(int reset_type, · line 275
Quoted 10 lines
drivers/firmware/efi/runtime-wrappers.c +6
-1return EFI_UNSUPPORTED ; -return efi_call_virt (update_capsule, capsules, count, sg_list); +if (!__in_nmi) +spin_lock_irqsave (&efi_runtime_lock, flags); + status =efi_call_virt (update_capsule, capsules, count, sg_list); +if (!__in_nmi) +spin_unlock_irqrestore (&efi_runtime_lock, flags); +return status; }
I don't think we need to check for being in NMI context here.
Quoted 12 lines
drivers/firmware/efi/runtime-wrappers.c +4
-0static efi_status_t virt_efi_query_capsule_caps(efi_capsule_header_t **capsules,@@ -137,11 +279,20 @@ static efi_status_t virt_efi_query_capsule_caps(efi_capsule_header_t **capsules, u64 *max_size, int *reset_type) { +unsigned long flags; +efi_status_t status; +bool __in_nmi =efi_in_nmi (); +if (efi.runtime_version <EFI_2_00_SYSTEM_TABLE_REVISION )return EFI_UNSUPPORTED ;
drivers/firmware/efi/runtime-wrappers.c static efi_status_t virt_efi_query_capsule_caps(efi_capsule_header_t **capsules, · line 296
Quoted 10 lines
drivers/firmware/efi/runtime-wrappers.c +7
-2-return efi_call_virt (query_capsule_caps, capsules, count, max_size, - reset_type); +if (!__in_nmi) +spin_lock_irqsave (&efi_runtime_lock, flags); + status =efi_call_virt (query_capsule_caps, capsules, count, max_size, + reset_type); +if (!__in_nmi) +spin_unlock_irqrestore (&efi_runtime_lock, flags); +return status; }
Definitely should not be perfoming QueryCapsuleCapabilities() in NMI context.
Signature · 1 line
Matt Fleming, Intel Open Source Technology Center
PATCH v3 1/1 efi: implement mandatory locking for UEFI Runtime Services
Quoted 10 lines · Matt Fleming
Quoted 4 lines · Ard Biesheuvel
According to section 7.1 of the UEFI spec, Runtime Services are not fully reentrant, and there are particular combinations of calls that need to be serialized. Use a spinlock to serialize all Runtime Services with respect to all others, even if this is more than strictly needed.
It'd be good to include a point about why we're only using a spinlock, namely that anything else introduces complication to code that is unlikely to be performance critical.
OK
Quoted 13 lines
[...]
drivers/firmware/efi/runtime-wrappers.c line 84
Quoted 7 lines
+ *
+ * In order to prevent deadlocks under NMI, the wrappers for these functions
+ * only grab theefi_runtime_lockorrtc_lockspinlocks if !efi_in_nmi().
+ */drivers/firmware/efi/runtime-wrappers.c +3
-0+#ifndef efi_in_nmi +#define efi_in_nmi () (0) +#endif It shouldn't be necessary to do the NMI checking for *all* runtime services, unless you use, for instance, the timer functions on ARM64.
No, I only added the checks to functions that are listed in the UEFI spec as requiring the special treatment.
Table 32 is copied right from the spec. (And if that is not obvious, I should definitely add a mention there)
Quoted 35 lines
Quoted 25 lines
drivers/firmware/efi/runtime-wrappers.c +10
-2+/* * As per commit ef68c8f87ed1 ("x86: Serialize EFI time accesses on rtc_lock"), * the EFI specification requires that callers of the time related runtime * functions serialize with other CMOS accesses in the kernel, as the EFI time @@ -30,10 +95,17 @@ static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc) {unsigned long flags;efi_status_t status; +bool __in_nmi =efi_in_nmi (); -spin_lock_irqsave (&rtc_lock, flags); +if (!__in_nmi) { +spin_lock_irqsave (&rtc_lock, flags); +spin_lock (&efi_runtime_lock); + } status =efi_call_virt (get_time, tm, tc); -spin_unlock_irqrestore (&rtc_lock, flags); +if (!__in_nmi) { +spin_unlock (&efi_runtime_lock); +spin_unlock_irqrestore (&rtc_lock, flags); + }return status; }drivers/firmware/efi/runtime-wrappers.c static efi_status_t virt_efi_set_time(efi_time_t *tm) · line 117
Quoted 4 lines
drivers/firmware/efi/runtime-wrappers.c +1
-0@@ -42,8 +114,11 @@ static efi_status_t virt_efi_set_time(efi_time_t *tm)unsigned long flags;efi_status_t status; +BUG_ON (efi_in_nmi ());I think we can safely drop these BUG_ON()s. I would expect things to explode pretty spectacularly anyway, even without them if we're in NMI context. BUG_ON()s are usually reserved for "this is a fatal condition and we cannot make any forward progress at all, so stop".
Quoted 3 lines
But also see my earlier point about how most of these functions aren't called from NMI context.
I added the BUG_ON() to functions not listed in the table, and added the treatment to functions that are listed in the table. Happy to drop the BUG_ON()'s, though.
Quoted 16 lines
Quoted 5 lines
drivers/firmware/efi/runtime-wrappers.c +0
-1static efi_status_t virt_efi_get_next_variable (unsigned long *name_size,efi_char16_t *name,efi_guid_t *vendor) { -return efi_call_virt (get_next_variable, name_size, name, vendor);drivers/firmware/efi/runtime-wrappers.c static efi_status_t virt_efi_get_variable(efi_char16_t *name, · line 188
Quoted 10 lines
drivers/firmware/efi/runtime-wrappers.c +10
-0+unsigned long flags; +efi_status_t status; +bool __in_nmi =efi_in_nmi (); + +if (!__in_nmi) +spin_lock_irqsave (&efi_runtime_lock, flags); + status =efi_call_virt (get_next_variable, name_size, name, vendor); +if (!__in_nmi) +spin_unlock_irqrestore (&efi_runtime_lock, flags); +return status;
Quoted 3 lines
We shouldn't ever be in NMI context when calling
get_next_variable(), right?
Spec allows it ...
Quoted 9 lines
Quoted 9 lines
drivers/firmware/efi/runtime-wrappers.c +5
-0@@ -119,17 +245,33 @@ static void virt_efi_reset_system(int reset_type,unsigned long data_size, efi_char16_t *data) { + unsigned long flags; +bool __in_nmi =efi_in_nmi (); + +if (!__in_nmi) +spin_lock_irqsave (&efi_runtime_lock, flags);
Quoted 9 lines
drivers/firmware/efi/runtime-wrappers.c static void virt_efi_reset_system(int reset_type, · line 256
Quoted 4 lines
drivers/firmware/efi/runtime-wrappers.c +2
-0__efi_call_virt (reset_system, reset_type, status, data_size, data); +if (!__in_nmi) +spin_unlock_irqrestore (&efi_runtime_lock, flags); }Is it even possible to perform a reset through the usual machinery in NMI context? I don't think this is possible for x86. What about for arm64?
We don't have NMI so all the in_nmi() macros evaluate to false anyway.
Quoted 20 lines
Quoted 9 lines
drivers/firmware/efi/runtime-wrappers.c +4
-0static efi_status_t virt_efi_update_capsule (efi_capsule_header_t **capsules,unsigned long count,unsigned long sg_list) { +unsigned long flags; +efi_status_t status; +bool __in_nmi =efi_in_nmi (); +if (efi.runtime_version <EFI_2_00_SYSTEM_TABLE_REVISION )drivers/firmware/efi/runtime-wrappers.c static void virt_efi_reset_system(int reset_type, · line 275
Quoted 10 lines
drivers/firmware/efi/runtime-wrappers.c +6
-1return EFI_UNSUPPORTED ; -return efi_call_virt (update_capsule, capsules, count, sg_list); +if (!__in_nmi) +spin_lock_irqsave (&efi_runtime_lock, flags); + status =efi_call_virt (update_capsule, capsules, count, sg_list); +if (!__in_nmi) +spin_unlock_irqrestore (&efi_runtime_lock, flags); +return status; }
Quoted 2 lines
I don't think we need to check for being in NMI context here.
Likewise, the spec says different ...
Quoted 12 lines
Quoted 12 lines
drivers/firmware/efi/runtime-wrappers.c +4
-0static efi_status_t virt_efi_query_capsule_caps(efi_capsule_header_t **capsules,@@ -137,11 +279,20 @@ static efi_status_t virt_efi_query_capsule_caps(efi_capsule_header_t **capsules, u64 *max_size, int *reset_type) { +unsigned long flags; +efi_status_t status; +bool __in_nmi =efi_in_nmi (); +if (efi.runtime_version <EFI_2_00_SYSTEM_TABLE_REVISION )return EFI_UNSUPPORTED ;
Quoted 14 lines
drivers/firmware/efi/runtime-wrappers.c static efi_status_t virt_efi_query_capsule_caps(efi_capsule_header_t **capsules, · line 296
Quoted 10 lines
drivers/firmware/efi/runtime-wrappers.c +7
-2-return efi_call_virt (query_capsule_caps, capsules, count, max_size, - reset_type); +if (!__in_nmi) +spin_lock_irqsave (&efi_runtime_lock, flags); + status =efi_call_virt (query_capsule_caps, capsules, count, max_size, + reset_type); +if (!__in_nmi) +spin_unlock_irqrestore (&efi_runtime_lock, flags); +return status; }Definitely should not be perfoming
QueryCapsuleCapabilities()in NMI context.
Well, again, the spec allows it. But I am happy to remove it as it does not affect ARM anyway
Regards,
Ard.
PATCH v3 1/1 efi: implement mandatory locking for UEFI Runtime Services
Quoted 3 lines · Ard Biesheuvel
Well, again, the spec allows it. But I am happy to remove it as it does not affect ARM anyway
Right, I understand why you added these now.
My personal opinion is that we shouldn't do the NMI dancing unless absolutely necessary, e.g. because of corresponding kernel code paths. The fact that the spec allows it doesn't necessarily mean we should support it.
But I do like the idea of documenting that the spec allows for things that we don't support, because that at least informs developers, when they come snooping around this file, that they've got some additional work to do if they want to call these functions from NMI context.
So the table you included is cool, and I think some additional sentences along the lines of "... but we don't support calling all these functions from NMI context" would be a good addition.
What do you think?
Signature · 1 line
Matt Fleming, Intel Open Source Technology Center
PATCH v3 1/1 efi: implement mandatory locking for UEFI Runtime Services
Quoted 5 lines · Matt Fleming
Quoted 3 lines · Ard Biesheuvel
Well, again, the spec allows it. But I am happy to remove it as it does not affect ARM anyway
Quoted 7 lines
Right, I understand why you added these now.
My personal opinion is that we shouldn't do the NMI dancing unless absolutely necessary, e.g. because of corresponding kernel code paths. The fact that the spec allows it doesn't necessarily mean we should support it.
I agree. But for me, it is not obvious which functions can or cannot be called from NMI context on x86, so I played it safe by just covering everything that the spec allows, the idea being that if other uses exists, they violate the spec anyway and handling NMI in those cases may well break other stuff.
Quoted 11 lines
But I do like the idea of documenting that the spec allows for things that we don't support, because that at least informs developers, when they come snooping around this file, that they've got some additional work to do if they want to call these functions from NMI context.
So the table you included is cool, and I think some additional sentences along the lines of "... but we don't support calling all these functions from NMI context" would be a good addition.
What do you think?
I think that makes sense. As I said, I don't have a strong preference either way regarding the NMI handling, as it does not affect the systems I am primarily concerned with (and it sounds like a big hack anyway). What I /am/ concerned with is not getting code into the kernel that turns out to be non-compliant a couple of months down the road and having to fix it urgently then.
So other than GetVariable and SetVariable, or there any other services that need the NMI treatment?
Signature · 1 line
Ard.
PATCH v3 1/1 efi: implement mandatory locking for UEFI Runtime Services
Quoted 7 lines · Ard Biesheuvel
I think that makes sense. As I said, I don't have a strong preference either way regarding the NMI handling, as it does not affect the systems I am primarily concerned with (and it sounds like a big hack anyway). What I /am/ concerned with is not getting code into the kernel that turns out to be non-compliant a couple of months down the road and having to fix it urgently then.
Right, that's a valid concern.
Quoted 2 lines
So other than GetVariable and SetVariable, or there any other services that need the NMI treatment?
The one and only (potential) NMI-context caller of EFI runtime services is efi_pstore_write(), which calls (as part of efivar_entry_set_safe()) QueryVariableInfo() and SetVariable().
Signature · 1 line
Matt Fleming, Intel Open Source Technology Center