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 386CFC433EF for ; Thu, 27 Jan 2022 15:08:00 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A5BB58386B; Thu, 27 Jan 2022 16:06:53 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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=chromium.org header.i=@chromium.org header.b="gbAdxswF"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3640F83807; Thu, 27 Jan 2022 16:06:25 +0100 (CET) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 867A4835C8 for ; Thu, 27 Jan 2022 16:06:21 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-oi1-x22e.google.com with SMTP id m9so6297670oia.12 for ; Thu, 27 Jan 2022 07:06:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ARpHGkMWC6IeqRSTOBshauEJqjneh5ibnUTompYczFk=; b=gbAdxswF8RXLUEq9DfGOGqFQoHX1Kqg4PfrYeqyBX6C88ll4Ni25rUEII4vRB2rbKU Z1CY2DnCogG9MYI5HURkIc3wLvuN9+ha/+4MZtNmT3HiSbfmJWChhhYHfflrt2CNJfe2 z0PbIPocQU8Kbhb7nmwENpvmZEqQ1Apoc7m1U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ARpHGkMWC6IeqRSTOBshauEJqjneh5ibnUTompYczFk=; b=abLfKbKolOildDmvQm18+4OnlfExES5aDRi/Cens/ZQeNe6lg7bhOYQ6n4YC1KE8wj F0hc3fZxsoq1IjPfg8d432F9d8Of3B+PrJQDmd5Mua9NlZbsRfAwJbKOyiyP42GxybzR +2WMQ911vPqFQqDDr9Z69hAfNXn7SkT3S0cfIzy155v7BDtDFBsglFT/bYmQpJtdTzDC wFJKeWJGJAAI9fkvd70d/N7LDr0VfSS89lyZRtBukmTqYfuOScD/jYwachq7ZIc0Ca7C sM42f3MMwy6eJjmEsurxmbAXkCmHECW6TfEjZe3N6ELGMOL0jvBZxp1PLdGvf2SgkLQD LLEw== X-Gm-Message-State: AOAM533bKk9E8Zlwabx2mwluxSlfxIc128/cZSj1mdm9fMO0m0cqFDTN ckeXTGyUl+ds+/S1B+6yxEjOy97tawUwAm4jpvZTZJY2c5U= X-Google-Smtp-Source: ABdhPJyASUlnx3yHguH5dO7bKeNFMDBt+el8CfQLX6W7yBSR7DGE+MlMo/C8YSigYDDm2Q+C0tltyN8jcmbjF1+ySg0= X-Received: by 2002:a05:6808:1903:: with SMTP id bf3mr2539439oib.18.1643295980019; Thu, 27 Jan 2022 07:06:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Simon Glass Date: Thu, 27 Jan 2022 08:06:05 -0700 Message-ID: Subject: Re: two questions on verified boot To: Rasmus Villemoes Cc: u-boot Content-Type: text/plain; charset="UTF-8" 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.5 at phobos.denx.de X-Virus-Status: Clean Hi Rasmus, On Sun, 21 Nov 2021 at 07:55, Rasmus Villemoes wrote: > > (1) When one wants to get rid of CONFIG_LEGACY_IMAGE_FORMAT, one also > has to wrap any boot script in a FIT rather than a uImage. While it's > not directly documented anywhere how to do that, it seems that a minimal > .its for achieving it is > > /dts-v1/; > > / { > description = "U-Boot script(s)"; > > images { > default = "boot"; > boot { > description = "Bootscript"; > data = /incbin/("boot.txt"); > type = "script"; > compression = "none"; > hash-1 { > algo = "sha256"; > }; > }; > }; > }; > > [The UX when one doesn't guess that the description string is mandatory > is rather sad, but that's a separate story.] > > Now, I can get that signed if I include a signature-foo node inside the > "boot" node, and also add a dummy empty /configurations node (otherwise > mkimage refuses to process it). But that will only work if I have added > a "required = image" property with the public key; if I want to use the > safer/saner "required = conf", how do I make sure any boot script is > properly signed? > > The code in source.c only cares about the images node and calls > fit_image_verify(), and there's no concept of "configuration" and > combining multiple images when talking about a simple boot script. By then the configuration should have been checked, though, right? At least, that is how bootm works. So it seems that the scripts are being done in a different way. > > (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 Yes the 'image' check does not protect against a mix & match attack - see doc/uImage.FIT/signature.txt > > images { > kernel { > data = blabla; > load = 0x1000000; > entry = 0x10000000; > signature { > ... // correct signature of blabla > }; > }; > }; > > and I know that the boot process uses $loadaddr = 0x40000000. What is to > stop me from modifying that FIT image to read > > images { > kernel { > data = blabla; > load = 0x1000000; > entry = 0x400abcde; > signature { > ... // correct signature of blabla > }; > }; > }; > some-other-node { > pwned = /incbin/("pwned"); > }; > > 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".) Yes I believe that is right. > > 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. Yes > 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. Yes, this matches the behaviour of the existing hashing properties. They only hash on the data itself. We could expand this to include the properties of the image node, I suppose. But do note that you really need 'config' signing to make things secure. Regards, Simon