Adding EFI runtime support to the Arm's FF-A bus

[Heinrich Schuchardt]

On 08.01.24 15:12, Abdellatif El Khlifi wrote:
> Happy new year Ilias,
>
> On Mon, Dec 18, 2023 at 04:59:09PM +0000, Abdellatif El Khlifi wrote:
>> Hi Ilias
>>
>> On Thu, Dec 14, 2023 at 09:47:13PM +0200, Ilias Apalodimas wrote:
>>> Hi Mark, Abdellatif
>>>
>>> On Thu, 14 Dec 2023 at 18:47, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>>>>
>>>>> Date: Thu, 14 Dec 2023 15:53:46 +0000
>>>>> From: Abdellatif El Khlifi <abdellatif.elkhlifi at arm.com>
>>>>
>>>> Hi Abdellatif,
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I'd like to ask for advice regarding adding EFI RT support to the Arm's FF-A bus
>>>>> in U-Boot.
>>>>>
>>>>> The objective is to enable the FF-A messaging APIs in EFI RT to be
>>>>> used for comms with the secure world. This will help getting/setting
>>>>> EFI variables through FF-A.
>>>>>
>>>>> The existing FF-A APIs in U-Boot call the DM APIs (which are not available at RT).
>>>>>
>>>>> Two possible solutions:
>>>>>
>>>>> 1/ having the entire U-Boot in RT space (as Simon stated in this discussion[1])
>>>>
>>>> I don't think this is a terribly good idea.  With this approach orders
>>>> of magnitude more code will be present in kernel address space one the
>>>> OS kernel is running and calling into the EFI runtime.  Including code
>>>> that may access hardware devices that are now under OS control.  It
>>>> will be nigh impossible to audit all that code and make sure that only
>>>> a safe subset of it gets called.  So...
>>>
>>> +100
>>> I think we should draw a line here. I mentioned it on another thread,
>>> but I did a shot BoF in Plumbers discussing issues like this,
>>> problems, and potential solutions [0] [1]. Since that talk patches for
>>> the kernel that 'solve' the problem for RPMBs got pulled into
>>> linux-next [2].
>>
>> I watched your talk. Great work, thanks :)
>>
>>> The TL;DR of that talk is that if the kernel ends up being in control
>>> of the hardware that stores the EFI variables, we need to find elegant
>>> ways to teach the kernel how to store those directly. The EFI
>>> requirement of an isolated flash is something that mostly came from
>>> the x86 world and is not a reality on the majority of embedded boards.
>>> I also think we should give up on Authenticated EFI variables in that
>>> case. We get zero guarantees unless the medium has similar properties
>>> to an RPMB.
>>> If a vendor cares about proper UEFI secure boot he can implement
>>> proper hardware.
>>>
>>>>
>>>>>
>>>>> 2/ Create an RT variant for the FF-A APIs needed.
>>>>>        These RT variant don't call the DM APIs
>>>>>        (e.g: ffa_mm_communicate_runtime, ffa_sync_send_receive_runtime, ...)
>>>>>
>>>>> What do you recommend please ?
>>>>
>>>> ...this is what I would recommend.  Preferably in a way that refactors
>>>> the code such that the low-level functionality is shared between the
>>>> DM and non-DM APIs.
>>>
>>> Yes. The only thing you need to keep alive is the machinery to talk to
>>> the secure world. The bus, flash driver etc should all be running
>>> isolated in there. In that case you can implement SetVariableRT as
>>> described the the EFI spec.
>>
>> Cool, thanks. That's my preferred solution too.
>>
>> mm_communicate() should be able to detect runtime mode so it calls ffa_mm_communicate_runtime().
>>
>> Is there a way to check whether we are in EFI runtime or not ?

Relevant UEFI event groups for the transition to the OS are:

EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES
EFI_EVENT_GROUP_EXIT_BOOT_SERVICES
EFI_EVENT_GROUP_VIRTUAL_ADDRESS_CHANGE

Once EFI_EVENT_GROUP_EXIT_BOOT_SERVICES is signaled you are at runtime.

Use CreateEventEx() to create an event for the group.

Best regards

Heinrich

>>
>> Suggested changes (pseudo-code):
>>
>> __efi_runtime mm_communicate () {
>> #if CONFIG_IS_ENABLED(ARM_FFA_TRANSPORT)
>> if (RT) { /* NEW */
>>          ret = ffa_mm_communicate_runtime(comm_buf, dsize); /* NEW */
>> } else {
>>      mm_comms = get_mm_comms();
>>      if (mm_comms == MM_COMMS_FFA)
>>          ret = ffa_mm_communicate(comm_buf, dsize);
>>      else
>>          ret = optee_mm_communicate(comm_buf, dsize);
>> }
>> #else
>> ...
>> #endif
>>
>> Existing code:  https://github.com/u-boot/u-boot/blob/master/lib/efi_loader/efi_variable_tee.c#L417
>
> A gentle reminder about the question above please (Is there a way to check whether we are in EFI runtime or not).
>
> Cheers,
> Abdellatif