On 19.10.20 11:31, Ard Biesheuvel wrote: > On Wed, 14 Oct 2020 at 20:41, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: >> >> On 14.10.20 19:58, Ard Biesheuvel wrote: >>> On Wed, 14 Oct 2020 at 19:45, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: >>>> >>>> On 14.10.20 19:31, Heinrich Schuchardt wrote: >>>>> Dear all, >>>>> >>>>> the fwts fails on U-Boot due to testing for a non-existent >>>>> RuntimeServicesSupported variable. >>>>> >>>>> If you look at the UEFI specification 2.8 (Errata B) [1] you will >>>>> discover in the change log: >>>>> >>>>> 2.8 A2049 >>>>> RuntimeServicesSupported EFI variable should be a config table >>>>> February 2020 >>>>> >>>>> Please, read the configuration table to determine if a runtime service >>>>> is available on UEFI 2.8 systems. >>>>> >>>>> On lower UEFI firmware version neither the variable nor the table exists. >>>>> >>>>> Best regards >>>>> >>>>> Heinrich >>>>> >>>>> [1] UEFI Specification Version 2.8 (Errata B) (released June 2020), >>>>> https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf >>>>> >>>> >>>> Hello Ard, >>>> >>>> what is your idea how the EFI_RT_PROPERTIES_TABLE shall be exposed to >>>> the efi_test driver? >>>> >>>> Will the EFI runtime wrapper simply return EFI_UNSUPPORTED if the >>>> function is not marked as supported in the table? Or will the >>>> configuration table itself be make available? >>>> >>> >>> The UEFI spec permits that runtime services return EFI_UNSUPPORTED at >>> runtime, but requires that they are marked as such in the >>> EFI_RT_PROPERTIES_TABLE. >>> >>> So assuming that the purpose of efi_test is compliance with the spec, >>> it should only allow EFI_UNSUPPORTED as a return value for each of the >>> tested runtime services if it is omitted from >>> efi.runtime_supported_mask. >>> >>> Since the efi_test ioctl returns both an error code and the actual EFI >>> status code, we should only fail the call on a EFI_UNSUPPORTED status >>> code if the RTPROP mask does not allow that. >>> >>> E.g., >>> >>> --- a/drivers/firmware/efi/test/efi_test.c >>> +++ b/drivers/firmware/efi/test/efi_test.c >>> @@ -265,7 +265,12 @@ static long efi_runtime_set_variable(unsigned long arg) >>> goto out; >>> } >>> >>> - rv = status == EFI_SUCCESS ? 0 : -EINVAL; >>> + if (status == EFI_SUCCESS || >>> + (status == EFI_UNSUPPORTED && >>> + !efi_rt_services_supported(EFI_RT_SUPPORTED_SET_VARIABLE))) >>> + rv = 0; >>> + else >>> + rv = -EINVAL; >>> >>> out: >>> kfree(data); >>> >>> >>> Do you think that could work? >>> >> >> The current fwts implementation assumes that EFI_UNSUPPORTED leads to >> ioctl() returning -1. This value should not be changed. It would be >> preferable to use another error code than -EINVAL, e.g. -EDOM if there >> is a mismatch with the EFI_RT_PROPERTIES_TABLE configuration table. Then >> a future verision of fwts can evaluate errno to discover the problem. >> >> Do I read you correctly: the EFI runtime wrapper does not fend of calls >> to runtime services marked as disallowed in EFI_RT_PROPERTIES_TABLE? >> Directly returning an error code might help to avoid crashes on >> non-compliant firmware. >> > > It is not the kernel's job to work around non-compliant firmware. The > EFI spec is crystal clear that every runtime service needs to be > implemented, but is permitted to return EFI_UNSUPPORTED after > ExitBootServices(). This means EFI_RT_PROPERTIES_TABLE does not tell > you calling certain runtime services is disallowed, it tells you that > there is no point in even trying. That is why users such as efi-pstore > now take this information into account in their probe path (and > efivarfs will only mount read/write if SetVariable() is not marked as > unsupported). > How about the return code? Best regards Heinrich
