Re: fwts: RuntimeServicesSupported variable

[Ard Biesheuvel <ardb@kernel.org>]

On Tue, 20 Oct 2020 at 08:20, ivanhu <ivan.hu@canonical.com> wrote:
>
>
> On 10/19/20 7:25 PM, Heinrich Schuchardt wrote:
> > On 19.10.20 13:01, Ard Biesheuvel wrote:
> >> On Mon, 19 Oct 2020 at 13:00, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>> On 19.10.20 12:03, Ard Biesheuvel wrote:
> >>>> On Mon, 19 Oct 2020 at 12:00, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>>>> 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?
> >>>>>
> >>>> As I attempted to explain, I think EFI_UNSUPPORTED should not be
> >>>> reported as an error if RT_PROP_TABLE permits it. The caller has
> >>>> access to the raw efi_status_t that was returned, so it can
> >>>> distinguish between the two cases.
> >>>>
> >>> The fwts tires to figure out if a firmware implementation is compliant.
> >>>
> >>> The return value according to you suggestion would be as follows
> >>> depending on the UEFI status and the entry in EFI_RT_PROPERTIES_TABLE.
> >>>
> >>>           | EFI_SUCCESS  | EFI_UNSUPPORTED | EFI_INVALID_PARAMETER
> >>> ----------|--------------|-----------------|----------------------
> >>> Available |              |                 |
> >>> according |     0        |   -EINVAL       |       -EINVAL
> >>> EFT_RT_PRO|              |                 |
> >>> -------------------------------------------------------------------
> >>> Not       |              |                 |
> >>> available |              |                 |
> >>> according |     0        |       0         |       -EINVAL
> >>> EFT_RT_PRO|              |                 |
> >>> -------------------------------------------------------------------
> >>>
> >>> fwts would not be able to detect that according to the
> >>> EFI_RT_PROPERTIES_TABLE the service is marked as not available
> >>> but returns a value other than EFI_UNSUPPORTED.
> >>>
> >> But that would be permitted by the spec anyway. A runtime service is
> >> not required to always return EFI_UNSUPPORTED if it is marked as
> >> unavaialble in EFI_RT_PROP.
> >>
> > In the chapter "EFI_RT _PROPERTIES_TABLE" you can find this description:
> >
> > "*RuntimeServicesSupported* mask of which calls are or are not
> > supported, where a bit set to 1 indicates that the call is supported,
> > and 0 indicates that it is not."
> >
> > This leaves no room for implementing a service that is marked as not
> > supported.
> >
> > In the descriptions of the return codes of the individual runtime services:
> >
> > "*EFI_UNSUPPORTED* This call is not supported by this platform at the
> > time the call is made. The platform should describe this runtime service
> > as unsupported at runtime via an EFI_RT_PROPERTIES_TABLE configuration
> > table."
>
> From the spec, it clearly describes
>
> If a platform cannot support calls defined in EFI_RUNTIME_SERVICES after
> ExitBootServices() is called, that platform is permitted to provide
> implementations of those runtime services that return EFI_UNSUPPORTED
> when invoked at runtime. On such systems, an EFI_RT_PROPERTIES_TABLE
> configuration table should be published describing which runtime
> services are supported at runtime.
>
> I think it's better not to modify efi_test base on the
> EFI_RT_PROPERTIES_TABLE or RuntimeServicesSupported, let efi_test be
> simply ioctl and FWTS tests can do the modifications.
>

Doesn't that mean FTWS would need to be able to access the
EFI_RT_PROPERTIES_TABLE?