[PATCH RFC] lib: optee: forbid OP-TEE OS loading without adding OP-TEE OS reserved-memory nodes

[Tom Rini]

On Fri, Sep 19, 2025 at 05:50:21PM +0200, Quentin Schulz wrote:

> From: Quentin Schulz <quentin.schulz at cherry.de>
> 
> It is currently possible to build an image with an OP-TEE OS (via the
> TEE environment variable) without OPTEE_LIB. U-Boot will happily load
> the TEE OS and the next OS (e.g. the Linux kernel).
> 
> This is an issue because on FDT-enabled devices, OP-TEE OS adds nodes to
> the reserved-memory FDT node for the memory regions it just reserved for
> itself. This updated is then passed to U-Boot proper which should know
> better not to use memory from there. The actual issue is that without
> OPTEE_LIB and OF_LIBFDT enabled, U-Boot proper will not copy those nodes
> over to the next OS's FDT before starting it. This results in the next
> OS's (e.g. Linux kernel) to not be aware of reserved memory, incurring
> random crashes or device reboots when it tries to access secure reserved
> memory area.
> 
> Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>
> ---
> I've just lost a day trying to figure out why my board suddenly boot
> loops when running a specific program in Linux userspace after updating
> U-Boot. I actually inadvertently had the TEE environment variable set
> for a device which doesn't actually need to run any TEE OS (so had
> OPTEE_LIB disabled).
> 
> This device is Rockchip PX30-based and the image is built with binman
> like all Rockchip-based devices.
> 
> The issue is that I built a U-Boot FIT with an OP-TEE OS that reserves
> some memory regions for itself (via the TEE environment variable) but
> U-Boot proper "forgot" to propagate those to the Linux kernel's FDT
> (because of the missing OPTEE_LIB).
> 
> Unfortunately, binman doesn't seem to have access to Kconfig symbols
> (grep CONFIG_ doesn't return anything meaningful and binman is either
>  configured through FDT nodes or via CLI arguments, c.f. cmd_binman in
>  the root Makefile) so I cannot try to be smart and guide the user to
> the correct Kconfig option to select if TEE is set. I could add a
> property based on the presence of OPTEE_LIB in rockchip-u-boot.dtsi for
> example and have a custom message based on that, the issue is that I
> assume all FDT-based platforms do actually need to do this dance, and
> not only Rockchip.
> Another option could be to add a CLI argument to binman through which
> we would pass the state of OPTEE_LIB and error out the build in that
> case, but that feels like opening the door to dirty hacks (though this
> patch is admittedly another dirty hack :) ).
> 
> Another option is to propagate the TEE environment variable to the
> preprocessor of the FDT (via dtc_cpp_flags) and then I can do
> 
>  #if defined(TEE) && !IS_ENABLED(CONFIG_OPTEE_LIB)
>  #error "CONFIG_OPTEE_LIB must be enabled!"
>  #endif
> 
> but we have the same issue as above, it is then Rockchip specific and
> also feels bad.
> 
> Another option is to remove the @tee-SEQ node from the binman FIT
> description when OPTEE_LIB isn't set but then I would lose the nice
> message when no TEE is provided:
> 
> Image 'simple-bin' is missing optional external blobs but is still functional: tee-os
> 
> and even worse, build without any TEE OS even though I could provide one
> with the TEE environment variable.
> 
> Finally, another option could be to move this hack under
> arch/arm/mach-rockchip/Kconfig to make it Rockchip specific or add a
> depends on ARCH_ROCKCHIP
> 
> OP-TEE OS on Aarch32 Rockchip boards doesn't actually need any of that
> if SPL_OPTEE_IMAGE is set because arch/arm/mach-rockchip/sdram.c then
> marks some hardcoded memory regions in RAM as holes in DRAM, which has
> the same effect as reserved memory regions I guess. I assume other
> platforms may use something different, so it may be casting too wide of
> a net.
> 
> Does anyone have something more delicate than this sledgehammer of a
> solution?

It looks like on other SoCs there's an ARCH_x wide imply/select OPTEE
(which in turn gets OPTEE_LIB), so is there a case for ARCH_ROCKCHIP &&
!ARM64 && !OPTEE ? I see you explained that 32bit has a workaround for
this already.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250919/a9164cbd/attachment.sig>