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.1ov8mbzim4...@ti.com/
