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 D324AC433FE for ; Mon, 7 Nov 2022 13:33:33 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id BED4A806D5; Mon, 7 Nov 2022 14:33:31 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=mork.no 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; secure) header.d=mork.no header.i=@mork.no header.b="lRQYKatz"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 08EA484EAB; Mon, 7 Nov 2022 14:33:30 +0100 (CET) Received: from louie.mork.no (louie.mork.no [IPv6:2001:41c8:51:8a:feff:ff:fe00:e5]) (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 306B780431 for ; Mon, 7 Nov 2022 14:33:27 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=mork.no Authentication-Results: phobos.denx.de; spf=none smtp.mailfrom=bjorn@miraculix.mork.no Received: from canardo.dyn.mork.no ([IPv6:2a01:799:c9c:2c00:0:0:0:1]) (authenticated bits=0) by louie.mork.no (8.15.2/8.15.2) with ESMTPSA id 2A7DXOEe804386 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) for ; Mon, 7 Nov 2022 13:33:26 GMT Received: from miraculix.mork.no ([IPv6:2a01:799:c9c:2c02:34cc:c78d:869d:3d9d]) (authenticated bits=0) by canardo.dyn.mork.no (8.15.2/8.15.2) with ESMTPSA id 2A7DXJQJ739091 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) for ; Mon, 7 Nov 2022 14:33:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1667827999; bh=OsLzhjc+zNtZ2IkhkgFNP5nGIIoFBFpGP46P+aJrRoQ=; h=From:To:Subject:References:Date:Message-ID:From; b=lRQYKatzxhnVN3wSPgHPyF/t3BCgSSPMi0weCW5p7CnIjYz3RP4xn9pNPwQl4mwQz YrViNFmxamKPbwq3ZC+/tnCJkbFYtVh1drysDYbo7ezV9l3Sl8tR5/3hv7/h8mBjwk 86HfmVLJ18f2stGSBFDYm4SU4+vzEyych0duezRE= Received: (nullmailer pid 57954 invoked by uid 1000); Mon, 07 Nov 2022 13:33:19 -0000 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: u-boot@lists.denx.de Subject: Re: [RFC v2 0/2] Prevent alignment issues with "in place" FIT configurations Organization: m References: <20221106154111.872209-1-bjorn@mork.no> Date: Mon, 07 Nov 2022 14:33:19 +0100 In-Reply-To: <20221106154111.872209-1-bjorn@mork.no> (=?utf-8?Q?=22Bj?= =?utf-8?Q?=C3=B8rn?= Mork"'s message of "Sun, 6 Nov 2022 16:41:09 +0100") Message-ID: <871qqex528.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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.6 at phobos.denx.de X-Virus-Status: Clean --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So if anyone looked at this, then you've noticed that it fails to consider signing. The design makes it hard to support the combination. Algnment must run last since signing may inject variable sized nodes before the fdt data properties. Signing must run last since it hashes the blob as it is, inluding FDT_NOP tags and property order. But we can trick this int working by signing before aligning to create the signature nodes with their proper size and position, and then sign again as a final step if we had to inject any FDT_NOP tags. The attached fix works for me, creating valid signatures with aligned images no matter how many times I re-sign the FIT with different length signature comments. Downsides is the obvious double signing, which we already accept for resizing, and a build-up of FDT_NOP tags. The latter is only an issue if you re-sign with signature node size changes. And there's at most one tag added per fdt node per signature update, so it's hardly a major problem. Bj=C3=B8rn --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: inline; filename=0001-fix-re-sign-if-nops-were-added.patch Content-Transfer-Encoding: quoted-printable >From 00f5cf3b08e44856ed826d427f63743180f3ae90 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Bj=3DC3=3DB8rn=3D20Mork?=3D Date: Sun, 6 Nov 2022 22:13:53 +0100 Subject: [RFC v2 3/2] fix: re-sign if nops were added MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Bj=C3=B8rn Mork --- tools/fit_image.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/tools/fit_image.c b/tools/fit_image.c index 2e215ca2199d..c29e209a8eea 100644 --- a/tools/fit_image.c +++ b/tools/fit_image.c @@ -66,6 +66,7 @@ static int fit_add_file_data(struct image_tool_params *pa= rams, size_t size_inc, struct stat sbuf; void *ptr; int ret =3D 0; + size_t oldsize; =20 tfd =3D mmap_fdt(params->cmdname, tmpfile, size_inc, &ptr, &sbuf, true, false); @@ -115,9 +116,22 @@ static int fit_add_file_data(struct image_tool_params = *params, size_t size_inc, } =20 if (!ret) { + oldsize =3D fdt_size_dt_struct(ptr); ret =3D fit_align_fdt_images(ptr); } =20 + /* new FDT_NOP tags must be included in the signed regions */ + if (!ret && oldsize !=3D fdt_size_dt_struct(ptr)) { + ret =3D fit_add_verification_data(params->keydir, + params->keyfile, dest_blob, ptr, + params->comment, + params->require_keys, + params->engine_id, + params->cmdname, + params->algo_name, + ¶ms->summary); + } + if (dest_blob) { munmap(dest_blob, destfd_size); close(destfd); --=20 2.30.2 --=-=-=--