search

ARM-software / ebbr

Embedded Base Boot Requirements Specification
Creative Commons Attribution Share Alike 4.0 International
113 stars 37 forks source link

Thread safety of runtime services #66

Closed xypron closed 3 years ago

xypron commented 3 years ago

Linux seems to expect that variable services are thread-safe I do not see any lock in functions like __efivar_entry_get().

U-Boot currently uses a static variable efi_current_var in lib/efi_loader/efi_var_mem.c to speed up lookup. So the runtime services are not thread-safe.

For EDK II I do not know if their implementations are thread-safe.

In the EBBR we should clearly express which guarantees the runtime service should provide.

daniel-thompson commented 3 years ago

Linux seems to expect that variable services are thread-safe I do not see any lock in functions like __efivar_entry_get().

You sure? I recall the EFI interfaces as being somewhat infamous as one of the last places in the kernel that still uses "real" semaphores for the locking instead of mutexes (meaning EFI interacts suboptimally with PREEMPT_RT).

In this specific case __efivar_entry_get() is protected by the efivars_lock just as efivar_entry_get() is but the lock is taken higher up the callstack via a call to efivar_entry_iter_begin().

leiflindholm commented 3 years ago

On Mon, Dec 07, 2020 at 03:01:43 -0800, Daniel Thompson wrote:

Linux seems to expect that variable services are thread-safe I do not see any lock in functions like __efivar_entry_get().

You sure? I recall the EFI interfaces as being somewhat infamous as one of the last places in the kernel that still uses "real" semaphores for the locking instead of mutexes (meaning EFI interacts suboptimally with PREEMPT_RT).

In this specific case __efivar_entry_get() is protected by the efivars_lock just as efivar_entry_get() is but the lock is taken higher up the callstack via a call to efivar_entry_iter_begin().

Moreover, table 35 "Rules for Reentry Into Runtime Services" in UEFI 2.8 explicitly lists the restrictions of which functions may (not) be called concurrently.

I don't think the EBBR should duplicate this information.

/ Leif

xypron commented 3 years ago

On 07.12.20 12:10, Leif Lindholm wrote:

On Mon, Dec 07, 2020 at 03:01:43 -0800, Daniel Thompson wrote:

Linux seems to expect that variable services are thread-safe I do not see any lock in functions like __efivar_entry_get().

You sure? I recall the EFI interfaces as being somewhat infamous as one of the last places in the kernel that still uses "real" semaphores for the locking instead of mutexes (meaning EFI interacts suboptimally with PREEMPT_RT).

In this specific case __efivar_entry_get() is protected by the efivars_lock just as efivar_entry_get() is but the lock is taken higher up the callstack via a call to efivar_entry_iter_begin().

Moreover, table 35 "Rules for Reentry Into Runtime Services" in UEFI 2.8 explicitly lists the restrictions of which functions may (not) be called concurrently.

I don't think the EBBR should duplicate this information.

Thanks a lot for pointing at chapter 8.1 Runtime Services Rules and Restrictions. Which clarifies my open questions.

Best regards

Heinrich