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@xs4all.nl wrote:
Date: Thu, 14 Dec 2023 15:53:46 +0000 From: Abdellatif El Khlifi abdellatif.elkhlifi@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...
A gentle reminder about the question above please (Is there a way to check whether we are in EFI runtime or not).
Cheers, Abdellatif