Re: fwts: RuntimeServicesSupported variable

[Heinrich Schuchardt <xypron.glpk@gmx.de>]

On 19.10.20 11:31, Ard Biesheuvel wrote:
> On Wed, 14 Oct 2020 at 20:41, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 14.10.20 19:58, Ard Biesheuvel wrote:
>>> On Wed, 14 Oct 2020 at 19:45, Heinrich Schuchardt <xypron.glpk@gmx.de> 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