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 X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45FDCC433EF for ; Sat, 18 Sep 2021 10:26:21 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 55626610E9 for ; Sat, 18 Sep 2021 10:26:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 55626610E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C450F829FC; Sat, 18 Sep 2021 12:26:17 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="gmB57WSQ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C9E7282BC3; Sat, 18 Sep 2021 12:26:16 +0200 (CEST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 605BB81D6C for ; Sat, 18 Sep 2021 12:26:11 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=francois.ozog@linaro.org Received: by mail-ed1-x52b.google.com with SMTP id q3so39808836edt.5 for ; Sat, 18 Sep 2021 03:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IWnfVzb9pOAQPSD+nAg5T12DlDmmgLVv1lV5awB2Ets=; b=gmB57WSQUw0BPbEtf6pPITiOFQ5BWwk6vE3BvLmZ6tXdZQ08aXe9JyLUJROe1bRXdX 1FnnEYwCEZGwYu7Sq1Xb8UdZOYPWyhA/R59ZHADSDuhlx4dGs72nQnggNJn//IjLP5ha w+qhwuaXgI9387RVc8LR1SCTLWxjfyM4VR21NRj1OeG6EML564lIhyhT/Wx77jeTaxO+ IQFhs6T6iMSTX9vvQr6INPqb4xUNAXkY74htRoAfcw1WLH8mRB9ycg0JFg2caLwkkcFA NIcTHIxk1Aqg+52iqwaf2FufPP2XdNrcCISno9w5WadSqMsnj1xbNXhFq4y44yMMQNis dNhw== 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=IWnfVzb9pOAQPSD+nAg5T12DlDmmgLVv1lV5awB2Ets=; b=iMMi6GxzCoXASdti43g4mcYcWCrETODp9QHjy1qtGrTmCSiiTUi9ICo6qJ7R7usfyN v+pdHNjQIvfaloVfGzErESlyLx43lGy+asgdk0Auqm0RaN4XcXh675ywibNk7YGLjr/U 1vyXrOTrXPRfeEb37hckb5u7ebHk/R2pQKjAIQcWbDwbcM7oKkWbuxySA9LQFiBGhE3A 55WvmnjSvS9G3kHWMUI0EPQoY8szTKBX1CfHagQRBOiTLKBIFVD2xCL4xGjcWJeHF/02 1h7YGSTOFA+haZaxYYYFWFfJbj04oJq7d+wdpqaeKyjCe6Ck37KgpmkFhD0lmuyOME79 IMDA== X-Gm-Message-State: AOAM531nzlqZnGSfC84MPEsB2Qr+XjwIVnT3WiRk8vs8kDDC7RaSm7oK QDutgrOBXC8ka9DS6k6irIPOhLfDtAznny/niJjXHQ== X-Google-Smtp-Source: ABdhPJzdNQ3rNz47zoMHnF2BICucSGOSf0WUh4aCSci8YXvZsybPNY0tTH7bwYW/UNp2z7qBQL48wCf0qguc93iGOhk= X-Received: by 2002:a17:906:dbcb:: with SMTP id yc11mr17519447ejb.111.1631960770840; Sat, 18 Sep 2021 03:26:10 -0700 (PDT) MIME-Version: 1.0 References: <561452b36639d218@bloch.sibelius.xs4all.nl> <56145f817ba7aedc@bloch.sibelius.xs4all.nl> <20210917172605.GA8971@bill-the-cat> <561469190b08558b@bloch.sibelius.xs4all.nl> In-Reply-To: <561469190b08558b@bloch.sibelius.xs4all.nl> From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Sat, 18 Sep 2021 12:26:00 +0200 Message-ID: Subject: Re: Problem with U-boot | Configuration Signature not being checked while booting To: Mark Kettenis Cc: Moiz Imtiaz , jehannazkhan@skyelectric.com, moiz.imtiaz@skyelectric.com, sjg@chromium.org, trini@konsulko.com, u-boot@lists.denx.de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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 Le sam. 18 sept. 2021 =C3=A0 12:10, Mark Kettenis = a =C3=A9crit : > > From: Moiz Imtiaz > > Date: Sat, 18 Sep 2021 14:47:51 +0500 > > > > >Nice! If you want to write something up extending the >documentation = on > > >how you made this work for Pi it would be much appreciated. > > > > Sure, would love to do a PR. > > > > I basically replaced the dtb that pi loads with control Dtb of uboot, b= ut > > will do a PR of documentation addition in respect to pi_4, detailing > > everything shortly :) > > Sorry, but I don't think this is safe. The Raspberry Pi firmware > makes changes to the device tree and it is unclear what requirements > it has in terms of names of nodes and compatible strings since the > firmware is closed source. It should be fine to add stuff to the DTB > that came with the firmware, but replacing it altogether is probably > going to break things in subtle ways. So I don't think that is > something we should advocate by documenting it in U-Boot. > The way I see the chain of trust is: I don=E2=80=99t know how the GPU firmw= are is checked (or even if it is checked), The GPU firmware does not check or measure the booted kernel from kernel=3Dxyz that it gets from the unverifie= d config.txt which have been building a hardware description from unverified files from the file system. Bottom line, trying to create a secure boot flow on RPI4 may lead into impression of security while it is not supported at hardware level. Impression of security can be worse than no security at all. Creating a DT overlay and specifying it in config.txt should be much > more robust than doing a wholesale replacement of the firmware DT. > > > It does verifies the kernel, and other loadables, except (Dtb) because > this > > is what Pi is giving to Uboot , not sure whether at "starting kernel" > stage > > Uboot passes its own Dtb (verified one) or the one passed by pi > > (unverified/ can't be verified, as it gets passed to Uboot by pi). So i= n > > true sense it's not a complete secure boot. Plus Pi_4 doesn't implement > the > > trustzone that Armv8 provides (Cortex A-72 ) so I am not sure how > difficult > > it would be for someone to change the config.txt(kernel=3Du-boot.bin) i= n > > memory (from attackers perspective), resulting in normal pi bootloader > to be > > loaded rather Uboot on next reboot. > > > > If pi can make the config.txt immutable from memory , have kind of secu= re > > world, than it would be great. Not sure, if pi has something as of this > in > > mind in near future implementation either. > > > > On Sat, 18 Sep 2021, 14:28 Simon Glass, wrote: > > > > Hi Tom, > > > > On Fri, 17 Sept 2021 at 11:26, Tom Rini wrote: > > > > > > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote: > > > > Hi Mark, > > > > > > > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis > > wrote: > > > > > > > > > > > From: Simon Glass > > > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600 > > > > > > > > > > Hi Simon, > > > > > > > > > > > Hi Mark, > > > > > > > > > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis > > wrote: > > > > > > > > > > > > > > > From: Moiz Imtiaz > > > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > Thanks for the reply. I already followed the steps > > mentioned in > > > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt". > > > > > > > > > > > > > > > > >I wonder if rpi is not using the devicetree compiled with > > U-Boot, but > > > > > > > > instead one provided by the earlier-stage firmware? > > > > > > > > > > > > > > > > Not sure, but seems like this is the case. I checked and > > there isn't any > > > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in > > u-boot. I tried to > > > > > > > > add the dtb and other dts dtsi > > > > > > > > > > < > https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/= broadcom > >files > > > > > > > > > > from the raspberry pi Linux and compile them with > > CONFIG_OF_SEPARATE and > > > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot > > the U-Boot and > > > > > > > > it would just give a blank screen*. I wonder why there isn= 't > > any device > > > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT no= t > > supported by > > > > > > > > RPI4? > > > > > > > > > > > > > > The issue with the rpi4 is that the addresses of devices mov= e > > around > > > > > > > based on the version of the Raspberry Pi firmware you're > > using. And > > > > > > > possibly on the amount of memory on the board as well. So > > U-Boot > > > > > > > pretty much has to use the device tree passed by the firmwar= e > > since > > > > > > > the device tree in the U-Boot tree would be wrong for many > > > > > > > combinations of firmware and hardware. > > > > > > > > > > > > > > Simon, this sort of thing is exactly the reason why I think > > the idea > > > > > > > of having all U-Boot configuration information in a single > > device tree > > > > > > > with the hardware description doesn't work everywhere. > > > > > > > > > > > > >From my reading of this thread, it rather reinforces the need > > to > > > > > > provide a way to give U-Boot the config it needs, in the > > devicetree. > > > > > > > > > > As long as that configuration is optional, yes, maybe. > > > > > > > > > > > It seems that rpi is actually OK in this regard. If you think > > about > > > > > > it, it would be pretty hopeless if first-stage firmware assume= d > > that > > > > > > it could provide a devicetree to whatever is next. > > > > > > > > > > Not hopeless. If that device tree provides a hardware descripti= on > > > > > that is complete enough to boot Linux, it should be good enough = to > > run > > > > > U-Boot. > > > > > > > > Not in general. I hope I have covered this in enormous detail in t= he > > > > devicetree patch. But if you don't need verified boot, SPL or some > > > > other feature that needs config, then perhaps you will get away wi= th > > > > it. > > > > > > Wait, why does SPL _need_ it? If something provides us with a devic= e > > > tree, we don't need u-boot,dm-spl as that's used to filter nodes in = to > > a > > > smaller DT to use. > > > > Yes, although if the filtering is not done I am not sure what SPL > > would do. In fact we don't have a way to provide two DTs (SPL, U-Boot > > proper) from a prior boot stage at present. > > > > > Dealing with u-boot,dm-pre-reloc could be trickier, > > > but means whatever loaded us needs to have enabled any early clocks = we > > > need. But even then, it's just going to be output related? And som= e > > > "was already configured" path could be used. > > > > My point is that ignoring U-Boot's devicetree requirements doesn't > > work in general. It may work in specific cases. It cannot work for > > verified boot of course. > > > > Regards, > > Simon > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog