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

[Andrew Davis <afd@ti.com>]

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

> except for spl_parse_legacy_header which could be triggered but would
> just lead to a boot failure as we don't override the default weak
> definition.
> 
> Regards,
> Anshul
>