[PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode

[Andrew Davis]

On 5/28/25 8:08 PM, Anshul Dalal wrote:
> On Wed May 28, 2025 at 9:09 PM IST, Andrew Davis wrote:
>> On 5/8/25 6:37 AM, Anshul Dalal wrote:
>>> On Thu May 8, 2025 at 9:32 AM IST, Vignesh Raghavendra wrote:
>>>>
>>>>
>>>> On 5/8/2025 8:42 AM, Anshul Dalal wrote:
>>>>> On Wed May 7, 2025 at 11:36 PM IST, Andrew Davis wrote:
>>>>>> On 5/6/25 10:33 PM, Anshul Dalal wrote:
>>>>>>> On Tue May 6, 2025 at 8:03 PM IST, Andrew Davis wrote:
>>>>>>>> On 4/28/25 9:12 AM, Anshul Dalal wrote:
>>>>>>>>> Falcon mode was disabled for TI_SECURE_DEVICE at commit e95b9b4437bc
>>>>>>>>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 32-bit
>>>>>>>>> HS devices and can be enabled on K3 devices.
>>>>>>>>>
>>>>>>>>> For secure boot, the kernel with x509 headers can be packaged in a fit
>>>>>>>> "can be", this is the issue. Security is not just allowing methods that
>>>>>>>> are security checked, but forcing the use of such methods. Setting
>>>>>>>> OS_BOOT opens up several paths that look for non-FIT images. These
>>>>>>>> images do not enforce authentication like FIT does. This means one can
>>>>>>>> bypass secure boot when OS_BOOT is enabled by simply placing a non-FIT
>>>>>>>> boot image on the boot media.
>>>>>>>>
>>>>>>> As per spl_load_image_ext_os, the SPL first tries to load the file set
>>>>>>> in falcon_args_file env variable but since it's not set in our case. And
>>>>>>> the only way to set them is by rebuilding u-boot as uEnv.txt is not
>>>>>>> supported at SPL stage.
>>>>>>>
>>>>>>> This means the SPL only loads CONFIG_SPL_FS_LOAD_ARGS_NAME and
>>>>>>> CONFIG_SPL_FS_LOAD_KERNEL_NAME which are set as the DTB and fitImage
>>>>>> What is stopping me from replacing the content of the file "fitImage"
>>>>>> with a normal kernel image? When loading that image the file type
>>>>>> will be detected as a normal kernel image and all FIT logic bypassed,
>>>>>> including authentication, breaking our secure chain of trust.
>>>>>>
>>>>>> Andrew
>>>>> That would require booti_setup to be executed in spl_parse_image_header,
>>>>> which is not possible on the R5 SPL since the required config symbol
>>>>> CMD_BOOTI is only available for ARM64 platforms.
>>>>>
>>>>> In the worst case we end up loading a 32-bit zImage which wouldn't
>>>>> boot on the Cortex-A cores anyway and would additionally require
>>>>> enabling CMD_BOOTZ (currently disabled) at build time.
>>>>
>>>> Is there any path where R5 SPL can be tricked to load and jump to
>>>> arbitrary binary? zImage, Image, elf, bin whatever?
>>>>
>>>> IOW, does SPL_OS_BOOT always check for some sort of header for the image
>>>> that it loads and the only type of header we have enabled here is fitImage?
>>>
>>> It does check for the header and proceeds only with the desired security
>>> enforced execution flow if the loaded image is FIT. For all other image
>>> types, they are guarded by config symbols that are set unset in our case
>>
>> Are you sure?
>>
>> The only thing preventing this from continuing in spl_parse_image_header()
>> is a check for CONFIG_SPL_PANIC_ON_RAW_IMAGE. Which is not set for us.
>>
>> After that we check if OS_BOOT is enabled and if so allow for kernel
>> images to also pass[0]. What stops this from functioning?
>>
>> Andrew
>>
>> [0] https://github.com/u-boot/u-boot/blob/master/common/spl/spl.c#L338
>>
> 
> It would not function because of the unset CONFIG_CMD_BOOTI which can
> only be set on 64 bit platforms anyway[1]. Hence the following check
> would fail in spl_parse_image_header:
> 
> if (CONFIG_IS_ENABLED(OS_BOOT) && IS_ENABLED(CONFIG_CMD_BOOTI))
> 

I linked the wrong line, the line a couple below for CONFIG_CMD_BOOTZ
is the one that concerns me.

> And as I said previously in the thread[2]; worst case is we load a
> 32-bit zImage, support for which would have to be explicitly enabled at
> build time as the respective config CMD_BOOTZ is kept unset currently.
> 

What forces CMD_BOOTZ to not be set? Can it be enabled in SPL at all?
If it can you should make it "depends on !TI_SECURE_DEVICE" like other
dangerous to the secure chain of trust configs.

Andrew

> ~ Anshul
> 
> [1] https://github.com/u-boot/u-boot/blob/e04d137231f2e9e14708a32448c879125b8e308f/cmd/Kconfig#L359
> [2] https://lore.kernel.org/u-boot/D9QG8DY630MX.1OV8MBZIM4R8S@ti.com/