Hi Heinrich, On Mon, 18 Dec 2023 at 13:59, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > > > Am 18. Dezember 2023 16:01:44 MEZ schrieb Simon Glass <s...@chromium.org>: > >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. > > The EFI runtime is the most security exposed part of U-Boot. We should strive > to keep the attack surface small. No matter how we define the runtime (by > section assignment as today or by a dedicated build) I would not want to have > the driver model in the runtime. > > The only drivers that are required by the EBBR are for resetting the system. > ARM has PSCI as reset handler, RISC-V has SBI. These are invoked by simple > ecalls.
So why not have Linux do it? Why do we need the runtime at all? But from the other POV, what if this expands? We are creating a little runtime stub without driver model? I suppose it will work until it doesn't. > > Any runtime device drivers for variable storage should not be in the U-Boot > runtime but live in the secure world (e.g. OP-TEE). FF-A is the new ARM > protocol for talking to the secure world and hence fits into the picture. OK. This is all very complicated, of course. But OK. > > @Abdellatif > > Does an OP-TEE module for managing EFI variables via FF-A already exist? For > QEMU? > > Best regards > > Heinrich > > > > >> > >> [...] > >> > >> [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
