From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 583D4C3ABB2 for ; Thu, 29 May 2025 01:09:30 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 660DD833E9; Thu, 29 May 2025 03:09:28 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=ti.com header.i=@ti.com header.b="C/kpT6Cs"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id ACDFB83394; Thu, 29 May 2025 03:09:26 +0200 (CEST) Received: from lelvem-ot02.ext.ti.com (lelvem-ot02.ext.ti.com [198.47.23.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 83E858338D for ; Thu, 29 May 2025 03:09:23 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=anshuld@ti.com Received: from fllvem-sh04.itg.ti.com ([10.64.41.54]) by lelvem-ot02.ext.ti.com (8.15.2/8.15.2) with ESMTP id 54T19LvK2249286; Wed, 28 May 2025 20:09:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1748480961; bh=ELlf3YNkoQzzdBnu0VbtpG2JzxnZGkN0YHAewIe29L8=; h=Date:CC:Subject:From:To:References:In-Reply-To; b=C/kpT6CsAGiTXcHuJZ3nVTWQL8QXzRhez0+MUiMbz9WLVnBLiIHQN4O6kD4ThhcFe QfO+zlqaxRFk9RRBXAV55dwAGraPNQDloIe0Iedq+fDjrfWbOZqIk1TVbGc+YVe3Vv cNxz7Fc8f/QAv4Cn/Er7VgJt6sirz2I/2duEx/WU= Received: from DLEE103.ent.ti.com (dlee103.ent.ti.com [157.170.170.33]) by fllvem-sh04.itg.ti.com (8.18.1/8.18.1) with ESMTPS id 54T19LHu3991437 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=FAIL); Wed, 28 May 2025 20:09:21 -0500 Received: from DLEE112.ent.ti.com (157.170.170.23) by DLEE103.ent.ti.com (157.170.170.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Wed, 28 May 2025 20:09:20 -0500 Received: from lelvem-mr05.itg.ti.com (10.180.75.9) by DLEE112.ent.ti.com (157.170.170.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Wed, 28 May 2025 20:09:21 -0500 Received: from localhost (dhcp-172-24-227-250.dhcp.ti.com [172.24.227.250]) by lelvem-mr05.itg.ti.com (8.18.1/8.18.1) with ESMTP id 54T19K7h870926; Wed, 28 May 2025 20:09:20 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Thu, 29 May 2025 06:38:49 +0530 Message-ID: CC: , , , Subject: Re: [PATCH v6 1/9] spl: Kconfig: allow K3 devices to use falcon mode From: Anshul Dalal To: Andrew Davis , "Raghavendra, Vignesh" , X-Mailer: aerc 0.20.1-0-g2ecb8770224a References: <20250428141235.1734014-1-anshuld@ti.com> <20250428141235.1734014-2-anshuld@ti.com> <3741d859-2048-4b32-9c1e-f551ec62d377@ti.com> <9183b5da-e8fb-4697-b0ba-da49e185c378@ti.com> In-Reply-To: <9183b5da-e8fb-4697-b0ba-da49e185c378@ti.com> X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean 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 e95b9b4437= bc >>>>>>>> ("ti_armv7_common: Disable Falcon Mode on HS devices") for older 3= 2-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 s= et >>>>>> 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_heade= r, >>>> 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 imag= e >>> that it loads and the only type of header we have enabled here is fitIm= age? >>=20 >> 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)) 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. ~ Anshul [1] https://github.com/u-boot/u-boot/blob/e04d137231f2e9e14708a32448c879125= b8e308f/cmd/Kconfig#L359 [2] https://lore.kernel.org/u-boot/D9QG8DY630MX.1OV8MBZIM4R8S@ti.com/