On Fri, Sep 19, 2025 at 05:50:21PM +0200, Quentin Schulz wrote: > From: Quentin Schulz <quentin.sch...@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.sch...@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
signature.asc
Description: PGP signature
