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.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 4960DC6377D for ; Thu, 22 Jul 2021 13:30:20 +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 C32EF60FED for ; Thu, 22 Jul 2021 13:30:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C32EF60FED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 72A8F8164D; Thu, 22 Jul 2021 15:30:17 +0200 (CEST) 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="QjZw/mKz"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3743282A01; Thu, 22 Jul 2021 15:30:15 +0200 (CEST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 4857D8023C for ; Thu, 22 Jul 2021 15:30:05 +0200 (CEST) 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-ot1-x32b.google.com with SMTP id o72-20020a9d224e0000b02904bb9756274cso5261619ota.6 for ; Thu, 22 Jul 2021 06:30:05 -0700 (PDT) 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:content-transfer-encoding; bh=oaYZwdMPm5Z/5xF9TkzDnhEeadba0vgemDytCTYTV40=; b=QjZw/mKzubIpDh76f0uDVpN+9hMHty+Vi4Z/wpN8e4aRKOUWvJwSJsdHHdELcA8+KL v7PymH4J06KdrXTYBsacbDdIsDfPg9sqoHM3Pxscxj4caitHtv/2rBn8z/xibBqCJWz0 FYOL2MVxRb05Ahe/86X8sOOnrNLGFKK0bZE/k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oaYZwdMPm5Z/5xF9TkzDnhEeadba0vgemDytCTYTV40=; b=CsPw9G1Ef0QfX0GUKDLrBlk66KXOn/OtumyNryfmRHLfivOjx5L5ayaw0bCi/+4qDm ywn2/kJLc/z66pNTykOPWhwvssigkgIWpdk9uMxFQAO/xvK/wCvx8BLST5APZqvRd7XV LW7uOIRdqdaJlC2gmOX8Lm7E4Rmw4SXV9eOc6wUwA76DZEJ/TP5eAJ3NvQwTNSPthaXq yzpV7cMRiPHxflN4oQtZuPcYKl7qqFvk4FOQ1SS7KdkOqplaAc0pGTayldHnmL8HlsJw 5OhN4G+vp/TqIEeVGjeYSZED8K90BOMCH4481dXswIJYuZczGEAdLLUSh5f7SC6HDbrU RoMg== X-Gm-Message-State: AOAM531msHsx+wdaB/U/8YF98PT3WdZpLA6V8BDWNVIEUPrENE+SlWBe 2Xt1q9fZnGSTPMXNuAbQX7mjue0I71GDxfD8yRuYRA== X-Google-Smtp-Source: ABdhPJyIEfeLlBgHFQ5rXS+4RPG2FGPGXWHK7gXq+W4nzi4QAOu8TNxi/g/wrt2kjQ2Wke/63iRUKRp5L56XhZJ2lP4= X-Received: by 2002:a05:6830:2317:: with SMTP id u23mr8892368ote.88.1626960603467; Thu, 22 Jul 2021 06:30:03 -0700 (PDT) MIME-Version: 1.0 References: <20210717142648.26588-1-ilias.apalodimas@linaro.org> In-Reply-To: From: Simon Glass Date: Thu, 22 Jul 2021 07:29:51 -0600 Message-ID: Subject: Re: [PATCH 1/3 v2] efi_capsule: Move signature from DTB to .rodata To: Ilias Apalodimas Cc: Sughosh Ganu , Heinrich Schuchardt , AKASHI Takahiro , Masami Hiramatsu , Alexander Graf , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Hi Ilias, On Thu, 22 Jul 2021 at 07:28, Simon Glass wrote: > > Hi Ilias, > > On Wed, 21 Jul 2021 at 00:42, Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > On Tue, 20 Jul 2021 at 20:42, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Tue, 20 Jul 2021 at 07:32, Sughosh Ganu = wrote: > > > > > > > > hi Simon, > > > > > > > > On Tue, 20 Jul 2021 at 18:20, Ilias Apalodimas wrote: > > > >> > > > >> Hi Simon, > > > >> On Tue, 20 Jul 2021 at 15:33, Simon Glass wrote= : > > > >> > > > > >> > Hi Ilias, > > > >> > > > > >> > On Sat, 17 Jul 2021 at 08:27, Ilias Apalodimas > > > >> > wrote: > > > >> > > > > > >> > > The capsule signature is now part of our DTB. This is problem= atic when a > > > >> > > user is allowed to change/fixup that DTB from U-Boots command = line since he > > > >> > > can overwrite the signature as well. > > > >> > > > > >> > Just to repeat my question since it looks like I didn't get a re= sponse > > > >> > on the last patch: > > > >> > > > > >> > Do you mean with the 'fdt' command? > > > >> > > > > > >> > If you mean the FDT fixups, they happen to a different DT, the o= ne > > > >> > being passed to Linux. > > > >> > > > >> In some platforms the key is derived from the relocated DTB, which= we > > > >> can overwrite. But I'll let Sughosh who figured it out explain the > > > >> details. > > > > > > > > > > > > On platforms where the dtb is concatenated with the u-boot image, u= sing CONFIG_OF_SEPARATE, the fdt is also getting relocated to the main memo= ry. We retrieve the public key from this dtb. By default, the fdtcontroladd= r env variable is getting set to this relocated dtb address -- this address= can also be accessed using the bdinfo command. Thus the public key can be = modified before attempting the capsule update. Which is the reason why Ilia= s is moving the public key to the embedded rodata section. > > > > > > You should be clearer about what problem you are trying to solve. Are > > > you worried about a script changing the DT? Or just it being writable > > > in general? > > > > Being writable in general is my main concern. Doing fixup internally > > from U-Boot might be something we'll always need but the ability to > > completely change it doesn't play well security. > > > > > > > > U-Boot itself is relocated also, including the rodata. So are you > > > using the public key from the original location? What if that is not > > > accessible after relocation? > > > > We are accessing he key from the relocated address. > > Then in what way are you protecting it? This is so confusing. Are you > saying that you are protecting the relocated address? If so, protect > the relocated devicetree too! > > > > > > > > > There is also the 'fdt addr -c' command to find the control DT. It is > > > not expected to be written to though. So just protect the memory to > > > which it is relocated, or relocate it to a place that you can protect= . > > > > Can you define 'protect'? The mmu support in U-Boot is kind of limited > > from what I can see. In order to protect anything we'd have to switch > > the pages ro R-- or RX-. Someone please shout if I am wrong, but I > > couldn't find code doing that in U-Boot. > > > > > > > > If the DT is writable it will affect U-Boot's operation, since that i= s > > > where all the config is stored. There is no point in pretending that > > > pulling one thing out of it and protecting it will result in any sort > > > of improvement. This needs to be done properly. > > > > Tbh I thought the relocation was done properly and the .rodata section > > was either merged with .text (and was RX-) or R--. > > If we fix the relocation properly, the .rodata will be read only, > > while the DTB should still be on RW memory. I understand that you > > are using the DTB for some configuration on U-Boot ,but arguably the > > public key of the EFI firmware you need to authenticate hardly > > classifies as configuration. > > What is it then? Please just do this properly. Add an API to protect memory, implement it for your chosen platform and then we will actually fix the problem you are worried about. Until then, work-arounds and hacks are pointless and just confuse the issue. Most haste, less speed. > > > Keep in mind that even if we fix the page tables permissions, on a > > secure platform the command line should be disabled, since anyone > > could load an arbitrary application and modify them. > > Yes we brought in CONFIG_CMDLINE for that reason about five years ago :-) Regards, SImon