[RFC PATCH v1 2/4] spl: Kconfig: allow disabling fallback during os boot

[Tom Rini]

On Fri, Jun 27, 2025 at 05:31:03AM +0530, Anshul Dalal wrote:
> On Fri Jun 27, 2025 at 5:17 AM IST, Tom Rini wrote:
> > On Thu, Jun 26, 2025 at 05:34:40PM +0530, Anshul Dalal wrote:
> >
> >> During falcon boot in FS mode, if the SPL fails to load the payload
> >> (kernel image and args), the execution fallbacks to standard u-boot boot
> >> mode.
> >> 
> >> This might not be desired in cases when u-boot payload (tifalcon.bin in
> >> our case) is dysfuncitonal by itself or user's access to standard u-boot
> >> should be restricted (for security reasons for example).
> >> 
> >> In our falcon use case, this fallback allows the user to bypass
> >> authenticated boot by just deleting the fitImage which causes SPL to
> >> reload tifalcon.bin. The boot proceeds as usual until ATF jumps to
> >> PRELOADED_BL33_BASE where the kernel has not been loaded causing the
> >> core to execute whatever else was written at that address.
> >> 
> >> Therefore this patch adds a new config symbol SPL_FALCON_ALLOW_FALLBACK
> >> that explicitly toggles the fallback for MMC FS boot. It is set to 'y'
> >> by default so as to not break any existing falcon mode systems.
> >> 
> >> Signed-off-by: Anshul Dalal <anshuld at ti.com>
> >> ---
> >>  common/spl/Kconfig   | 10 +++++
> >>  common/spl/spl_mmc.c | 87 ++++++++++++++++++++++++++++----------------
> >>  2 files changed, 65 insertions(+), 32 deletions(-)
> >> 
> >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> >> index 8d153c2e9c9..d5d3a41ce61 100644
> >> --- a/common/spl/Kconfig
> >> +++ b/common/spl/Kconfig
> >> @@ -1203,6 +1203,16 @@ config SPL_SECURE_OS_BOOT
> >>  	  Enables support for secure boot in falcon mode by restricting the SPL to
> >>  	  only loading a fitImage instead of raw kernel images or DTBs.
> >>  
> >> +config SPL_FALCON_ALLOW_FALLBACK
> >
> > SPL_OS_BOOT_ALLOW_FALLBACK please.
> >
> >> +	bool "Allow fallback to regular boot if falcon mode fails"
> >> +	depends on SPL_OS_BOOT && SYS_MMCSD_FS_BOOT && !SPL_SECURE_OS_BOOT
> >
> > This should just be SPL_OS_BOOT && !SPL_OS_BOOT_SECURE.
> >
> > Then in a follow-up patch we need to go and modify spl_*_load_os to make
> > use of the new flag and if fail to load the OS image we panic() if we
> > can't fall back.
> 
> A quick general question here, in cases where we want a function to lead
> to a boot failure. Is it better to return an error, hoping the caller to
> handle it and stop the boot process or panic within the function body to
> begin with?
> 
> int spl_do_*_os_boot() {
> 	int ret = spl_load_kernel_image(...);
> 
> 	if (ret && !CONFIG_IS_ENABLED(OS_BOOT_ALLOW_FALLBACK))
> 		return ret; OR panic("Failed to os boot");
> 
> 	/* fallback */
> }
> 
> From a security PoV, I see the point in explicitly halting the boot
> right within the function body but returning the error conforms to
> standard error handling practices.

As part of implementing this, it's a little bit up to you here. I didn't
immediately see a good fall back path to panic at the higher level but
I could have just missed it. But the important thing is that if we're
secure and we fail to load and fallback is disabled, we need to panic
somewhere.

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