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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 910B7C433F5 for ; Fri, 29 Oct 2021 05:20:48 +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 CF4DD61151 for ; Fri, 29 Oct 2021 05:20:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CF4DD61151 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 2B07B83480; Fri, 29 Oct 2021 07:20:45 +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=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="eE0S/BN9"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C1B578357A; Fri, 29 Oct 2021 07:20:42 +0200 (CEST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 138BF8331B for ; Fri, 29 Oct 2021 07:20:37 +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=takahiro.akashi@linaro.org Received: by mail-pg1-x530.google.com with SMTP id s136so8798590pgs.4 for ; Thu, 28 Oct 2021 22:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=5dN14k2YLiHDC4aY33c8qPOVEq+Iijlw64tUUrA4hGA=; b=eE0S/BN9MoNIYFTdsAXUY7JX6mS/D0XGIF5vbltBtAbb3mhzHpNfaY0IdWvZIP1tnx nBK6TBfR3F3svfhK+WeE0Nzzt3EJT8A2UOVhvjYDPtwSPkj9EJzkLm1qu/mXNj/nDh3Z I84z4jwNft1JAVmscAXgBPPpqrRPmN47dwMuoK+wSJhQMWj423wOeIix02gKfKOZepsz 1q5e5m9R908slpBIN+zqQAnmBxc5tbHPCBf+yPg4PWo/PbJ7rBNH1rvCJlH5l2tQcuJz TL5Sp3HB29l2DtnDyZrPhSXoglhOEyVrVNXiseJPhd/CfuvnFMWVsgJ0z8zeezx6UlrN UoWA== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=5dN14k2YLiHDC4aY33c8qPOVEq+Iijlw64tUUrA4hGA=; b=MkMMnmhw4Ib+OGsVr+m+YNe3sIRlMRPVICuOsF3QrTxQoxDl7wKsmNLWt5eCDh7AVr wWjuBIqitUTBqzNu+wo/Kf/q1hK8j2ELHXrlkcoWmEP3CuTrpuy4uD9/bUMnGiO1cv/t 2IHN5jgM4XHssCnQq5Kv0spQvyfzt5fnPzsYZMunD/Hpti3WYZ11ILSQEieuFhkjE8lL ZGIPPJIjZAHWITMjOmViqsT60xeBuz9Fi/EwJMiCFWGblo4QYXG/QJTfq/TfP3U1uTvM ah7N56YPPGcTQk9Xv76UOwjWzlMTEvbJrb77siYmDSb0pXv1SJSkBMIf/WBxmpALGU5T M2lA== X-Gm-Message-State: AOAM531k+pc0xhtMP56+QdztLzxNG5XOMIFcgcIBmXycp+I6r5b6XD/z UvuQ3A8G/8ii5KwAn2wKvWwl4u1e9ITUuw== X-Google-Smtp-Source: ABdhPJyVQ3slodvvR3/n/EXyQpqJEFPAFmoq5qrHSamc4wyfdfnYu5MLsnPqO8uQoU2pcb1WzMJ50Q== X-Received: by 2002:a63:794b:: with SMTP id u72mr6779182pgc.191.1635484835328; Thu, 28 Oct 2021 22:20:35 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:99fd:f5c5:d3a8:a6cf]) by smtp.gmail.com with ESMTPSA id k14sm4249455pga.65.2021.10.28.22.20.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Oct 2021 22:20:34 -0700 (PDT) Date: Fri, 29 Oct 2021 14:20:30 +0900 From: AKASHI Takahiro To: Simon Glass Cc: Heinrich Schuchardt , Alex Graf , Ilias Apalodimas , Sughosh Ganu , Masami Hiramatsu , u-boot@lists.denx.de Subject: Re: [PATCH v5 04/11] doc: update UEFI document for usage of mkeficapsule Message-ID: <20211029052030.GB33977@laputa> Mail-Followup-To: AKASHI Takahiro , Simon Glass , Heinrich Schuchardt , Alex Graf , Ilias Apalodimas , Sughosh Ganu , Masami Hiramatsu , u-boot@lists.denx.de References: <20211028062356.98224-1-takahiro.akashi@linaro.org> <20211028062356.98224-5-takahiro.akashi@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Thu, Oct 28, 2021 at 09:17:48PM -0600, Simon Glass wrote: > Hi Takahiro, > > On Thu, 28 Oct 2021 at 00:25, AKASHI Takahiro > wrote: > > > > Now we can use mkeficapsule command instead of EDK-II's script > > to create a signed capsule file. So update the instruction for > > capsule authentication. > > > > Signed-off-by: AKASHI Takahiro > > --- > > doc/develop/uefi/uefi.rst | 143 ++++++++++++++++++-------------------- > > 1 file changed, 67 insertions(+), 76 deletions(-) > > Reviewed-by: Simon Glass > > thoughts below > > > > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > > index f17138f5c765..864d61734bee 100644 > > --- a/doc/develop/uefi/uefi.rst > > +++ b/doc/develop/uefi/uefi.rst > > @@ -284,37 +284,52 @@ Support has been added for the UEFI capsule update feature which > > enables updating the U-Boot image using the UEFI firmware management > > protocol (FMP). The capsules are not passed to the firmware through > > the UpdateCapsule runtime service. Instead, capsule-on-disk > > -functionality is used for fetching the capsule from the EFI System > > -Partition (ESP) by placing the capsule file under the > > -\EFI\UpdateCapsule directory. > > - > > -The directory \EFI\UpdateCapsule is checked for capsules only within the > > -EFI system partition on the device specified in the active boot option > > -determined by reference to BootNext variable or BootOrder variable processing. > > -The active Boot Variable is the variable with highest priority BootNext or > > -within BootOrder that refers to a device found to be present. Boot variables > > -in BootOrder but referring to devices not present are ignored when determining > > -active boot variable. > > -Before starting a capsule update make sure your capsules are installed in the > > -correct ESP partition or set BootNext. > > +functionality is used for fetching capsules from the EFI System > > +Partition (ESP) by placing capsule files under the directory:: > > + > > + \EFI\UpdateCapsule > > Can we use forward slashes please? > > What is a backslash, even? DOS? Windows? UEFI specification. In this document, all the file paths are presented with backslashes. (See section 8.5.5 in version 2.9) Anyhow U-Boot UEFI internally converts the path with slashes. > > + > > +The directory is checked for capsules only within the > > +EFI system partition on the device specified in the active boot option, > > +which is determined by BootXXXX variable in BootNext, or if not, the highest > > +priority one within BootOrder. Any BootXXXX variables referring to devices > > +not present are ignored when determining the active boot option. > > + > > +Please note that capsules will be applied in the alphabetic order of > > +capsule file names. > > + > > +Creating a capsule file > > +*********************** > > + > > +A capsule file can be created by using tools/mkeficapsule. > > +To build this tool, enable:: > > + > > + CONFIG_TOOLS_MKEFICAPSULE=y > > + CONFIG_TOOLS_LIBCRYPTO=y > > + > > +Run the following command:: > > + > > + $ mkeficapsule \ > > + --index 1 --instance 0 \ > > + [--fit | --raw ] \ > > + > > > > Performing the update > > ********************* > > > > -Since U-boot doesn't currently support SetVariable at runtime there's a Kconfig > > -option (CONFIG_EFI_IGNORE_OSINDICATIONS) to disable the OsIndications variable > > -check. If that option is enabled just copy your capsule to \EFI\UpdateCapsule. > > - > > -If that option is disabled, you'll need to set the OsIndications variable with:: > > +Put capsule files under the directory mentioned above. > > +Then, following the UEFI specification, you'll need to set > > +the EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED > > +bit in OsIndications variable with:: > > > > => setenv -e -nv -bs -rt -v OsIndications =0x04 > > > > -Finally, the capsule update can be initiated either by rebooting the board, > > -which is the preferred method, or by issuing the following command:: > > +Since U-boot doesn't currently support SetVariable at runtime, its value > > +won't be taken over across the reboot. If this is the case, you can skip > > +this feature check with the Kconfig option (CONFIG_EFI_IGNORE_OSINDICATIONS) > > +set. > > > > - => efidebug capsule disk-update > > - > > -**The efidebug command is should only be used during debugging/development.** > > +Finally, the capsule update can be initiated by rebooting the board. > > > > Enabling Capsule Authentication > > ******************************* > > @@ -324,82 +339,58 @@ be updated by verifying the capsule signature. The capsule signature > > is computed and prepended to the capsule payload at the time of > > capsule generation. This signature is then verified by using the > > public key stored as part of the X509 certificate. This certificate is > > -in the form of an efi signature list (esl) file, which is embedded as > > -part of U-Boot. > > +in the form of an efi signature list (esl) file, which is embedded in > > +a device tree. > > > > The capsule authentication feature can be enabled through the > > following config, in addition to the configs listed above for capsule > > update:: > > > > CONFIG_EFI_CAPSULE_AUTHENTICATE=y > > - CONFIG_EFI_CAPSULE_KEY_PATH= > > > > The public and private keys used for the signing process are generated > > -and used by the steps highlighted below:: > > +and used by the steps highlighted below. > > > > - 1. Install utility commands on your host > > - * OPENSSL > > +1. Install utility commands on your host > > + * openssl > > * efitools > > > > - 2. Create signing keys and certificate files on your host > > +2. Create signing keys and certificate files on your host:: > > > > $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=CRT/ \ > > -keyout CRT.key -out CRT.crt -nodes -days 365 > > $ cert-to-efi-sig-list CRT.crt CRT.esl > > > > - $ openssl x509 -in CRT.crt -out CRT.cer -outform DER > > - $ openssl x509 -inform DER -in CRT.cer -outform PEM -out CRT.pub.pem > > - > > - $ openssl pkcs12 -export -out CRT.pfx -inkey CRT.key -in CRT.crt > > - $ openssl pkcs12 -in CRT.pfx -nodes -out CRT.pem > > - > > -The capsule file can be generated by using the GenerateCapsule.py > > -script in EDKII:: > > - > > - $ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \ > > - --monotonic-count --fw-version \ > > - --lsv --guid \ > > - e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose \ > > - --update-image-index --signer-private-cert \ > > - /path/to/CRT.pem --trusted-public-cert \ > > - /path/to/CRT.pub.pem --other-public-cert /path/to/CRT.pub.pem \ > > - > > - > > -Place the capsule generated in the above step on the EFI System > > -Partition under the EFI/UpdateCapsule directory > > - > > -Testing on QEMU > > -*************** > > +3. Run the following command to create and sign the capsule file:: > > > > -Currently, support has been added on the QEMU ARM64 virt platform for > > -updating the U-Boot binary as a raw image when the platform is booted > > -in non-secure mode, i.e. with CONFIG_TFABOOT disabled. For this > > -configuration, the QEMU platform needs to be booted with > > -'secure=off'. The U-Boot binary placed on the first bank of the NOR > > -flash at offset 0x0. The U-Boot environment is placed on the second > > -NOR flash bank at offset 0x4000000. > > + $ mkeficapsule --monotonic-count 1 \ > > + --private-key CRT.key \ > > + --certificate CRT.crt \ > > + --index 1 --instance 0 \ > > + [--fit | --raw ] \ > > + > > > > -The capsule update feature is enabled with the following configuration > > -settings:: > > +4. Insert the signature list into a device tree in the following format:: > > > > - CONFIG_MTD=y > > - CONFIG_FLASH_CFI_MTD=y > > - CONFIG_CMD_MTDPARTS=y > > - CONFIG_CMD_DFU=y > > - CONFIG_DFU_MTD=y > > - CONFIG_PCI_INIT_R=y > > - CONFIG_EFI_CAPSULE_ON_DISK=y > > - CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y > > - CONFIG_EFI_CAPSULE_FIRMWARE=y > > - CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y > > + { > > + signature { > > + capsule-key = [ ]; > > + } > > Can you add this feature to binman? A new entry type that takes the > capsule key could do it. We need some way of handling this a bit > better. As I said in the previous version, I don't know yet if binman is the best place. Can you give me a pointer where a similar feature is implemented in binman, please? > > + ... > > + } > > > > -In addition, the following config needs to be disabled(QEMU ARM specific):: > > + You can do this manually with:: > > > > - CONFIG_TFABOOT > > + $ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts > > + $ fdtoverlay -i orig.dtb -o new.dtb -v signature.dtbo > > > > -The capsule file can be generated by using the tools/mkeficapsule:: > > + where signature.dts looks like:: > > > > - $ mkeficapsule --raw --index 1 > > + &{/} { > > + signature { > > + capsule-key = /incbin/("CRT.esl"); > > + }; > > + }; > > Ick. I think your tool should just support adding the signature. # I may misunderstand your point. The whole purpose of this tool is to create a capsule file. Adding the signature to that file is simply an optional behavior. I don't see any reason that we should have those features in separate tools. On the other hand, step.4 mentioned above is to add public keys (x509 certificate list or signature list in UEFI terminology) to a device tree. This is a separate step. Clear? -Takahiro Akashi > > > > Executing the boot manager > > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- > > 2.33.0 > > > > Regards, > Simon > > > Regards, > SImon