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

Raghavendra, Vignesh vigneshr at ti.com
Thu May 8 06:02:59 CEST 2025



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?

Regards
Vignesh


More information about the U-Boot mailing list