On Tue, 24 Nov 2020 at 14:05, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: > > On 10/20/20 9:22 AM, ivanhu wrote: > > > > On 10/20/20 2:46 PM, Ard Biesheuvel wrote: > >> On Tue, 20 Oct 2020 at 08:20, ivanhu <ivan.hu@xxxxxxxxxxxxx> 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@xxxxxx> wrote: > >>>>>> On 19.10.20 12:03, Ard Biesheuvel wrote: > >>>>>>> On Mon, 19 Oct 2020 at 12:00, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: > >>>>>>>> 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? > >>>>>>>> > >>>>>>> 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? > >> > > Right, FWTS need to be able to get the RuntimeServicesSupported value. > > > > I'm not sure if kernel will implement it or not, if not, maybe efi_test > > can help to get and export the RuntimeServicesSupported from configure > > table to FWTS. > > Hello Ard, > > what are you plans to get the issue solved? > No plans. Patches welcome.
