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

[Anshul Dalal]

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.

Regards,
Anshul