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 A823EC10F16 for ; Mon, 6 May 2024 11:52:39 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id F197B882F1; Mon, 6 May 2024 13:52:37 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=dolcini.it Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=dolcini.it header.i=@dolcini.it header.b="dLa4vI0S"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id ADD95882F7; Mon, 6 May 2024 13:52:36 +0200 (CEST) Received: from mail11.truemail.it (mail11.truemail.it [IPv6:2001:4b7e:0:8::81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 37D3E88280 for ; Mon, 6 May 2024 13:52:33 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=dolcini.it Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=francesco@dolcini.it Received: from francesco-nb (93-49-2-63.ip317.fastwebnet.it [93.49.2.63]) by mail11.truemail.it (Postfix) with ESMTPA id B9BF91FAC6; Mon, 6 May 2024 13:52:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolcini.it; s=default; t=1714996352; bh=evz29y0+sbx8kvfrhFmdStog7X+/Cjr7CSrOMj3OYQE=; h=From:To:Subject; b=dLa4vI0SAyogzNCfqttnCNEyFS5bxpGr+tWZeVllI3s9DuBGDjIrGqXuT4tjOLbpf yTxQ3ddEZrZkbqb+5f0lMFNwPvDf/8yjrY+wWFqiDI28mnkdNnK80BMDCTl6p67SR1 aa2yeu4HiExx15tdw6iwcmoiP3WeMhngv2Oh4EiZoGJ2GPNAht0I7CsLEdAQYIviJa ahXeiXoCwQwDRPuI8O0LRcUqTPVxx6tKyLdPby+oEISLxXvDQ8yiTw1Vkb5EtPjX7t r8koTfw9//XDoqcv6xvbB5byh9l1bUl4r5xgPVQkMLsU1Ctnv1NiwscU7WwEAf1TDY nxGN0cTgedixQ== Date: Mon, 6 May 2024 13:52:27 +0200 From: Francesco Dolcini To: Marek Vasut Cc: u-boot@lists.denx.de, anton.gres@ifm.com, ch@denx.de, "NXP i.MX U-Boot Team" , Adam Ford , Alper Nebi Yasak , Andrejs Cainikovs , Angus Ainslie , Emanuele Ghidoli , Fabio Estevam , Francesco Dolcini , Marcel Ziswiler , Rasmus Villemoes , Simon Glass , Stefan Eichenberger , Stefano Babic , Tim Harvey , Tom Rini , kernel@puri.sm, u-boot@dh-electronics.com Subject: Re: [PATCH v2 1/4] binman: Add nxp_imx8mcst etype for i.MX8M flash.bin signing Message-ID: <20240506115227.GA12786@francesco-nb> References: <20240503010518.263458-1-marex@denx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240503010518.263458-1-marex@denx.de> 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 Hello Marek, On Fri, May 03, 2024 at 03:05:09AM +0200, Marek Vasut wrote: > Add new binman etype which allows signing both the SPL and fitImage sections > of i.MX8M flash.bin using CST. There are multiple DT properties which govern > the signing process, nxp,loader-address is the only mandatory one which sets > the SPL signature start address without the imx8mimage header, this should be > SPL text base. The key material can be configured using optional DT properties > nxp,srk-table, nxp,csf-crt, nxp,img-crt, all of which default the key material > names generated by CST tool scripts. The nxp,unlock property can be used to > unlock CAAM access in SPL section. > > Signed-off-by: Marek Vasut I was not able to test or really look into your series [1], however I can relate with a comment from Tim Harvey. I think is important to keep in mind that that signing cannot be done with key material that is in-tree, because well, that's private, and I think we should not force people to branch to properly sign the binaries. I think that it would be valuable to share how do you foresee this used in a real environment. Francesco [1] so feel free to reference me to any already agreed discussion on the topic ...