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 C9323C433F5 for ; Sun, 21 Nov 2021 19:32:39 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7107B8321B; Sun, 21 Nov 2021 20:32:37 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linux.microsoft.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=linux.microsoft.com header.i=@linux.microsoft.com header.b="Qkom5ZaR"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6F3528329E; Sun, 21 Nov 2021 20:32:36 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by phobos.denx.de (Postfix) with ESMTP id 7363580FAE for ; Sun, 21 Nov 2021 20:32:33 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=dphadke@linux.microsoft.com Received: by linux.microsoft.com (Postfix, from userid 1046) id 6FB3620C7061; Sun, 21 Nov 2021 11:32:32 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6FB3620C7061 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1637523152; bh=4l1tOSYuS7oNcdRGLo/ZPI4RDKyHYuMSbTdrnfiD2g0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Qkom5ZaR1ojyPbqGivBmmwJA+y8oQ7B8FDSJ1XKS82qIDqYoA9V+EYPDAgTjSysx8 qc/CtfKtRmnb20+z+yHTSiFdNJGRNdsezMVbRbh7iO9CoUyCCaZ9+k2tDUjHAR+pHS as18WyL3Mw50eYbUR+hF2kxFNcyVB3+ZV2hohur0= From: Dhananjay Phadke To: rasmus.villemoes@prevas.dk Cc: sjg@chromium.org, u-boot@lists.denx.de Subject: Re: two questions on verified boot Date: Sun, 21 Nov 2021 11:32:19 -0800 Message-Id: <1637523139-14507-1-git-send-email-dphadke@linux.microsoft.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: References: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.37 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.2 at phobos.denx.de X-Virus-Status: Clean On 11/21/2021 6:55 AM, Rasmus Villemoes wrote: > (2) Assuming for the moment that I would be happy with just using > required=image, am I right in that not only does that mean that the > combination of kernel/fdt/initramfs is not verified, merely the > individual parts, but more importantly (a mix'n'match attack isn't > really very likely), _only_ the data property in each node is part of > what gets signed, not the other important properties such as load= and > entry=? IOW, suppose I have a FIT image with > > and I know that the boot process uses $loadaddr = 0x40000000. What is to > stop me from modifying that FIT image to read > > where 0xabcde is chosen to coincide with where the data part of the > pwned property lies in the modified FIT? (That pwned property can be put > anywhere; I could even just replace the signer-name property inside the > signature node with a value of "mkimage\0".) > > In fit_config_process_sig(), there's this elaborate dance with > fit_config_get_data()/fdt_find_regions() which, AFAICT, ends up > including all the property values (and the FDT_PROP tags and string > offsets etc.), and then we call info.crypto->sign() with some > appropriate region_count. But in fit_image_process_sig(), we call > info.crypto->sign() with nregions==1, and AFAICT, the data being signed > is just the value of the "data" property, nothing else. Couldn't agree more, I've been wondering on similar lines. It would be great to actually run digest over entire image (data + attributes) or config node (minus signature and hash subnodes if re-signing). It would have avoided CVE-2020-10648? Regards, Dhananjay