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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 E9F37C433EF for ; Sun, 12 Sep 2021 15:03:08 +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 04A9E6101E for ; Sun, 12 Sep 2021 15:03:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 04A9E6101E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com 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 2600E83124; Sun, 12 Sep 2021 17:03:05 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.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=konsulko.com header.i=@konsulko.com header.b="lCDLwMed"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id AB5DA83938; Sun, 12 Sep 2021 17:03:03 +0200 (CEST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 2373382D78 for ; Sun, 12 Sep 2021 17:03:00 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf33.google.com with SMTP id 4so4546678qvp.3 for ; Sun, 12 Sep 2021 08:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=aXUbP7YdIK7bz0Gd3ZkWaDG9Zk9P9IdiclhfbIGkOn0=; b=lCDLwMedu2nsyq5gAq30BfglnulmTAg2BhMBrGmtiiSJ8oDhJFzWuWEWXDTuOfwiD0 EDmMjYL61j+Id3Lsp5OFILKFU2KXBnFU6K4OvoAZLknyktTeAiDqf0LeNBWJSPF+Q2kp v1kZD1ViUUlxc9ETnMEJsok7Ks60WjLwOMekE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=aXUbP7YdIK7bz0Gd3ZkWaDG9Zk9P9IdiclhfbIGkOn0=; b=bmj8DRcht/llELw1EFxFhEMIzKmScGRmarDC4MHDg7wUOw3VxCQD3ZhCsjmbbnjqhZ 1WWqLcSciep9yDfagdCrp/75njH1l/rTpeag+i7+UeMHQWgmtTqVvsdKAji1VTXaox2M 5rukmlWln/3cWmhxEQ+YYo9gnYnFXAeeOYgLwxcS3nJmsu0pmsXoVpNrU71OCUsliXtH gOJk8i1bEi/hFMuJKoP26UqpB/+GUGeVmzpqgxqZEnqIm36BnuzMIlk1m7gA26xD3GJx Tjd804IrqX2GCt41GFifTbT9j1MFsgV2t4/RzfkXm0W1oT1bgurqddf+pXUpp5EFjqWf eh0g== X-Gm-Message-State: AOAM530Z+8LcvxNDJBHdqlKHJsGTISC3R8fScAXoBxtZy5RMSVGfFTHs kiJ+1D/G2iho9sCXSt8C467SDw== X-Google-Smtp-Source: ABdhPJzrrb3bpUI5gxPqXvLPvQHoOhdKS4BB4RmBHaH9NsJL4cUQhMPQa/gJN5QPJ0EmqP4Q/+vY2A== X-Received: by 2002:ad4:4a8b:: with SMTP id h11mr6629380qvx.3.1631458978785; Sun, 12 Sep 2021 08:02:58 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-415e-9dd0-c165-e94f.res6.spectrum.com. [2603:6081:7b01:cbda:415e:9dd0:c165:e94f]) by smtp.gmail.com with ESMTPSA id d9sm3325127qkn.124.2021.09.12.08.02.57 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 12 Sep 2021 08:02:57 -0700 (PDT) Date: Sun, 12 Sep 2021 11:02:55 -0400 From: Tom Rini To: Moiz Imtiaz Cc: Simon Glass , Mark Kettenis , U-Boot Mailing List , moiz.imtiaz@skyelectric.com, Jehannaz Khan Subject: Re: Problem with U-boot | Configuration Signature not being checked while booting Message-ID: <20210912150255.GZ12964@bill-the-cat> References: <561452b36639d218@bloch.sibelius.xs4all.nl> <20210911210545.GX12964@bill-the-cat> <561452f953d600b5@bloch.sibelius.xs4all.nl> <20210911213441.GY12964@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bBL4Cp/E4tg7ZwO1" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) 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 --bBL4Cp/E4tg7ZwO1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 12, 2021 at 02:58:12AM +0500, Moiz Imtiaz wrote: > Completely agreed, that a fully secure boot on pi won't be achievable > because the Root of Trust (ROT) cant be established from the BOTROM/EEPRO= M. > Plus Pi doesn't have any High Assurance Boot (HAB). But given the > scenerio, whatever we can achieve i.e if we can verify the kernel, the > device tree, from the bootloader, (u-boot) that would be great. >=20 > Currently the issue with Pi4 is that , signature verification is not being > done with u-boot, so wondering if that can be made possible. Right, OK. Yes, I think it would be possible, but you'll need to experiment a bit. You'll basically want to take the signature information that the U-Boot docs talk about out of the created device tree, and put it in its own file, and then have the Pi firmware apply that as an "overlay", as it assembles the tree to use. Then the regular mechanism U-Boot uses to use the passed in device tree should work. > >But that applies to the scenario where the public key is stored in the > > device tree embedded in u-boot itself as well >=20 > Just for the sake of knowledge, Isn't this the case with all u-boot, that > the public key is stored in the device tree (control FDT) and is embedded > in the u-boot. You're in experimental territory here, yes. The existing examples all are on platforms where a prior stage wouldn't be giving us a device tree. U-Boot should not actually care where the device tree comes from so long as it is correct. I've only got a Pi 3 in my CI lab, and since it's CI I also really hate fiddling with it since I then end up spending more time re-setting it for CI. --=20 Tom --bBL4Cp/E4tg7ZwO1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmE+FpYACgkQFHw5/5Y0 tyzCSgv+OXAjIUYRHM5720rfAn3+kaYp+hrWY0d9edDo9QArl7v23KKy2s7PmPBZ ICqo4bJdHv/PoSFu03g1j7FcRqzVV9gJe0Dlczpbe0PaqTO4gQLBSssS9CdZwIgO PF7XZ8AuSo0NY+RRfziXGiu60+wmEAKvzw604eVYtdY8nFpPDgJBOMAY1s5GX1zF /qazAT4f9XOgqGcuqD88+3tsGoSc1ZScGI2Rpa0uWFatBz5wBz8H/GCsjslFJALp WcjZ6kg6xjsFgBBP9e5hWbgfQZ3cxEV+G3bzccnfq/uH8Vznh6wKszlzeLoJDiA0 EFfk7ilE/89kRHXkvQbL5uuaMbBGHoty4GAv+RSrQ/9yPqg9sgVyXjJChB9QfP1A VcvSLHYcB3EIFA89cRMigW1tDGhlGzI88bObEaEzT8+5iJoB1vDj05jRPj/puHm6 f5b5GyjtfFbA5aITmYTKdvzxPCVPSdBpUCCifaJv5xMUnJzruN/RWecBcWOpjlQo mISSlS7i =vewp -----END PGP SIGNATURE----- --bBL4Cp/E4tg7ZwO1--