Hi, On Thu, 14 Dec 2023 at 12:47, Ilias Apalodimas <ilias.apalodi...@linaro.org> 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]. > 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.
Just to copy in my thoughts as they are lost at this point: > We would need to publish a runtime interface with access to the driver > API. I did ask for this when the EFI runtime support was added, but it > wasn't done. > It would be possible to create a new 'runtime' phase of U-Boot (RPL?), > separate from the others. That will be much easier once we get the XPL > stuff sorted out., since adding new [hase would be fairly trivial CPL > died as another contributor had a series which went in first...then I > never got back to it. > So for now having the entire U-Boot in runtime space seems reasonable to me. > I'll also mention that it would be nice to have s new-style API > (replacing the old API U-Boot currently has) which uses more of a > module approach. E.g. we could declare that uclass_first_device() is > exported and can be called from outside U-Boot. > > > > > > > > > 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. The current approach is pretty brittle, since it relies on putting some of the U-Boot code into a separate area. There is no good way to know which U-Boot code should be in that area, since we don't create a separate build. If a function calls one that has not been specially marked, or accesses data that is not in the area, then it will crash or hang. So, as I said, I think we need a new build, if we want to avoid all of U-Boot in there. Anything else is hard to maintain. > > [...] > > [0] https://www.youtube.com/watch?v=UdQk0SCUAlA > [1] > https://lpc.events/event/17/contributions/1653/attachments/1338/2682/Plumbers%20-%20EFI%20setvariable%20problems%20and%20solutions.pdf > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c44b6be62e8dd4ee0a308c36a70620613e6fc55f > Regards, Simon
