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 >