On Mon, 8 Jan 2024 at 16:32, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
>
> 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.kette...@xs4all.nl>
> >>> wrote:
> >>>>
> >>>>> Date: Thu, 14 Dec 2023 15:53:46 +0000
> >>>>> From: Abdellatif El Khlifi <abdellatif.elkhl...@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.
On top of that, we are already calling
efi_variables_boot_exit_notify() based on those events. We could reuse
that
Regards
/Ilias
>
> 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
>
