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=-12.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 EDD9BC07E95 for ; Fri, 16 Jul 2021 06:50:56 +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 3E740613E3 for ; Fri, 16 Jul 2021 06:50:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E740613E3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmx.de 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 9AC3981E14; Fri, 16 Jul 2021 08:50:53 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de 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; secure) header.d=gmx.net header.i=@gmx.net header.b="bSGu1Lkr"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 53A3682000; Fri, 16 Jul 2021 08:50:52 +0200 (CEST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id AC58180C89 for ; Fri, 16 Jul 2021 08:50:47 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1626418246; bh=gq+O3fQktrKqhXpvVmmubXvC4YWe8tk7XFP4SJH5RM0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=bSGu1LkraqCBrfgouwBiS2PHHfCCSeJoDWK/25DzZxA0iAPwqJ4Ybuc8G3Sp0EIR2 sZmy1CB291hsx8pLq3UT9RkiZ68OB7vSjnZ8CjMrTNI6cmtE1eAZdwnygRkGluwLvb /8MQ1xScMP03xvtWnkCCafIQ4P0Mlk8imFdqsKPw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.35] ([88.152.144.157]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mel3t-1lW2vQ3869-00aicU; Fri, 16 Jul 2021 08:50:45 +0200 Subject: Re: [PATCH 3/3] doc: Update CapsuleUpdate READMEs To: Ilias Apalodimas Cc: masami.hiramatsu@linaro.org, takahiro.akashi@linaro.org, Alexander Graf , Sughosh Ganu , Simon Glass , u-boot@lists.denx.de References: <20210715170030.97758-1-ilias.apalodimas@linaro.org> <20210715170030.97758-3-ilias.apalodimas@linaro.org> From: Heinrich Schuchardt Message-ID: Date: Fri, 16 Jul 2021 08:50:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210715170030.97758-3-ilias.apalodimas@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:cxq9naX/d2pTrfj83k/kLGVhe6OQtZknCHJfPlhUsRrUeb/nqCz hqFfBGnJl+ReVH3NKMXG7cmKHGv5f/SLpb901j8YISfNP4PkEUtnDov0cs/oqKIbhoyPqI3 4vvTsqYo2Zmpv56C6umWdy4vGiz8mvzjhqgPms8E8yef+d9o+kMuhfJu/QDQWYnRIgRWnc6 RSuqFa2PFVlsJQwvj2QUg== X-UI-Out-Filterresults: notjunk:1;V03:K0:BLmS0mooGt0=:Mb/CY3mt6+38u35lmjJMZW ufp7+cd8CrX0cAwwB6FwVDONPgxST0ehu7fxgwn2YwTzAZFBqpsedhkDpypNF9IiSKcoMIPzN fj/tuFuXR2M7exfPZXKjXK9D9Zi+6a6mjOAs2tshsKXwlZ6i1TQ14ULANu5O0gDTa5AUC3zf7 t+JRaogpS42GSVPTgi1cuGIYKty+vE3HbSDACTZAKzjSPxPPrcwShMDiT8vjAEdFUa793sr6V z3OZcNLQsJn+LU5bgzgIcQ3nUdrrfUYE6FFM7A4CSyQK69JBAyBU/Fq9ARMN+2OO+AOXb+3yj 25EdTuHZXTV9PvYdj6FoCTVeCMjiAOi2N5n5dmw9wS5k73L5xhQd2k3pBfqNzc7muF9LCU0MP gTEunTC9QB3Z/DrI2M6VL05fpUkXsIUms2YEOwSnU1txuhbCwBt1Xsl3aZiXG8AgrRNGoLllz CY/FwIZhU7xsLUUJUKoNH14tSIVH/Wuao1HscQXTHnRqYJqoXicRTFajSUQ662Y6GMnJLV9wn LqAKALF6qis8uLHbFSYh6E4pu/0YbsQluMgH9vP4P+vjKAFJYgeiEZIqDfcA8IiW1sTnM0gG3 3zsarqVLRobA7HWRDWSbdrdf5239R1FWiTTVZf55yEsgFuAWvQPOUj5D4TEq1R47glWpglUs3 CoRaPmoQnws/TIXyYXpRrCz6CtnOJA0L1jXTDnXmuddsFtXVBEUT+oU9/2cirTPm12JhLC1fX EYAriPR/Q0kgf0DQChumBWsdPsmUXqzjWoiXqr+i/G40Ch+AZUTzK91unYSBv3Wj6rpKrZ77J QAADP609B0Wa6hME+28EHUNrlaeUz+WxhJrU6bP+FpQyHhjlfdlw3b8G/2WMQZ8fOej7N04OJ rQ4auOoCD1Nw4mSOAMKK9U0V7ZRrhXvmGQuK8QsbtQ8++Gn5jgeBsFIriFObwaJETchEkPQmn L2oNWm7TnTvBXF4dixTiwKRRA5S3fwh6DUqVuNP9Airydr23JcjjJ7wn73ZS//dS3zRTettDi 7hRdehf8GQJk/c+vqeNXUWJXSRnct7LY5hsAqavb/KypXMUZvk9943GYqds9hoHMfH3FyQiwR d21D8pXJk+JIhp4JoYrakvAuyMDccydEPNc 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 7/15/21 7:00 PM, Ilias Apalodimas wrote: > Since we removed embeddingg the capsule key into a .dtb and fixed > authenticated capsule updates for all boards, move the relevant > documentation in the efi file and update it accordingly > > Signed-off-by: Ilias Apalodimas > --- > doc/board/emulation/qemu_capsule_update.rst | 203 -------------------- > doc/develop/uefi/uefi.rst | 125 ++++++++++++ > 2 files changed, 125 insertions(+), 203 deletions(-) > delete mode 100644 doc/board/emulation/qemu_capsule_update.rst > > diff --git a/doc/board/emulation/qemu_capsule_update.rst b/doc/board/emu= lation/qemu_capsule_update.rst > deleted file mode 100644 > index 0a2286d039d9..000000000000 > --- a/doc/board/emulation/qemu_capsule_update.rst > +++ /dev/null > @@ -1,203 +0,0 @@ > -.. SPDX-License-Identifier: GPL-2.0+ > -.. Copyright (C) 2020, Linaro Limited > - > -Enabling UEFI Capsule Update feature > ------------------------------------- > - > -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. > - > -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=3Doff'. 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. > - > -The capsule update feature is enabled with the following configuration > -settings:: > - > - CONFIG_MTD=3Dy > - CONFIG_FLASH_CFI_MTD=3Dy > - CONFIG_CMD_MTDPARTS=3Dy > - CONFIG_CMD_DFU=3Dy > - CONFIG_DFU_MTD=3Dy > - CONFIG_PCI_INIT_R=3Dy > - CONFIG_EFI_CAPSULE_ON_DISK=3Dy > - CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=3Dy > - CONFIG_EFI_CAPSULE_FIRMWARE=3Dy > - CONFIG_EFI_CAPSULE_FIRMWARE_RAW=3Dy > - CONFIG_EFI_CAPSULE_FMP_HEADER=3Dy > - > -In addition, the following config needs to be disabled(QEMU ARM specifi= c):: > - > - CONFIG_TFABOOT > - > -The capsule file can be generated by using the tools/mkeficapsule:: > - > - $ mkeficapsule --raw --index 1 > - > -As per the UEFI specification, the capsule file needs to be placed on > -the EFI System Partition, under the \EFI\UpdateCapsule directory. The > -EFI System Partition can be a virtio-blk-device. > - > -Before initiating the firmware update, the efi variables BootNext, > -BootXXXX and OsIndications need to be set. The BootXXXX variable needs > -to be pointing to the EFI System Partition which contains the capsule > -file. The BootNext, BootXXXX and OsIndications variables can be set > -using the following commands:: > - > - =3D> efidebug boot add -b 0 Boot0000 virtio 0:1 > - =3D> efidebug boot next 0 > - =3D> setenv -e -nv -bs -rt -v OsIndications =3D0x04 > - =3D> saveenv > - > -Finally, the capsule update can be initiated with the following > -command:: > - > - =3D> efidebug capsule disk-update > - > -The updated U-Boot image will be booted on subsequent boot. > - > -Enabling Capsule Authentication > -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > - > -The UEFI specification defines a way of authenticating the capsule to > -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 the platform's device tree blob using the mkeficapsule > -utility. > - > -On the QEMU virt platforms, the device-tree is generated on the fly > -based on the devices configured. This device tree is then passed on to > -the various software components booting on the platform, including > -U-Boot. Therefore, on the QEMU virt platform, the signatute is > -embedded on an overlay. This overlay is then applied at runtime to the > -base platform device-tree. Steps needed for embedding the esl file in > -the overlay are highlighted below. > - > -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=3Dy > - > -The public and private keys used for the signing process are generated > -and used by the steps highlighted below:: > - > - 1. Install utility commands on your host > - * OPENSSL > - * efitools > - > - 2. Create signing keys and certificate files on your host > - > - $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=3DCRT/ \ > - -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.pu= b.pem > - > - $ openssl pkcs12 -export -out CRT.pfx -inkey CRT.key -in CRT.cr= t > - $ 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 > - > -For embedding the public key certificate, the following steps need to > -be followed:: > - > - 1. Generate a skeleton overlay dts file, with a single fragment > - node and an empty __overlay__ node > - > - A typical skeleton overlay file will look like this > - > - /dts-v1/; > - /plugin/; > - > - / { > - fragment@0 { > - target-path =3D "/"; > - __overlay__ { > - }; > - }; > - }; > - > - > - 2. Convert the dts to a corresponding dtb with the following > - command > - ./scripts/dtc/dtc -@ -I dts -O dtb -o \ > - > - > - 3. Run the dtb file generated above through the mkeficapsule tool > - in U-Boot > - ./tools/mkeficapsule -O -D > - > -Running the above command results in the creation of a 'signature' > -node in the dtb, under which the public key is stored as a > -'capsule-key' property. The '-O' option is to be used since the > -public key certificate(esl) file is being embedded in an overlay. > - > -The dtb file embedded with the certificate is now to be placed on an > -EFI System Partition. This would then be loaded and "merged" with the > -base platform flattened device-tree(dtb) at runtime. > - > -Build U-Boot with the following steps(QEMU ARM64):: > - > - $ make qemu_arm64_defconfig > - $ make menuconfig > - Disable CONFIG_TFABOOT > - Enable CONFIG_EFI_CAPSULE_AUTHENTICATE > - Enable all configs needed for capsule update(listed above) > - $ make all > - > -Boot the platform and perform the following steps on the U-Boot > -command line:: > - > - 1. Enable capsule authentication by setting the following env > - variable > - > - =3D> setenv capsule_authentication_enabled 1 > - =3D> saveenv > - > - 2. Load the overlay dtb to memory and merge it with the base fdt > - > - =3D> fatload virtio 0:1 <$fdtovaddr> EFI/ > - =3D> fdt addr $fdtcontroladdr > - =3D> fdt resize > - =3D> fdt apply <$fdtovaddr> > - > - 3. Set the following environment and UEFI boot variables > - > - =3D> setenv -e -nv -bs -rt -v OsIndications =3D0x04 > - =3D> efidebug boot add -b 0 Boot0000 virtio 0:1 > - =3D> efidebug boot next 0 > - =3D> saveenv > - > - 4. Finally, the capsule update can be initiated with the following > - command > - > - =3D> efidebug capsule disk-update > - > -On subsequent reboot, the platform should boot the updated U-Boot binar= y. > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > index 4f2b8b036db8..3d04228e8188 100644 > --- a/doc/develop/uefi/uefi.rst > +++ b/doc/develop/uefi/uefi.rst > @@ -277,6 +277,131 @@ Enable ``CONFIG_OPTEE``, ``CONFIG_CMD_OPTEE_RPMB``= and ``CONFIG_EFI_MM_COMM_TEE` > > [1] https://optee.readthedocs.io/en/latest/building/efi_vars/stmm.html > > +Enabling UEFI Capsule Update feature > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +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 th= e > +EFI system partition on the device specified in the active boot option > +determine by reference to BootNext variable or BootOrder variable proce= ssing. %s/determine/determined/ > +The active Boot Variable is the variable with highest priority BootNext= or Does only the device have to be present or also the file? Should we check only the binary or also the initrd? Best regards Heinrich > +within BootOrder that refers to a device found to be present. Boot vari= ables > +in BootOrder but referring to devices not present are ignored when dete= rmining > +active boot variable. > +Before starting a capsule update make sure your capsules are installed = in the > +correct ESP partition or set BootNext. > + > +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 v= ariable > +check. If that option is enabled just copy your capsule to \EFI\UpdateC= apsule. > + > +If that option is disabled, you'll need to set the OsIndications variab= le with:: > + > + =3D> setenv -e -nv -bs -rt -v OsIndications =3D0x04 > + > +Finally, the capsule update can be initiated either by rebooting the bo= ard, > +which is the preferred method, or by issuing the following command:: > + > + =3D> efidebug capsule disk-update > + > +**The efidebug command is should only be used during debugging/developm= ent.** > + > +Enabling Capsule Authentication > +******************************* > + > +The UEFI specification defines a way of authenticating the capsule to > +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. > + > +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=3Dy > + CONFIG_EFI_CAPSULE_KEY_PATH=3D > + > +The public and private keys used for the signing process are generated > +and used by the steps highlighted below:: > + > + 1. Install utility commands on your host > + * OPENSSL > + * efitools > + > + 2. Create signing keys and certificate files on your host > + > + $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=3DCRT/ \ > + -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.pu= b.pem > + > + $ openssl pkcs12 -export -out CRT.pfx -inkey CRT.key -in CRT.cr= t > + $ 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 > +*************** > + > +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=3Doff'. 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. > + > +The capsule update feature is enabled with the following configuration > +settings:: > + > + CONFIG_MTD=3Dy > + CONFIG_FLASH_CFI_MTD=3Dy > + CONFIG_CMD_MTDPARTS=3Dy > + CONFIG_CMD_DFU=3Dy > + CONFIG_DFU_MTD=3Dy > + CONFIG_PCI_INIT_R=3Dy > + CONFIG_EFI_CAPSULE_ON_DISK=3Dy > + CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=3Dy > + CONFIG_EFI_CAPSULE_FIRMWARE=3Dy > + CONFIG_EFI_CAPSULE_FIRMWARE_RAW=3Dy > + CONFIG_EFI_CAPSULE_FMP_HEADER=3Dy > + > +In addition, the following config needs to be disabled(QEMU ARM specifi= c):: > + > + CONFIG_TFABOOT > + > +The capsule file can be generated by using the tools/mkeficapsule:: > + > + $ mkeficapsule --raw --index 1 > + > Executing the boot manager > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > >