[PATCH v6 0/9] Integrate EFI capsule tasks into u-boot's build flow
This patchset aims to bring two capsule related tasks under the u-boot build flow. One is the embedding of the public key into the platform's dtb. The public key is in the form of an EFI Signature List(ESL) file and is used for capsule authentication. This is being achieved by adding the signature node containing the capsule public key in the architecture's u-boot.dtsi file. Currently, the u-boot.dtsi file has been added for the sandbox and arm architectures. The path to the ESL file is being provided through a Kconfig symbol(CONFIG_EFI_CAPSULE_ESL_FILE). Changes have also been made to the test flow so that the keys used for signing the capsule, and the ESL file, are generated prior to invoking the u-boot's build, which enables embedding the ESL file into the dtb as part of the u-boot build. The other task is related to generation of capsules. The capsules can be generated as part of u-boot build, and this is being achieved through binman, by adding a capsule entry type. The capsules can be generated by specifying the capsule parameters as properties under the capsule entry node. Changes have also been made to the efi capsule update feature testing setup on the sandbox variants. Currently, the capsule files and the public key ESL file are generated after u-boot has been built. This logic has been changed so that the capsule input files along with the keys needed for capsule signing and authentication are generated prior to initiation of the u-boot build. The placement of all the files needed for generation of capsules is under the test/py/tests/test_efi_capsule/test_files/ directory. The document has been updated to reflect the above changes. Changes since V5: This series drops the changes for generating capsules by reading the params from a config file. This was suggested by Simon Glass. The config file changes would be submitted separately once these changes get merged. * Get rid of the logic of keeping the files under the /tmp/capsules/ directory from earlier versions. * New patch which introduces the input files and certs needed for EFI capsule update testing in the tree. * The capsule input files and certs are put under the test/py/tests/test_efi_capsule/test_files/ directory. * Add support for the oemflag parameter used in FWU A/B updates. This was missed in the earlier version. * Use a single function, generate_capsule in the mkeficapsule bintool, instead of the multiple functions in earlier version. * Remove the logic for generating capsules from config file as suggested by Simon. * Use required_props for image index and GUID parameters. * Use a subnode for the capsule payload instead of using a filename for the payload, as suggested by Simon. * Add a capsule generation test with oemflag parameter being passed. * Remove the documentation for generating the capsule through config file, as that functionality is not added through this series. * Use the public key ESL file from the tree instead of the /tmp/capsules/ directory being used in previous version. * Use the public key ESL file and other input files from the tree instead of the /tmp/capsules/ directory being used in previous version. * Use macros for other input files and certs. Sughosh Ganu (9): binman: bintool: Build a tool from a list of commands nuvoton: npcm845-evb: Add a newline at the end of file capsule: authenticate: Add capsule public key in platform's dtb doc: capsule: Document the new mechanism to embed ESL file into dtb test: capsule: Add files needed for testing EFI capsule updates binman: capsule: Add support for generating EFI capsules doc: Add documentation to highlight capsule generation related updates test: capsule: Remove public key embed logic from capsule update test sandbox: capsule: Generate capsule related files through binman arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +- arch/arm/dts/u-boot.dtsi | 14 + arch/sandbox/dts/u-boot.dtsi | 364 ++ configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig| 1 + configs/sandbox_spl_defconfig | 1 + doc/develop/uefi/uefi.rst | 40 +- lib/efi_loader/Kconfig| 9 + test/py/tests/test_efi_capsule/conftest.py| 165 +--- test/py/tests/test_efi_capsule/signature.dts | 10 - .../test_efi_capsule/test_files/SIGNER.crt| 19 + .../test_efi_capsule/test_files/SIGNER.esl| Bin 0 -> 829 bytes .../test_efi_capsule/test_files/SIGNER.key| 28 ++ .../test_efi_capsule/test_files/SIGNER2.crt | 19 + .../test_efi_capsule/test_files/SIGNER2.key | 28 ++ .../test_files/u-boot.bin.new | 1 + .../test_files/u-boot.bin.old | 1 + .../test_files/u-boot.env.new | 1 + .../test_files/u-boot.env.old | 1 + .../tests/test_efi_capsule/uboot_bin_env.its | 36 -- tools/bin
Re: [PATCH v5 03/12] capsule: authenticate: Add capsule public key in platform's dtb
hi Simon,
On Wed, 26 Jul 2023 at 19:56, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Wed, 26 Jul 2023 at 02:57, Sughosh Ganu wrote:
> >
> > hi Simon,
> >
> > On Wed, 26 Jul 2023 at 04:22, Simon Glass wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Tue, 25 Jul 2023 at 02:58, Sughosh Ganu
> > > wrote:
> > > >
> > > > The EFI capsule authentication logic in u-boot expects the public key
> > > > in the form of an EFI Signature List(ESL) to be provided as part of
> > > > the platform's dtb. Currently, the embedding of the ESL file into the
> > > > dtb needs to be done manually.
> > > >
> > > > Add a signature node in the u-boot dtsi file and include the public
> > > > key through the capsule-key property. This file is per architecture,
> > > > and is currently being added for sandbox and arm architectures. It
> > > > will have to be added for other architectures which need to enable
> > > > capsule authentication support.
> > > >
> > > > The path to the ESL file is specified through the
> > > > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > Changes since V4:
> > > > * Fix multi line comment format.
> > > > * Drop additional blank line.
> > > > * Remove the check for CONFIG_EFI_HAVE_CAPSULE_SUPPORT from arm's
> > > > u-boot.dtsi.
> > > > * Wrap the help text in the EFI_CAPSULE_ESL_FILE config at 72 chars.
> > > >
> >
> >
> >
> > > > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > > > new file mode 100644
> > > > index 00..60bd004937
> > > > --- /dev/null
> > > > +++ b/arch/sandbox/dts/u-boot.dtsi
> > > > @@ -0,0 +1,17 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * Devicetree file with miscellaneous nodes that will be included
> > > > + * at build time into the DTB. Currently being used for including
> > > > + * capsule related information.
> > > > + *
> > > > + */
> > > > +
> > > > +#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
> > > > +/ {
> > > > +#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> > > > + signature {
> > > > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > > > + };
> > > > +#endif
> > > > +};
> > > > +#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
> > >
> > > You missed my comment there. You should not need the outer #ifdef, but
> > > if you do, please combine them into one #if
> >
> > I did not miss your comment. The reason I have kept both the ifdefs is
> > that we need to include stuff which is needed only when
> > CONFIG_EFI_CAPSULE_AUTHENTICATE is enabled, and then the rest of the
> > stuff is needed only when CONFIG_EFI_HAVE_CAPSULE_SUPPORT is enabled.
> > Not having both the ifdefs would result in build failures. In the
> > u-boot.dtsi included for the arm arch, I am using a single ifdef,
> > since we are including only the signature node in that file.
>
> Well having
>
> / {
> };
>
> is harmless in all cases, I believe. So you should not need the outer one?
Sorry, I missed out this comment earlier. So this would not be an
empty node but contain the capsule generation nodes. This would result
in capsules getting generated for the sandbox_vpl and sandbox_noinst
variants which do not enable the capsule functionality.
-sughosh
Re: [PATCH v4 06/12] binman: capsule: Add support for generating capsules
hi Simon, On Wed, 26 Jul 2023 at 04:06, Simon Glass wrote: > > Hi Sughosh, > > On Thu, 20 Jul 2023 at 03:20, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Thu, 20 Jul 2023 at 00:41, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Wed, 19 Jul 2023 at 02:42, Sughosh Ganu > > > wrote: > > > > > > > > hi Simon, > > > > > > > > On Wed, 19 Jul 2023 at 06:41, Simon Glass wrote: > > > > > > > > > > Hi Sughosh, > > > > > > > > > > On Mon, 17 Jul 2023 at 04:44, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote: > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu > > > > > > > wrote: > > > > > > > > > > > > > > > > Add support in binman for generating capsules. The capsule > > > > > > > > parameters > > > > > > > > can be specified either through a config file or through the > > > > > > > > capsule > > > > > > > > binman entry. Also add test cases in binman for capsule > > > > > > > > generation, > > > > > > > > and enable this testing on the sandbox_spl variant. > > > > > > > > > > > > > > Can you use sandbox instead, or perhaps sandbox_spl? SPL is > > > > > > > really for > > > > > > > SPL testing. > > > > > > > > > > > > Er, I am actually using the sandbox_spl variant. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > --- > > > > > > > > Changes since V3: > > > > > > > > * Add test cases for covering the various capsule generation > > > > > > > > scenarios. > > > > > > > > * Add function comments in the mkeficapsule bintool. > > > > > > > > * Fix the fetch method of the mkeficapsule bintool to enable > > > > > > > > building > > > > > > > > the tool. > > > > > > > > * Add more details about the capsule parameters in the > > > > > > > > documentation > > > > > > > > as well as the code. > > > > > > > > * Fix order of module imports, and addition of blank lines in > > > > > > > > the > > > > > > > > capsule.py file. > > > > > > > > * Use SetContents in the ObtainContents method. > > > > > > > > > > > > > > > > configs/sandbox_spl_defconfig | 1 + > > > > > > > > tools/binman/btool/mkeficapsule.py| 158 > > > > > > > > ++ > > > > > > > > tools/binman/entries.rst | 37 > > > > > > > > tools/binman/etype/capsule.py | 132 > > > > > > > > +++ > > > > > > > > tools/binman/ftest.py | 127 > > > > > > > > ++ > > > > > > > > tools/binman/test/282_capsule.dts | 18 ++ > > > > > > > > tools/binman/test/283_capsule_signed.dts | 20 +++ > > > > > > > > tools/binman/test/284_capsule_conf.dts| 14 ++ > > > > > > > > tools/binman/test/285_capsule_missing_key.dts | 19 +++ > > > > > > > > .../binman/test/286_capsule_missing_index.dts | 17 ++ > > > > > > > > .../binman/test/287_capsule_missing_guid.dts | 17 ++ > > > > > > > > .../test/288_capsule_missing_payload.dts | 17 ++ > > > > > > > > tools/binman/test/289_capsule_missing.dts | 17 ++ > > > > > > > > tools/binman/test/290_capsule_version.dts | 19 +++ > > > > > > > > tools/binman/test/capsule_cfg.txt | 6 + > > > > > > > > 15 files changed, 619 insert
Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing
On Wed, 26 Jul 2023 at 22:09, Tom Rini wrote:
>
> On Wed, Jul 26, 2023 at 08:11:44PM +0530, Sughosh Ganu wrote:
> > hi Simon,
> >
> > On Wed, 26 Jul 2023 at 19:41, Simon Glass wrote:
> > >
> > > Hi Tom,
> > >
> > > On Wed, 26 Jul 2023 at 07:23, Tom Rini wrote:
> > > >
> > > > On Wed, Jul 26, 2023 at 03:16:38PM +0530, Sughosh Ganu wrote:
> > > > > On Wed, 26 Jul 2023 at 04:26, Tom Rini wrote:
> > > > > >
> > > > > > On Tue, Jul 25, 2023 at 04:52:38PM -0600, Simon Glass wrote:
> > > > > > > On Tue, 25 Jul 2023 at 02:58, Sughosh Ganu
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Support has being added through earlier commits to build
> > > > > > > > capsules
> > > > > > > > and embed the public key needed for capsule authentication as
> > > > > > > > part of
> > > > > > > > u-boot build.
> > > > > > > >
> > > > > > > > From the testing point-of-view, this means the input files
> > > > > > > > needed for
> > > > > > > > generating the above have to be setup before invoking the
> > > > > > > > build. Set
> > > > > > > > this up in the CI configuration docker file for testing the
> > > > > > > > capsule
> > > > > > > > update feature.
> > > > > > > >
> > > > > > > > Signed-off-by: Sughosh Ganu
> > > > > > > > ---
> > > > > > > > Changes since V4:
> > > > > > > > * New patch which moves the setting up of the files needed for
> > > > > > > > testing
> > > > > > > > the EFI capsule update feature to the Dockerfile.
> > > > > > > >
> > > > > > > > Note: Earlier, this setup was being done in the azure and
> > > > > > > > gitlab yaml
> > > > > > > > files. Now that this has been moved to the Dockerfile, this will
> > > > > > > > require generating a new container image and referencing that
> > > > > > > > image in
> > > > > > > > the yaml files for the CI to work when these patches get
> > > > > > > > applied.
> > > > > > > >
> > > > > > > > tools/docker/Dockerfile | 12
> > > > > > > > 1 file changed, 12 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
> > > > > > > > index 3d2b64a355..294a0b0a53 100644
> > > > > > > > --- a/tools/docker/Dockerfile
> > > > > > > > +++ b/tools/docker/Dockerfile
> > > > > > > > @@ -206,6 +206,18 @@ RUN mkdir -p /opt/nokia && \
> > > > > > > > cp /tmp/qemu-linaro/arm-softmmu/qemu-system-arm
> > > > > > > > /opt/nokia && \
> > > > > > > > rm -rf /tmp/qemu-linaro
> > > > > > > >
> > > > > > > > +# Set up capsule files for UEFI capsule update testing
> > > > > > > > +RUN mkdir -p /tmp/capsules && \
> > > > > > > > +cd /tmp/capsules/ && \
> > > > > > >
> > > > > > > You can just use ${UBOOT_TRAVIS_BUILD_DIR} here
> > > > > >
> > > > > > That's not present in Dockerfiles, only at runtime within jobs
> > > > > > (because
> > > > > > we set it).
> > > > >
> > > > > I can copy the files into UBOOT_TRAVIS_BUILD_DIR as part of the job,
> > > > > similar to what is being done for the grub*.efi files.
> > > >
> > > > Yes, copying the files rather than relying on them being in /tmp is
> > > > better, but..
> > > >
> > > > > > > > +echo -n "u-boot:Old" > u-boot.bin.old && \
> > > > > > > > +echo -n "u-boot:New" > u-boot.bin.new && \
> > > > > > > > +echo -n "u-boot-env:Old" > u-boot.env.old && \
> > > > > > > > +echo -n "u-boot-env
Re: [PATCH v4 06/12] binman: capsule: Add support for generating capsules
hi Simon, On Wed, 26 Jul 2023 at 04:06, Simon Glass wrote: > > Hi Sughosh, > > On Thu, 20 Jul 2023 at 03:20, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Thu, 20 Jul 2023 at 00:41, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Wed, 19 Jul 2023 at 02:42, Sughosh Ganu > > > wrote: > > > > > > > > hi Simon, > > > > > > > > On Wed, 19 Jul 2023 at 06:41, Simon Glass wrote: > > > > > > > > > > Hi Sughosh, > > > > > > > > > > On Mon, 17 Jul 2023 at 04:44, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote: > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu > > > > > > > wrote: > > > > > > > > > > > > > > > > Add support in binman for generating capsules. The capsule > > > > > > > > parameters > > > > > > > > can be specified either through a config file or through the > > > > > > > > capsule > > > > > > > > binman entry. Also add test cases in binman for capsule > > > > > > > > generation, > > > > > > > > and enable this testing on the sandbox_spl variant. > > > > > > > > > > > > > > Can you use sandbox instead, or perhaps sandbox_spl? SPL is > > > > > > > really for > > > > > > > SPL testing. > > > > > > > > > > > > Er, I am actually using the sandbox_spl variant. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > --- > > > > > > > > Changes since V3: > > > > > > > > * Add test cases for covering the various capsule generation > > > > > > > > scenarios. > > > > > > > > * Add function comments in the mkeficapsule bintool. > > > > > > > > * Fix the fetch method of the mkeficapsule bintool to enable > > > > > > > > building > > > > > > > > the tool. > > > > > > > > * Add more details about the capsule parameters in the > > > > > > > > documentation > > > > > > > > as well as the code. > > > > > > > > * Fix order of module imports, and addition of blank lines in > > > > > > > > the > > > > > > > > capsule.py file. > > > > > > > > * Use SetContents in the ObtainContents method. > > > > > > > > > > > > > > > > configs/sandbox_spl_defconfig | 1 + > > > > > > > > tools/binman/btool/mkeficapsule.py| 158 > > > > > > > > ++ > > > > > > > > tools/binman/entries.rst | 37 > > > > > > > > tools/binman/etype/capsule.py | 132 > > > > > > > > +++ > > > > > > > > tools/binman/ftest.py | 127 > > > > > > > > ++ > > > > > > > > tools/binman/test/282_capsule.dts | 18 ++ > > > > > > > > tools/binman/test/283_capsule_signed.dts | 20 +++ > > > > > > > > tools/binman/test/284_capsule_conf.dts| 14 ++ > > > > > > > > tools/binman/test/285_capsule_missing_key.dts | 19 +++ > > > > > > > > .../binman/test/286_capsule_missing_index.dts | 17 ++ > > > > > > > > .../binman/test/287_capsule_missing_guid.dts | 17 ++ > > > > > > > > .../test/288_capsule_missing_payload.dts | 17 ++ > > > > > > > > tools/binman/test/289_capsule_missing.dts | 17 ++ > > > > > > > > tools/binman/test/290_capsule_version.dts | 19 +++ > > > > > > > > tools/binman/test/capsule_cfg.txt | 6 + > > > > > > > > 15 files changed, 619 insert
Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing
hi Simon,
On Wed, 26 Jul 2023 at 19:41, Simon Glass wrote:
>
> Hi Tom,
>
> On Wed, 26 Jul 2023 at 07:23, Tom Rini wrote:
> >
> > On Wed, Jul 26, 2023 at 03:16:38PM +0530, Sughosh Ganu wrote:
> > > On Wed, 26 Jul 2023 at 04:26, Tom Rini wrote:
> > > >
> > > > On Tue, Jul 25, 2023 at 04:52:38PM -0600, Simon Glass wrote:
> > > > > On Tue, 25 Jul 2023 at 02:58, Sughosh Ganu
> > > > > wrote:
> > > > > >
> > > > > > Support has being added through earlier commits to build capsules
> > > > > > and embed the public key needed for capsule authentication as part
> > > > > > of
> > > > > > u-boot build.
> > > > > >
> > > > > > From the testing point-of-view, this means the input files needed
> > > > > > for
> > > > > > generating the above have to be setup before invoking the build. Set
> > > > > > this up in the CI configuration docker file for testing the capsule
> > > > > > update feature.
> > > > > >
> > > > > > Signed-off-by: Sughosh Ganu
> > > > > > ---
> > > > > > Changes since V4:
> > > > > > * New patch which moves the setting up of the files needed for
> > > > > > testing
> > > > > > the EFI capsule update feature to the Dockerfile.
> > > > > >
> > > > > > Note: Earlier, this setup was being done in the azure and gitlab
> > > > > > yaml
> > > > > > files. Now that this has been moved to the Dockerfile, this will
> > > > > > require generating a new container image and referencing that image
> > > > > > in
> > > > > > the yaml files for the CI to work when these patches get applied.
> > > > > >
> > > > > > tools/docker/Dockerfile | 12
> > > > > > 1 file changed, 12 insertions(+)
> > > > > >
> > > > > > diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
> > > > > > index 3d2b64a355..294a0b0a53 100644
> > > > > > --- a/tools/docker/Dockerfile
> > > > > > +++ b/tools/docker/Dockerfile
> > > > > > @@ -206,6 +206,18 @@ RUN mkdir -p /opt/nokia && \
> > > > > > cp /tmp/qemu-linaro/arm-softmmu/qemu-system-arm /opt/nokia
> > > > > > && \
> > > > > > rm -rf /tmp/qemu-linaro
> > > > > >
> > > > > > +# Set up capsule files for UEFI capsule update testing
> > > > > > +RUN mkdir -p /tmp/capsules && \
> > > > > > +cd /tmp/capsules/ && \
> > > > >
> > > > > You can just use ${UBOOT_TRAVIS_BUILD_DIR} here
> > > >
> > > > That's not present in Dockerfiles, only at runtime within jobs (because
> > > > we set it).
> > >
> > > I can copy the files into UBOOT_TRAVIS_BUILD_DIR as part of the job,
> > > similar to what is being done for the grub*.efi files.
> >
> > Yes, copying the files rather than relying on them being in /tmp is
> > better, but..
> >
> > > > > > +echo -n "u-boot:Old" > u-boot.bin.old && \
> > > > > > +echo -n "u-boot:New" > u-boot.bin.new && \
> > > > > > +echo -n "u-boot-env:Old" > u-boot.env.old && \
> > > > > > +echo -n "u-boot-env:New" > u-boot.env.new && \
> > > > >
> > > > > We don't want these files, just the certs, since they are the things
> > > > > that take a long time:
> > > > >
> > > > > > +openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > > > > > /CN=TEST_SIGNER/ -keyout SIGNER.key -out SIGNER.crt -nodes -days
> > > > > > 365 && \
> > > > > > +openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > > > > > /CN=TEST_SIGNER/ -keyout SIGNER2.key -out SIGNER2.crt -nodes -days
> > > > > > 365 && \
> > > > > > +cert-to-efi-sig-list SIGNER.crt SIGNER.esl && \
> > > > > > +chmod -R uog+rw /tmp/capsules/
> > > >
> > > > How long does it even take to make these certs? I'm not sure it's great
> > > > to make these and stage them in /tmp and expect them to be around at
> > > > test time.
> > >
> > > Should I mimic what is being done for the various grub.efi files? I
> > > believe that these are in the /opt/grub/ directory of the docker
> > > image, and get copied to the build dir at runtime.
> >
> > It takes 10 minutes or so to build grub, and we use it in multiple
> > tests. Running openssl takes not even a second. Why are we doing this
> > in the Dockerfile? Is this needed in more than one test? If so, does it
> > matter if we have the same certs in each test?
>
> Yes it is actually much faster that I expected, so I suppose we can go
> back to having it in the test itself, e.g. in a pytest fixture.
If not part of the docker image, these commands will still have to run
as part of the azure and gitlab yml files. They are needed before the
build is invoked, as they serve as input files needed to generate the
capsules as part of the build. The pytest fixtures would be run a)
only for the pytest stages and b) after the build has completed.
-sughosh
Re: [PATCH v5 08/12] doc: Add documentation to highlight capsule generation related updates
hi Heinrich,
On Tue, 25 Jul 2023 at 21:42, Heinrich Schuchardt wrote:
>
> On 25.07.23 10:57, Sughosh Ganu wrote:
> > The UEFI capsule can now be generate by specifying the capsule
> > parameters through a config file. Additionally, the capsules can be
> > generated as part of u-boot build, through binman. Highlight these
> > changes in the documentation.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V4: None
> >
> > doc/develop/uefi/uefi.rst | 84 +++
> > 1 file changed, 84 insertions(+)
> >
> > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> > index b2854b52a6..29955d943e 100644
> > --- a/doc/develop/uefi/uefi.rst
> > +++ b/doc/develop/uefi/uefi.rst
> > @@ -318,6 +318,79 @@ Run the following command
> > --guid \
> >
> >
> > +Alternatively, the capsules can be generated through a config
> > +file. When generating the capsules through a config file, the Kconfig
> > +symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the
> > +path to the config file.
> > +
> > +The config file describes the parameters that are used for generating
> > +one or more capsules. The parameters for a given capsule file are
> > +specified within curly braces, in the form of "key:value" pairs. All
> > +the parameters that are currently supported by the mkeficapsule tool
> > +can be specified through the config file.
> > +
> > +The following are some example payload parameters specified through
> > +the config file.
> > +
> > +.. code-block:: none
> > +
> > + {
> > + image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
> > + hardware-instance: 0
> > + monotonic-count: 1
> > + payload: u-boot.bin
> > + image-index: 1
> > + fw-version: 2
> > + private-key: /path/to/priv/key
> > + pub-key-cert: /path/to/pub/key
> > + capsule: u-boot.capsule
> > + }
> > + {
> > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
> > + hardware-instance: 0
> > + payload: u-boot.itb
> > + image-index: 2
> > + fw-version: 7
> > + oemflags: 0x8000
> > + capsule: fit.capsule
> > + }
> > + {
> > + capsule-type: accept
> > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
> > + capsule: accept.capsule
> > + }
> > + {
> > + capsule-type: revert
> > + capsule: revert.capsule
> > + }
>
> This seems to be neither YAML nor JSON. Can't we use a standardized
> format? YAML is easily parsed in C with libfyaml (see
> https://www.wpsoftware.net/andrew/pages/libyaml.html).
I used this key:value format since I wanted to keep this as close to
the one used in EDK2 as possible. EDK2 does use json files, but the
format is very similar to what I have introduced here. I have attached
a file for your reference.
-sughosh
>
> Best regards
>
> Heinrich
>
> > +
> > +The following are the keys that specify the capsule parameters
> > +
> > +..code-block:: none
> > +
> > +image-guid: Image GUID
> > +image-index: Image index value
> > +fw-version: Image version
> > +private-key: Path to the private key file used for capsule signing
> > +pub-key-cert: Path to the public key crt file used for capsule signing
> > +payload: Path to the capsule payload file
> > +capsule: Path to the output capsule file that is generated
> > +hardware-instance: Hardware Instance value
> > +monotonic-count: Monotonic count value
> > +capsule-type: Specifies capsule type. normal(default), accept or revert
> > +oemflags: 16bit Oemflags value to be used(populated in capsule header)
> > +
> > +When generating capsules through a config file, the command would look
> > +like
> > +
> > +.. code-block:: console
> > +
> > +$ mkeficapsule --cfg-file
> > +
> > +
> > +Capsule with firmware version
> > +*
> > +
> > The UEFI specification does not define the firmware versioning mechanism.
> > EDK II reference implementation inserts the FMP Payload Header right
> > before
> > the payload. It coutains the fw_version and lowest supported version,
> > @@ -345,6 +418,17 @@ add --fw-version option in mkeficapsule tool.
> > If the --fw-version option is not set, FMP Payload Header is not inserted
> > and fw_version is set as 0.
> >
> > +
> > +Capsule Generation through binman
> > +*
> > +
> > +Support has also been added to generate capsules during u-boot build
> > +through binman. This requires the platform's DTB to be populated with
> > +the capsule entry nodes for binman. The capsules then can be generated
> > +by specifying the capsule parameters either through a config file, or
> > +by specifying them as properties in the capsule entry node.
> > +
> > +
> > Performing the update
> > *
> >
>
rockpi_images.json
Description: application/json
Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing
On Wed, 26 Jul 2023 at 18:53, Tom Rini wrote:
>
> On Wed, Jul 26, 2023 at 03:16:38PM +0530, Sughosh Ganu wrote:
> > On Wed, 26 Jul 2023 at 04:26, Tom Rini wrote:
> > >
> > > On Tue, Jul 25, 2023 at 04:52:38PM -0600, Simon Glass wrote:
> > > > On Tue, 25 Jul 2023 at 02:58, Sughosh Ganu
> > > > wrote:
> > > > >
> > > > > Support has being added through earlier commits to build capsules
> > > > > and embed the public key needed for capsule authentication as part of
> > > > > u-boot build.
> > > > >
> > > > > From the testing point-of-view, this means the input files needed for
> > > > > generating the above have to be setup before invoking the build. Set
> > > > > this up in the CI configuration docker file for testing the capsule
> > > > > update feature.
> > > > >
> > > > > Signed-off-by: Sughosh Ganu
> > > > > ---
> > > > > Changes since V4:
> > > > > * New patch which moves the setting up of the files needed for testing
> > > > > the EFI capsule update feature to the Dockerfile.
> > > > >
> > > > > Note: Earlier, this setup was being done in the azure and gitlab yaml
> > > > > files. Now that this has been moved to the Dockerfile, this will
> > > > > require generating a new container image and referencing that image in
> > > > > the yaml files for the CI to work when these patches get applied.
> > > > >
> > > > > tools/docker/Dockerfile | 12
> > > > > 1 file changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
> > > > > index 3d2b64a355..294a0b0a53 100644
> > > > > --- a/tools/docker/Dockerfile
> > > > > +++ b/tools/docker/Dockerfile
> > > > > @@ -206,6 +206,18 @@ RUN mkdir -p /opt/nokia && \
> > > > > cp /tmp/qemu-linaro/arm-softmmu/qemu-system-arm /opt/nokia &&
> > > > > \
> > > > > rm -rf /tmp/qemu-linaro
> > > > >
> > > > > +# Set up capsule files for UEFI capsule update testing
> > > > > +RUN mkdir -p /tmp/capsules && \
> > > > > +cd /tmp/capsules/ && \
> > > >
> > > > You can just use ${UBOOT_TRAVIS_BUILD_DIR} here
> > >
> > > That's not present in Dockerfiles, only at runtime within jobs (because
> > > we set it).
> >
> > I can copy the files into UBOOT_TRAVIS_BUILD_DIR as part of the job,
> > similar to what is being done for the grub*.efi files.
>
> Yes, copying the files rather than relying on them being in /tmp is
> better, but..
>
> > > > > +echo -n "u-boot:Old" > u-boot.bin.old && \
> > > > > +echo -n "u-boot:New" > u-boot.bin.new && \
> > > > > +echo -n "u-boot-env:Old" > u-boot.env.old && \
> > > > > +echo -n "u-boot-env:New" > u-boot.env.new && \
> > > >
> > > > We don't want these files, just the certs, since they are the things
> > > > that take a long time:
> > > >
> > > > > +openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > > > > /CN=TEST_SIGNER/ -keyout SIGNER.key -out SIGNER.crt -nodes -days 365
> > > > > && \
> > > > > +openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > > > > /CN=TEST_SIGNER/ -keyout SIGNER2.key -out SIGNER2.crt -nodes -days
> > > > > 365 && \
> > > > > +cert-to-efi-sig-list SIGNER.crt SIGNER.esl && \
> > > > > +chmod -R uog+rw /tmp/capsules/
> > >
> > > How long does it even take to make these certs? I'm not sure it's great
> > > to make these and stage them in /tmp and expect them to be around at
> > > test time.
> >
> > Should I mimic what is being done for the various grub.efi files? I
> > believe that these are in the /opt/grub/ directory of the docker
> > image, and get copied to the build dir at runtime.
>
> It takes 10 minutes or so to build grub, and we use it in multiple
> tests. Running openssl takes not even a second. Why are we doing this
> in the Dockerfile? Is this needed in more than one test? If so, does it
> matter if we have the same certs in each test?
The reason why these files are needed is that they need to be present
before we start the build, for the sandbox variants. I was creating
these in the yml files in the earlier versions. Simon suggested
putting them in the docker file since these commands don't have to be
run on every invocation. These files are needed for the build and
pytest stages of the CI.
-sughosh
Re: [PATCH v5 08/12] doc: Add documentation to highlight capsule generation related updates
hi Simon,
On Wed, 26 Jul 2023 at 04:24, Simon Glass wrote:
>
> Hi,
>
> On Tue, 25 Jul 2023 at 10:18, Heinrich Schuchardt wrote:
> >
> > On 25.07.23 10:57, Sughosh Ganu wrote:
> > > The UEFI capsule can now be generate by specifying the capsule
> > > parameters through a config file. Additionally, the capsules can be
> > > generated as part of u-boot build, through binman. Highlight these
> > > changes in the documentation.
> > >
> > > Signed-off-by: Sughosh Ganu
> > > ---
> > > Changes since V4: None
> > >
> > > doc/develop/uefi/uefi.rst | 84 +++
> > > 1 file changed, 84 insertions(+)
> > >
> > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> > > index b2854b52a6..29955d943e 100644
> > > --- a/doc/develop/uefi/uefi.rst
> > > +++ b/doc/develop/uefi/uefi.rst
> > > @@ -318,6 +318,79 @@ Run the following command
> > > --guid \
> > >
> > >
> > > +Alternatively, the capsules can be generated through a config
> > > +file. When generating the capsules through a config file, the Kconfig
> > > +symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the
> > > +path to the config file.
> > > +
> > > +The config file describes the parameters that are used for generating
> > > +one or more capsules. The parameters for a given capsule file are
> > > +specified within curly braces, in the form of "key:value" pairs. All
> > > +the parameters that are currently supported by the mkeficapsule tool
> > > +can be specified through the config file.
> > > +
> > > +The following are some example payload parameters specified through
> > > +the config file.
> > > +
> > > +.. code-block:: none
> > > +
> > > + {
> > > + image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
> > > + hardware-instance: 0
> > > + monotonic-count: 1
> > > + payload: u-boot.bin
> > > + image-index: 1
> > > + fw-version: 2
> > > + private-key: /path/to/priv/key
> > > + pub-key-cert: /path/to/pub/key
> > > + capsule: u-boot.capsule
> > > + }
> > > + {
> > > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
> > > + hardware-instance: 0
> > > + payload: u-boot.itb
> > > + image-index: 2
> > > + fw-version: 7
> > > + oemflags: 0x8000
> > > + capsule: fit.capsule
> > > + }
> > > + {
> > > + capsule-type: accept
> > > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
> > > + capsule: accept.capsule
> > > + }
> > > + {
> > > + capsule-type: revert
> > > + capsule: revert.capsule
> > > + }
> >
> > This seems to be neither YAML nor JSON. Can't we use a standardized
> > format? YAML is easily parsed in C with libfyaml (see
> > https://www.wpsoftware.net/andrew/pages/libyaml.html).
>
> Can we please get this series landed without the config file at first?
> If it useful we can add it later, but it is a complexity that is not
> necessary for an initial series.
We do need support for generation of capsules through the config file.
There is another patchset [1] which will be leveraging generation of
capsules through the config file. I believe AMD(Xilinx) too is looking
for support of such functionality, whereby the capsule gets generated
after reading the parameters from the config file. Not being able to
generate capsules through the config file as part of the build would
be a half baked support.
In my earlier reply [2] to your concern about using relative paths for
capsule generation, I had mentioned that if we cannot extend binman
tests to use absolute paths, we can drop testing this scenario in the
binman tests suite since this feature is actually getting tested as
part of the larger EFI capsule update feature testing. Would that not
be okay with you? Else we have the option of using absolute paths for
the indir and outdir, instead of the runtime generated directories,
only for this feature test of course.
-sughosh
[1] - https://lists.denx.de/pipermail/u-boot/2023-June/520407.html
[2] - https://lists.denx.de/pipermail/u-boot/2023-July/523779.html
Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing
On Wed, 26 Jul 2023 at 04:26, Tom Rini wrote:
>
> On Tue, Jul 25, 2023 at 04:52:38PM -0600, Simon Glass wrote:
> > On Tue, 25 Jul 2023 at 02:58, Sughosh Ganu wrote:
> > >
> > > Support has being added through earlier commits to build capsules
> > > and embed the public key needed for capsule authentication as part of
> > > u-boot build.
> > >
> > > From the testing point-of-view, this means the input files needed for
> > > generating the above have to be setup before invoking the build. Set
> > > this up in the CI configuration docker file for testing the capsule
> > > update feature.
> > >
> > > Signed-off-by: Sughosh Ganu
> > > ---
> > > Changes since V4:
> > > * New patch which moves the setting up of the files needed for testing
> > > the EFI capsule update feature to the Dockerfile.
> > >
> > > Note: Earlier, this setup was being done in the azure and gitlab yaml
> > > files. Now that this has been moved to the Dockerfile, this will
> > > require generating a new container image and referencing that image in
> > > the yaml files for the CI to work when these patches get applied.
> > >
> > > tools/docker/Dockerfile | 12
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
> > > index 3d2b64a355..294a0b0a53 100644
> > > --- a/tools/docker/Dockerfile
> > > +++ b/tools/docker/Dockerfile
> > > @@ -206,6 +206,18 @@ RUN mkdir -p /opt/nokia && \
> > > cp /tmp/qemu-linaro/arm-softmmu/qemu-system-arm /opt/nokia && \
> > > rm -rf /tmp/qemu-linaro
> > >
> > > +# Set up capsule files for UEFI capsule update testing
> > > +RUN mkdir -p /tmp/capsules && \
> > > +cd /tmp/capsules/ && \
> >
> > You can just use ${UBOOT_TRAVIS_BUILD_DIR} here
>
> That's not present in Dockerfiles, only at runtime within jobs (because
> we set it).
I can copy the files into UBOOT_TRAVIS_BUILD_DIR as part of the job,
similar to what is being done for the grub*.efi files.
>
> > > +echo -n "u-boot:Old" > u-boot.bin.old && \
> > > +echo -n "u-boot:New" > u-boot.bin.new && \
> > > +echo -n "u-boot-env:Old" > u-boot.env.old && \
> > > +echo -n "u-boot-env:New" > u-boot.env.new && \
> >
> > We don't want these files, just the certs, since they are the things
> > that take a long time:
> >
> > > +openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > > -keyout SIGNER.key -out SIGNER.crt -nodes -days 365 && \
> > > +openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > > -keyout SIGNER2.key -out SIGNER2.crt -nodes -days 365 && \
> > > +cert-to-efi-sig-list SIGNER.crt SIGNER.esl && \
> > > +chmod -R uog+rw /tmp/capsules/
>
> How long does it even take to make these certs? I'm not sure it's great
> to make these and stage them in /tmp and expect them to be around at
> test time.
Should I mimic what is being done for the various grub.efi files? I
believe that these are in the /opt/grub/ directory of the docker
image, and get copied to the build dir at runtime.
-sughosh
Re: [PATCH v5 10/12] test: capsule: Remove public key embed logic from capsule update test
hi Simon, On Wed, 26 Jul 2023 at 04:24, Simon Glass wrote: > > On Tue, 25 Jul 2023 at 02:58, Sughosh Ganu wrote: > > > > The embedding of the public key EFI Signature List(ESL) file into the > > platform's DTB is now done at the time of u-boot build. Remove this > > logic from the capsule update test' configuration. > > > > Include the public key for the sandbox and sandbox_flattree variant > > as part of the build. > > > > Signed-off-by: Sughosh Ganu > > --- > > Changes since V4: None > > > > configs/sandbox_defconfig| 1 + > > configs/sandbox_flattree_defconfig | 1 + > > test/py/tests/test_efi_capsule/conftest.py | 37 > > test/py/tests/test_efi_capsule/signature.dts | 10 -- > > 4 files changed, 9 insertions(+), 40 deletions(-) > > delete mode 100644 test/py/tests/test_efi_capsule/signature.dts > > > > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig > > index 19cc6701e6..53e342b3fa 100644 > > --- a/configs/sandbox_defconfig > > +++ b/configs/sandbox_defconfig > > @@ -342,6 +342,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y > > CONFIG_EFI_CAPSULE_ON_DISK=y > > CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y > > CONFIG_EFI_CAPSULE_AUTHENTICATE=y > > +CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl" > > No, we cannot use hard-coded pathnames, still. > > Please grep for /tmp/capsules throughout your series. > > You should be able to drop the path if you put the file in the right > dir in the test. It runs in the working directory, I believe. Okay, let me check this out. -sughosh
Re: [PATCH v5 03/12] capsule: authenticate: Add capsule public key in platform's dtb
hi Simon,
On Wed, 26 Jul 2023 at 04:22, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Tue, 25 Jul 2023 at 02:58, Sughosh Ganu wrote:
> >
> > The EFI capsule authentication logic in u-boot expects the public key
> > in the form of an EFI Signature List(ESL) to be provided as part of
> > the platform's dtb. Currently, the embedding of the ESL file into the
> > dtb needs to be done manually.
> >
> > Add a signature node in the u-boot dtsi file and include the public
> > key through the capsule-key property. This file is per architecture,
> > and is currently being added for sandbox and arm architectures. It
> > will have to be added for other architectures which need to enable
> > capsule authentication support.
> >
> > The path to the ESL file is specified through the
> > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V4:
> > * Fix multi line comment format.
> > * Drop additional blank line.
> > * Remove the check for CONFIG_EFI_HAVE_CAPSULE_SUPPORT from arm's
> > u-boot.dtsi.
> > * Wrap the help text in the EFI_CAPSULE_ESL_FILE config at 72 chars.
> >
> > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > new file mode 100644
> > index 00..60bd004937
> > --- /dev/null
> > +++ b/arch/sandbox/dts/u-boot.dtsi
> > @@ -0,0 +1,17 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Devicetree file with miscellaneous nodes that will be included
> > + * at build time into the DTB. Currently being used for including
> > + * capsule related information.
> > + *
> > + */
> > +
> > +#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
> > +/ {
> > +#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> > + signature {
> > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > + };
> > +#endif
> > +};
> > +#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
>
> You missed my comment there. You should not need the outer #ifdef, but
> if you do, please combine them into one #if
I did not miss your comment. The reason I have kept both the ifdefs is
that we need to include stuff which is needed only when
CONFIG_EFI_CAPSULE_AUTHENTICATE is enabled, and then the rest of the
stuff is needed only when CONFIG_EFI_HAVE_CAPSULE_SUPPORT is enabled.
Not having both the ifdefs would result in build failures. In the
u-boot.dtsi included for the arm arch, I am using a single ifdef,
since we are including only the signature node in that file.
-sughosh
>
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index a22e47616f..0d559ff3a1 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -235,6 +235,15 @@ config EFI_CAPSULE_MAX
> > Select the max capsule index value used for capsule report
> > variables. This value is used to create CapsuleMax variable.
> >
> > +config EFI_CAPSULE_ESL_FILE
> > + string "Path to the EFI Signature List File"
> > + default ""
> > + depends on EFI_CAPSULE_AUTHENTICATE
> > + help
> > + Provides the absolute path to the EFI Signature List file which
> > + will be embedded in the platform's device tree and used for
> > + capsule authentication at the time of capsule update.
> > +
> > config EFI_DEVICE_PATH_TO_TEXT
> > bool "Device path to text protocol"
> > default y
> > diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> > index 1a8c8d7cab..c52c9d27bd 100644
> > --- a/lib/efi_loader/Makefile
> > +++ b/lib/efi_loader/Makefile
> > @@ -89,3 +89,10 @@ obj-$(CONFIG_EFI_ECPT) += efi_conformance.o
> >
> > EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
> > $(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
> > +
> > +ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
> > +EFI_CAPSULE_KEY_PATH := $(subst $\",,$(CONFIG_EFI_CAPSULE_ESL_FILE))
> > +ifeq ("$(wildcard $(EFI_CAPSULE_KEY_PATH))","")
> > +$(error .esl cerificate not found. Configure your
> > CONFIG_EFI_CAPSULE_ESL_FILE)
> > +endif
> > +endif
> > --
> > 2.34.1
> >
>
> Regards,
> Simon
Re: [PATCH v5 09/12] test: py: Setup capsule files for testing
hi Simon,
On Wed, 26 Jul 2023 at 04:23, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Tue, 25 Jul 2023 at 02:58, Sughosh Ganu wrote:
> >
> > Support has being added through earlier commits to build capsules and
> > embed the public key needed for capsule authentication as part of
> > u-boot build.
> >
> > From the testing point-of-view, this means the input files needed for
> > the above have to be setup before invoking the build. Set this up in
> > the pytest configuration file for testing the capsule update feature.
> >
> > Signed-off-by: Sughosh Ganu
> > Reviewed-by: Simon Glass
> > ---
> > Changes since V4: None
> >
> > test/py/conftest.py | 84 +
> > 1 file changed, 84 insertions(+)
> >
> > diff --git a/test/py/conftest.py b/test/py/conftest.py
> > index fc9dd3a83f..1092cb713b 100644
> > --- a/test/py/conftest.py
> > +++ b/test/py/conftest.py
> > @@ -80,6 +80,86 @@ def pytest_addoption(parser):
> > help='Run sandbox under gdbserver. The argument is the channel '+
> > 'over which gdbserver should communicate, e.g. localhost:1234')
> >
> > +def setup_capsule_build(source_dir, build_dir, board_type, log):
> > +"""Setup the platform's build for testing capsule updates
> > +
> > +This generates the payload/input files needed for testing the
> > +capsule update functionality, along with the keys for signing
> > +the capsules. An EFI Signature List(ESL) file, which houses the
> > +public key for capsule authentication is generated as
> > +well.
> > +
> > +The ESL file is subsequently embedded into the platform's
> > +dtb during the u-boot build, to be used for capsule
> > +authentication.
> > +
> > +Two sets of keys are generated, namely SIGNER and SIGNER2.
> > +The SIGNER2 key pair is used as a malicious key for testing the
> > +the capsule authentication functionality.
> > +
> > +All the generated files are placed under the /tmp/capsules/
> > +directory.
> > +
> > +Args:
> > +soruce_dir (str): Directory containing source code
> > +build_dir (str): Directory to build in
> > +board_type (str): board_type parameter (e.g. 'sandbox')
> > +log (Logfile): Log file to use
> > +
> > +Returns:
> > +Nothing.
> > +"""
> > +def run_command(name, cmd, source_dir):
> > +with log.section(name):
> > +if isinstance(cmd, str):
> > +cmd = cmd.split()
> > +runner = log.get_runner(name, None)
> > +runner.run(cmd, cwd=source_dir)
> > +runner.close()
> > +log.status_pass('OK')
> > +
> > +def gen_capsule_payloads(capsule_dir):
> > +fname = f'{capsule_dir}u-boot.bin.old'
> > +with open(fname, 'w') as fd:
> > +fd.write('u-boot:Old')
> > +
> > +fname = f'{capsule_dir}u-boot.bin.new'
> > +with open(fname, 'w') as fd:
> > +fd.write('u-boot:New')
> > +
> > +fname = f'{capsule_dir}u-boot.env.old'
> > +with open(fname, 'w') as fd:
> > +fd.write('u-boot-env:Old')
> > +
> > +fname = f'{capsule_dir}u-boot.env.new'
> > +with open(fname, 'w') as fd:
> > +fd.write('u-boot-env:New')
> > +
> > +capsule_sig_dir = '/tmp/capsules/'
> > +sig_name = 'SIGNER'
> > +mkdir_p(capsule_sig_dir)
> > +name = 'openssl'
> > +cmd = ( 'openssl req -x509 -sha256 -newkey rsa:2048 '
> > +'-subj /CN=TEST_SIGNER/ -keyout '
> > +f'{capsule_sig_dir}{sig_name}.key '
> > +f'-out {capsule_sig_dir}{sig_name}.crt -nodes -days 365' )
> > +run_command(name, cmd, source_dir)
>
> Can you drop this now that the docker file does it?
This handles the scenario of running the pytest on the host machine.
We can run the tests on our host machine as well, and the capsule
tests need to be supported even for that test scenario. The docker
file will only handle the CI environment.
-sughosh
>
> > +
> > +name = 'cert-to-efi-sig-list'
> > +cmd = ( f'cert-to-efi-sig-list {capsule_sig_dir}{sig_name}.crt '
> > +f'{capsule_sig_dir}{sig_name}.esl' )
> > +run_command(name, cmd, source_dir)
> > +
> > +sig_name = 'SIGNER2'
> > +name = 'openssl'
> > +cmd = ( 'o
[PATCH v5 12/12] sandbox: capsule: Generate capsule related files through binman
The EFI capsule files can now be generated as part of u-boot
build. This is done through binman. Add capsule entry nodes in the
u-boot.dtsi for the sandbox architecture for generating the
capsules. Remove the corresponding generation of capsules from the
capsule update conftest file.
The capsules are generated through the config file for the sandbox
variant, and through explicit parameters for the sandbox_flattree
variant.
Also generate the FIT image used for testing the capsule update
feature on the sandbox_flattree variant through binman. Remove the now
superfluous its file which was used for generating this FIT image.
Signed-off-by: Sughosh Ganu
---
Changes since V4:
* Define macros for the image GUIDs being used for generating the
capsules.
* Use lower case for image GUIDs.
arch/sandbox/dts/u-boot.dtsi | 271 ++
test/py/tests/test_efi_capsule/conftest.py| 127
.../tests/test_efi_capsule/uboot_bin_env.its | 36 ---
3 files changed, 271 insertions(+), 163 deletions(-)
delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
index 60bd004937..7606db3764 100644
--- a/arch/sandbox/dts/u-boot.dtsi
+++ b/arch/sandbox/dts/u-boot.dtsi
@@ -7,11 +7,282 @@
*/
#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
+
+#define SANDBOX_UBOOT_IMAGE_GUID "09d7cf52-0720-4710-91d1-08469b7fe9c8"
+#define SANDBOX_UBOOT_ENV_IMAGE_GUID "5a7021f5-fef2-48b4-aaba-832e777418c0"
+#define SANDBOX_FIT_IMAGE_GUID "3673b45d-6a7c-46f3-9e60-adabb03f7937"
+#define SANDBOX_INCORRECT_GUID "058b7d83-50d5-4c47-a195-60d86ad341c4"
+
/ {
#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
signature {
capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
};
#endif
+
+ binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ itb {
+ filename = "/tmp/capsules/uboot_bin_env.itb";
+
+ fit {
+ description = "Automatic U-Boot environment update";
+ #address-cells = <2>;
+
+ images {
+ u-boot-bin {
+ description = "U-Boot binary on SPI
Flash";
+ compression = "none";
+ type = "firmware";
+ arch = "sandbox";
+ load = <0>;
+ blob {
+ filename =
"/tmp/capsules/u-boot.bin.new";
+ };
+
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ u-boot-env {
+ description = "U-Boot environment on
SPI Flash";
+ compression = "none";
+ type = "firmware";
+ arch = "sandbox";
+ load = <0>;
+ blob {
+ filename =
"/tmp/capsules/u-boot.env.new";
+ };
+
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ };
+ };
+ };
+
+#ifdef CONFIG_EFI_USE_CAPSULE_CFG_FILE
+ capsule1 {
+ capsule {
+ cfg-file = CONFIG_EFI_CAPSULE_CFG_FILE;
+ };
+ };
+#else
+ capsule2 {
+ capsule {
+ image-index = <0x1>;
+ image-type-id = SANDBOX_UBOOT_IMAGE_GUID;
+ filename = "/tmp/capsules/u-boot.bin.new";
+ capsule = "/tmp/capsules/Test01";
+ };
+ };
+
+ capsule3 {
+ capsule {
+ image-index = <0x2>;
+ image-type-id = SANDBOX_UBOOT_ENV_IMAGE_GUID;
+ filename = "/tmp/capsules/u-boot.env.new";
+ capsule = "/tmp/capsules/Test02";
+ };
+ };
+
+ capsule4 {
+ capsule {
+ image-index = <0x1>;
+ image-type-id = SANDBOX_INCORRECT_GUID;
+ filename = "/tmp/capsule
[PATCH v5 07/12] binman: capsule: Add support for generating capsules
Add support in binman for generating capsules. The capsule parameters
can be specified either through a config file or through the capsule
binman entry. Also add test cases in binman for capsule generation,
and enable this testing on the sandbox_spl variant.
Signed-off-by: Sughosh Ganu
---
Changes since V4:
* Rebase on top of current HEAD.
* Remove blank lines after function comments.
* Fix a couple of typos.
* Use single quotes for strings.
* Put the GUIDs in variables with relevant names.
* Declare certain values in local variables instead of member values.
* Add comments for explaning the payload offsets in the capsule file.
* Drop the test case for generating the capsule from the config
file.
* Define payload data for the capsule tests.
* Add logic to find input and output files in capsule generation in
the indir and outdir directories when absolute path is not passed.
configs/sandbox_spl_defconfig | 1 +
tools/binman/btool/mkeficapsule.py| 153 ++
tools/binman/entries.rst | 42 +
tools/binman/etype/capsule.py | 132 +++
tools/binman/ftest.py | 115 +
tools/binman/test/307_capsule.dts | 19 +++
tools/binman/test/308_capsule_signed.dts | 21 +++
tools/binman/test/309_capsule_version.dts | 20 +++
tools/binman/test/310_capsule_missing_key.dts | 20 +++
.../binman/test/311_capsule_missing_index.dts | 18 +++
.../binman/test/312_capsule_missing_guid.dts | 17 ++
.../test/313_capsule_missing_payload.dts | 18 +++
tools/binman/test/314_capsule_missing.dts | 18 +++
tools/binman/test/files/capsule_cfg.txt | 6 +
14 files changed, 600 insertions(+)
create mode 100644 tools/binman/btool/mkeficapsule.py
create mode 100644 tools/binman/etype/capsule.py
create mode 100644 tools/binman/test/307_capsule.dts
create mode 100644 tools/binman/test/308_capsule_signed.dts
create mode 100644 tools/binman/test/309_capsule_version.dts
create mode 100644 tools/binman/test/310_capsule_missing_key.dts
create mode 100644 tools/binman/test/311_capsule_missing_index.dts
create mode 100644 tools/binman/test/312_capsule_missing_guid.dts
create mode 100644 tools/binman/test/313_capsule_missing_payload.dts
create mode 100644 tools/binman/test/314_capsule_missing.dts
create mode 100644 tools/binman/test/files/capsule_cfg.txt
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index 8d50162b27..65223475ab 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -249,3 +249,4 @@ CONFIG_UNIT_TEST=y
CONFIG_SPL_UNIT_TEST=y
CONFIG_UT_TIME=y
CONFIG_UT_DM=y
+CONFIG_TOOLS_MKEFICAPSULE=y
diff --git a/tools/binman/btool/mkeficapsule.py
b/tools/binman/btool/mkeficapsule.py
new file mode 100644
index 00..bfd6552b9a
--- /dev/null
+++ b/tools/binman/btool/mkeficapsule.py
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2023 Linaro Limited
+#
+"""Bintool implementation for mkeficapsule tool
+
+mkeficapsule is a tool used for generating EFI capsules.
+
+The following are the command-line options to be provided
+to the tool
+Usage: mkeficapsule [options]
+Options:
+ -g, --guid guid for image blob type
+ -i, --index update image index
+ -I, --instanceupdate hardware instance
+ -v, --fw-version firmware version
+ -p, --private-key private key file
+ -c, --certificate signer's certificate file
+ -m, --monotonic-count monotonic count
+ -d, --dump_sig dump signature (*.p7)
+ -A, --fw-accept firmware accept capsule, requires GUID, no image blob
+ -R, --fw-revert firmware revert capsule, takes no GUID, no image blob
+ -o, --capoemflag Capsule OEM Flag, an integer between 0x and 0x
+ -f, --cfg-file config file with capsule parameters
+ -h, --help print a help message
+"""
+
+from binman import bintool
+
+class Bintoolmkeficapsule(bintool.Bintool):
+"""Handles the 'mkeficapsule' tool
+
+This bintool is used for generating the EFI capsules. The
+capsule generation parameters can either be specified through
+command-line, or through a config file.
+"""
+def __init__(self, name):
+super().__init__(name, 'mkeficapsule tool for generating capsules')
+
+def capsule_cfg_file(self, cfg_file):
+"""Generate a capsule reading parameters from config file
+
+Args:
+cfg_file (str): Path to the config file
+
+Returns:
+str: Tool output
+"""
+args = [
+f'--cfg-file={cfg_file}'
+]
+return self.run_cmd(*args)
+
+def cmdline_capsule(self, image_index, image_guid, hardware_instance,
+payload, output
[PATCH v5 10/12] test: capsule: Remove public key embed logic from capsule update test
The embedding of the public key EFI Signature List(ESL) file into the
platform's DTB is now done at the time of u-boot build. Remove this
logic from the capsule update test' configuration.
Include the public key for the sandbox and sandbox_flattree variant
as part of the build.
Signed-off-by: Sughosh Ganu
---
Changes since V4: None
configs/sandbox_defconfig| 1 +
configs/sandbox_flattree_defconfig | 1 +
test/py/tests/test_efi_capsule/conftest.py | 37
test/py/tests/test_efi_capsule/signature.dts | 10 --
4 files changed, 9 insertions(+), 40 deletions(-)
delete mode 100644 test/py/tests/test_efi_capsule/signature.dts
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 19cc6701e6..53e342b3fa 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -342,6 +342,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/configs/sandbox_flattree_defconfig
b/configs/sandbox_flattree_defconfig
index 8aa295686d..06b1408b90 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -227,6 +227,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
CONFIG_UNIT_TEST=y
CONFIG_UT_TIME=y
CONFIG_UT_DM=y
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index 054be1ee97..99b502902e 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -25,48 +25,25 @@ def efi_capsule_data(request, u_boot_config):
image_path = u_boot_config.persistent_data_dir + '/test_efi_capsule.img'
try:
+capsules_path_dir = '/tmp/capsules/'
# Create a target device
check_call('dd if=/dev/zero of=./spi.bin bs=1MiB count=16', shell=True)
check_call('rm -rf %s' % mnt_point, shell=True)
check_call('mkdir -p %s' % data_dir, shell=True)
check_call('mkdir -p %s' % install_dir, shell=True)
-
-capsule_auth_enabled = u_boot_config.buildconfig.get(
-'config_efi_capsule_authenticate')
-if capsule_auth_enabled:
-# Create private key (SIGNER.key) and certificate (SIGNER.crt)
-check_call('cd %s; '
- 'openssl req -x509 -sha256 -newkey rsa:2048 '
-'-subj /CN=TEST_SIGNER/ -keyout SIGNER.key '
-'-out SIGNER.crt -nodes -days 365'
- % data_dir, shell=True)
-check_call('cd %s; %scert-to-efi-sig-list SIGNER.crt SIGNER.esl'
- % (data_dir, EFITOOLS_PATH), shell=True)
-
-# Update dtb adding capsule certificate
-check_call('cd %s; '
- 'cp %s/test/py/tests/test_efi_capsule/signature.dts .'
- % (data_dir, u_boot_config.source_dir), shell=True)
-check_call('cd %s; '
- 'dtc -@ -I dts -O dtb -o signature.dtbo signature.dts; '
- 'fdtoverlay -i %s/arch/sandbox/dts/test.dtb '
-'-o test_sig.dtb signature.dtbo'
- % (data_dir, u_boot_config.build_dir), shell=True)
-
-# Create *malicious* private key (SIGNER2.key) and certificate
-# (SIGNER2.crt)
-check_call('cd %s; '
- 'openssl req -x509 -sha256 -newkey rsa:2048 '
-'-subj /CN=TEST_SIGNER/ -keyout SIGNER2.key '
-'-out SIGNER2.crt -nodes -days 365'
- % data_dir, shell=True)
+check_call('cp %s/* %s ' % (capsules_path_dir, data_dir), shell=True)
# Update dtb to add the version information
check_call('cd %s; '
'cp %s/test/py/tests/test_efi_capsule/version.dts .'
% (data_dir, u_boot_config.source_dir), shell=True)
+
+capsule_auth_enabled = u_boot_config.buildconfig.get(
+'config_efi_capsule_authenticate')
if capsule_auth_enabled:
+check_call('cp %s/arch/sandbox/dts/test.dtb %s/test_sig.dtb' %
+ (u_boot_config.build_dir, data_dir), shell=True)
check_call('cd %s; '
'dtc -@ -I dts -O dtb -o version.dtbo version.dts; '
'fdtoverlay -i test_sig.dtb '
diff --git a/test/py/tests/test_efi_capsule/signature.dts
b/test/py/tests/test_efi_capsule/signature.dts
deleted file mode 100644
index 078cfc76c9..00
--- a/test/py/tests/test_efi_capsule/signature.dts
+++ /dev/null
@@ -1
[PATCH v5 11/12] sandbox: capsule: Add a config file for generating capsules
Support has been added to the mkeficapsule tool to generate capsules
by parsing the capsule parameters through a config file. Add a config
file for generating capsules. These capsules will be used for testing
the capsule update feature on sandbox platform.
Enable generation of capsules through the config file on the sandbox
variant.
Signed-off-by: Sughosh Ganu
---
Changes since V4:
* Use a relative path for CONFIG_EFI_CAPSULE_CFG_FILE.
* Remove logic to copy capsule config file to /tmp/capsules/
directory, as the capsule entry can handle relative paths.
* Add a comment in the capsule config file for the image GUIDs being
used.
* Use lower case for image GUIDs.
configs/sandbox_defconfig | 2 +
.../test_efi_capsule/sandbox_capsule_cfg.txt | 175 ++
2 files changed, 177 insertions(+)
create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 53e342b3fa..49ca6f5f61 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -343,6 +343,8 @@ CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
+CONFIG_EFI_CAPSULE_CFG_FILE="test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt"
+CONFIG_EFI_USE_CAPSULE_CFG_FILE=y
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
b/test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
new file mode 100644
index 00..bfce3bbb5f
--- /dev/null
+++ b/test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
@@ -0,0 +1,175 @@
+# This is a config file used for generating EFI capsules for the
+# sandbox platform. The image GUIDs used in this file are as
+# follows
+#
+# 09d7cf52-0720-4710-91d1-08469b7fe9c8 - u-boot image GUID
+#
+# 5a7021f5-fef2-48b4-aaba-832e777418c0 - u-boot env image GUID
+#
+# 3673b45d-6a7c-46f3-9e60-adabb03f7937 - FIT image GUID
+#
+# 058b7d83-50d5-4c47-a195-60d86ad341c4 - Incorrect GUID for the platform
+#
+
+{
+ image-index: 1
+ image-guid: 09d7cf52-0720-4710-91d1-08469b7fe9c8
+ payload: /tmp/capsules/u-boot.bin.new
+ capsule: /tmp/capsules/Test01
+}
+{
+ image-index: 2
+ image-guid: 5a7021f5-fef2-48b4-aaba-832e777418c0
+ payload: /tmp/capsules/u-boot.env.new
+ capsule: /tmp/capsules/Test02
+}
+{
+ image-index: 1
+ image-guid: 058b7d83-50d5-4c47-a195-60d86ad341c4
+ payload: /tmp/capsules/u-boot.bin.new
+ capsule: /tmp/capsules/Test03
+
+}
+{
+ image-index: 1
+ image-guid: 3673b45d-6a7c-46f3-9e60-adabb03f7937
+ payload: /tmp/capsules/uboot_bin_env.itb
+ capsule: /tmp/capsules/Test04
+
+}
+{
+ image-index: 1
+ image-guid: 058b7d83-50d5-4c47-a195-60d86ad341c4
+ payload: /tmp/capsules/uboot_bin_env.itb
+ capsule: /tmp/capsules/Test05
+
+}
+{
+ image-index: 1
+ image-guid: 058b7d83-50d5-4c47-a195-60d86ad341c4
+ payload: /tmp/capsules/uboot_bin_env.itb
+ capsule: /tmp/capsules/Test05
+}
+{
+ image-index: 1
+ monotonic-count: 1
+ private-key: /tmp/capsules/SIGNER.key
+ pub-key-cert: /tmp/capsules/SIGNER.crt
+ image-guid: 09d7cf52-0720-4710-91d1-08469b7fe9c8
+ payload: /tmp/capsules/u-boot.bin.new
+ capsule: /tmp/capsules/Test11
+}
+{
+ image-index: 1
+ monotonic-count: 1
+ private-key: /tmp/capsules/SIGNER2.key
+ pub-key-cert: /tmp/capsules/SIGNER2.crt
+ image-guid: 09d7cf52-0720-4710-91d1-08469b7fe9c8
+ payload: /tmp/capsules/u-boot.bin.new
+ capsule: /tmp/capsules/Test12
+}
+{
+ image-index: 1
+ monotonic-count: 1
+ private-key: /tmp/capsules/SIGNER.key
+ pub-key-cert: /tmp/capsules/SIGNER.crt
+ image-guid: 3673b45d-6a7c-46f3-9e60-adabb03f7937
+ payload: /tmp/capsules/uboot_bin_env.itb
+ capsule: /tmp/capsules/Test13
+}
+{
+ image-index: 1
+ monotonic-count: 1
+ private-key: /tmp/capsules/SIGNER2.key
+ pub-key-cert: /tmp/capsules/SIGNER2.crt
+ image-guid: 3673b45d-6a7c-46f3-9e60-adabb03f7937
+ payload: /tmp/capsules/uboot_bin_env.itb
+ capsule: /tmp/capsules/Test14
+}
+{
+ image-index: 1
+ fw-version: 5
+ image-guid: 09d7cf52-0720-4710-91d1-08469b7fe9c8
+ payload: /tmp/capsules/u-boot.bin.new
+ capsule: /tmp/capsules/Test101
+}
+{
+ image-index: 2
+ fw-version: 10
+ image-guid: 5a7021f5-fef2-48b4-aaba-832e777418c0
+ payload: /tmp/capsules/u-boot.env.new
+ capsule: /tmp/capsules/Test102
+}
+{
+ image-index: 1
+ fw-version: 2
+ image-guid: 09d7cf52-0720-4710-91d1-08469b7fe9c8
+ payload: /tmp/capsules/u-boot.bin.new
+ capsule: /tmp/capsules/Test103
+
+}
+{
+ image-index: 1
+ fw-version: 5
+ image
[PATCH v5 09/12] test: py: Setup capsule files for testing
Support has being added through earlier commits to build capsules and
embed the public key needed for capsule authentication as part of
u-boot build.
>From the testing point-of-view, this means the input files needed for
the above have to be setup before invoking the build. Set this up in
the pytest configuration file for testing the capsule update feature.
Signed-off-by: Sughosh Ganu
Reviewed-by: Simon Glass
---
Changes since V4: None
test/py/conftest.py | 84 +
1 file changed, 84 insertions(+)
diff --git a/test/py/conftest.py b/test/py/conftest.py
index fc9dd3a83f..1092cb713b 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -80,6 +80,86 @@ def pytest_addoption(parser):
help='Run sandbox under gdbserver. The argument is the channel '+
'over which gdbserver should communicate, e.g. localhost:1234')
+def setup_capsule_build(source_dir, build_dir, board_type, log):
+"""Setup the platform's build for testing capsule updates
+
+This generates the payload/input files needed for testing the
+capsule update functionality, along with the keys for signing
+the capsules. An EFI Signature List(ESL) file, which houses the
+public key for capsule authentication is generated as
+well.
+
+The ESL file is subsequently embedded into the platform's
+dtb during the u-boot build, to be used for capsule
+authentication.
+
+Two sets of keys are generated, namely SIGNER and SIGNER2.
+The SIGNER2 key pair is used as a malicious key for testing the
+the capsule authentication functionality.
+
+All the generated files are placed under the /tmp/capsules/
+directory.
+
+Args:
+soruce_dir (str): Directory containing source code
+build_dir (str): Directory to build in
+board_type (str): board_type parameter (e.g. 'sandbox')
+log (Logfile): Log file to use
+
+Returns:
+Nothing.
+"""
+def run_command(name, cmd, source_dir):
+with log.section(name):
+if isinstance(cmd, str):
+cmd = cmd.split()
+runner = log.get_runner(name, None)
+runner.run(cmd, cwd=source_dir)
+runner.close()
+log.status_pass('OK')
+
+def gen_capsule_payloads(capsule_dir):
+fname = f'{capsule_dir}u-boot.bin.old'
+with open(fname, 'w') as fd:
+fd.write('u-boot:Old')
+
+fname = f'{capsule_dir}u-boot.bin.new'
+with open(fname, 'w') as fd:
+fd.write('u-boot:New')
+
+fname = f'{capsule_dir}u-boot.env.old'
+with open(fname, 'w') as fd:
+fd.write('u-boot-env:Old')
+
+fname = f'{capsule_dir}u-boot.env.new'
+with open(fname, 'w') as fd:
+fd.write('u-boot-env:New')
+
+capsule_sig_dir = '/tmp/capsules/'
+sig_name = 'SIGNER'
+mkdir_p(capsule_sig_dir)
+name = 'openssl'
+cmd = ( 'openssl req -x509 -sha256 -newkey rsa:2048 '
+'-subj /CN=TEST_SIGNER/ -keyout '
+f'{capsule_sig_dir}{sig_name}.key '
+f'-out {capsule_sig_dir}{sig_name}.crt -nodes -days 365' )
+run_command(name, cmd, source_dir)
+
+name = 'cert-to-efi-sig-list'
+cmd = ( f'cert-to-efi-sig-list {capsule_sig_dir}{sig_name}.crt '
+f'{capsule_sig_dir}{sig_name}.esl' )
+run_command(name, cmd, source_dir)
+
+sig_name = 'SIGNER2'
+name = 'openssl'
+cmd = ( 'openssl req -x509 -sha256 -newkey rsa:2048 '
+'-subj /CN=TEST_SIGNER/ -keyout '
+f'{capsule_sig_dir}{sig_name}.key '
+f'-out {capsule_sig_dir}{sig_name}.crt -nodes -days 365' )
+run_command(name, cmd, source_dir)
+
+gen_capsule_payloads(capsule_sig_dir)
+
def run_build(config, source_dir, build_dir, board_type, log):
"""run_build: Build U-Boot
@@ -90,6 +170,10 @@ def run_build(config, source_dir, build_dir, board_type,
log):
board_type (str): board_type parameter (e.g. 'sandbox')
log (Logfile): Log file to use
"""
+capsule_boards = ( 'sandbox', 'sandbox64', 'sandbox_flattree' )
+if board_type in capsule_boards:
+setup_capsule_build(source_dir, build_dir, board_type, log)
+
if config.getoption('buildman'):
if build_dir != source_dir:
dest_args = ['-o', build_dir, '-w']
--
2.34.1
[PATCH v5 05/12] tools: mkeficapsule: Add support for parsing capsule params from config file
Add support for specifying the parameters needed for capsule
generation through a config file, instead of passing them through
command-line. Parameters for more than a single capsule file can be
specified, resulting in generation of multiple capsules through a
single invocation of the command.
This path is to be used for generating capsules through a make target,
with the parameters being parsed from the config file.
Signed-off-by: Sughosh Ganu
---
Changes since V4: None
tools/Kconfig | 16 ++
tools/Makefile | 1 +
tools/eficapsule.h | 115
tools/mkeficapsule.c | 87 +
tools/mkeficapsule_parse.c | 352 +
5 files changed, 540 insertions(+), 31 deletions(-)
create mode 100644 tools/mkeficapsule_parse.c
diff --git a/tools/Kconfig b/tools/Kconfig
index 6e23f44d55..88ea3567d0 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -98,6 +98,22 @@ config TOOLS_MKEFICAPSULE
optionally sign that file. If you want to enable UEFI capsule
update feature on your target, you certainly need this.
+config EFI_CAPSULE_CFG_FILE
+ string "Path to the EFI Capsule Config File"
+ default ""
+ help
+ Path to the EFI capsule config file which provides the
+ parameters needed to build capsule(s). Parameters can be
+ provided for multiple payloads resulting in corresponding
+ capsule images being generated.
+
+config EFI_USE_CAPSULE_CFG_FILE
+ bool "Use the config file for generating capsules"
+ help
+ Boolean option used to specify if the EFI capsules are to
+ be generated through parameters specified via the config
+ file or through command line.
+
menuconfig FSPI_CONF_HEADER
bool "FlexSPI Header Configuration"
help
diff --git a/tools/Makefile b/tools/Makefile
index 3d0c4b0dd6..eb129e3bb2 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
HOSTLDLIBS_mkeficapsule += \
$(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
+mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
mkfwumdata-objs := mkfwumdata.o generated/lib/crc32.o
HOSTLDLIBS_mkfwumdata += -luuid
diff --git a/tools/eficapsule.h b/tools/eficapsule.h
index 2099a2e9b8..d455ac1d6f 100644
--- a/tools/eficapsule.h
+++ b/tools/eficapsule.h
@@ -52,6 +52,12 @@ typedef struct {
/* flags */
#define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
+enum capsule_type {
+ CAPSULE_NORMAL_BLOB = 0,
+ CAPSULE_ACCEPT,
+ CAPSULE_REVERT,
+};
+
struct efi_capsule_header {
efi_guid_t capsule_guid;
uint32_t header_size;
@@ -113,6 +119,7 @@ struct efi_firmware_image_authentication {
struct win_certificate_uefi_guid auth_info;
} __packed;
+
/* fmp payload header */
#define SIGNATURE_16(A, B) ((A) | ((B) << 8))
#define SIGNATURE_32(A, B, C, D) \
@@ -143,4 +150,112 @@ struct fmp_payload_header_params {
uint32_t fw_version;
};
+/**
+ * struct efi_capsule_params - Capsule parameters
+ * @image_guid: Guid value of the payload input image
+ * @image_index: Image index value
+ * @hardware_instance: Hardware instance to be used for the image
+ * @fmp: FMP payload header used for storing firmware version
+ * @monotonic_count: Monotonic count value to be used for signed capsule
+ * @privkey_file: Path to private key used in capsule signing
+ * @cert_file: Path to public key certificate used in capsule signing
+ * @input_file: Path to payload input image
+ * @capsule_file: Path to the output capsule file
+ * @oemflags: Oemflags to be populated in the capsule header
+ * @capsule: Capsule Type, normal or accept or revert
+ */
+struct efi_capsule_params {
+ efi_guid_t *image_guid;
+ unsigned long image_index;
+ unsigned long hardware_instance;
+ struct fmp_payload_header_params fmp;
+ uint64_t monotonic_count;
+ char *privkey_file;
+ char *cert_file;
+ char *input_file;
+ char *capsule_file;
+ unsigned long oemflags;
+ enum capsule_type capsule;
+};
+
+/**
+ * capsule_with_cfg_file() - Generate capsule from config file
+ * @cfg_file: Path to the config file
+ *
+ * Parse the capsule parameters from the config file and use the
+ * parameters for generating one or more capsules.
+ *
+ * Return: None
+ *
+ */
+void capsule_with_cfg_file(const char *cfg_file);
+
+/**
+ * convert_uuid_to_guid() - convert UUID to GUID
+ * @buf: UUID binary
+ *
+ * UUID and GUID have the same data structure, but their binary
+ * formats are different due to the endianness. See lib/uuid.c.
+ * Since uuid_parse() can handle only UUID, this function must
+ * be called to get correct data for GUID when parsing a string.
+ *
+ * The correct data will be returned
[PATCH v5 08/12] doc: Add documentation to highlight capsule generation related updates
The UEFI capsule can now be generate by specifying the capsule
parameters through a config file. Additionally, the capsules can be
generated as part of u-boot build, through binman. Highlight these
changes in the documentation.
Signed-off-by: Sughosh Ganu
---
Changes since V4: None
doc/develop/uefi/uefi.rst | 84 +++
1 file changed, 84 insertions(+)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index b2854b52a6..29955d943e 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -318,6 +318,79 @@ Run the following command
--guid \
+Alternatively, the capsules can be generated through a config
+file. When generating the capsules through a config file, the Kconfig
+symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the
+path to the config file.
+
+The config file describes the parameters that are used for generating
+one or more capsules. The parameters for a given capsule file are
+specified within curly braces, in the form of "key:value" pairs. All
+the parameters that are currently supported by the mkeficapsule tool
+can be specified through the config file.
+
+The following are some example payload parameters specified through
+the config file.
+
+.. code-block:: none
+
+ {
+ image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
+ hardware-instance: 0
+ monotonic-count: 1
+ payload: u-boot.bin
+ image-index: 1
+ fw-version: 2
+ private-key: /path/to/priv/key
+ pub-key-cert: /path/to/pub/key
+ capsule: u-boot.capsule
+ }
+ {
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ hardware-instance: 0
+ payload: u-boot.itb
+ image-index: 2
+ fw-version: 7
+ oemflags: 0x8000
+ capsule: fit.capsule
+ }
+ {
+ capsule-type: accept
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ capsule: accept.capsule
+ }
+ {
+ capsule-type: revert
+ capsule: revert.capsule
+ }
+
+The following are the keys that specify the capsule parameters
+
+..code-block:: none
+
+image-guid: Image GUID
+image-index: Image index value
+fw-version: Image version
+private-key: Path to the private key file used for capsule signing
+pub-key-cert: Path to the public key crt file used for capsule signing
+payload: Path to the capsule payload file
+capsule: Path to the output capsule file that is generated
+hardware-instance: Hardware Instance value
+monotonic-count: Monotonic count value
+capsule-type: Specifies capsule type. normal(default), accept or revert
+oemflags: 16bit Oemflags value to be used(populated in capsule header)
+
+When generating capsules through a config file, the command would look
+like
+
+.. code-block:: console
+
+$ mkeficapsule --cfg-file
+
+
+Capsule with firmware version
+*
+
The UEFI specification does not define the firmware versioning mechanism.
EDK II reference implementation inserts the FMP Payload Header right before
the payload. It coutains the fw_version and lowest supported version,
@@ -345,6 +418,17 @@ add --fw-version option in mkeficapsule tool.
If the --fw-version option is not set, FMP Payload Header is not inserted
and fw_version is set as 0.
+
+Capsule Generation through binman
+*
+
+Support has also been added to generate capsules during u-boot build
+through binman. This requires the platform's DTB to be populated with
+the capsule entry nodes for binman. The capsules then can be generated
+by specifying the capsule parameters either through a config file, or
+by specifying them as properties in the capsule entry node.
+
+
Performing the update
*
--
2.34.1
[PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing
Support has being added through earlier commits to build capsules and embed the public key needed for capsule authentication as part of u-boot build. >From the testing point-of-view, this means the input files needed for generating the above have to be setup before invoking the build. Set this up in the CI configuration docker file for testing the capsule update feature. Signed-off-by: Sughosh Ganu --- Changes since V4: * New patch which moves the setting up of the files needed for testing the EFI capsule update feature to the Dockerfile. Note: Earlier, this setup was being done in the azure and gitlab yaml files. Now that this has been moved to the Dockerfile, this will require generating a new container image and referencing that image in the yaml files for the CI to work when these patches get applied. tools/docker/Dockerfile | 12 1 file changed, 12 insertions(+) diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index 3d2b64a355..294a0b0a53 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -206,6 +206,18 @@ RUN mkdir -p /opt/nokia && \ cp /tmp/qemu-linaro/arm-softmmu/qemu-system-arm /opt/nokia && \ rm -rf /tmp/qemu-linaro +# Set up capsule files for UEFI capsule update testing +RUN mkdir -p /tmp/capsules && \ +cd /tmp/capsules/ && \ +echo -n "u-boot:Old" > u-boot.bin.old && \ +echo -n "u-boot:New" > u-boot.bin.new && \ +echo -n "u-boot-env:Old" > u-boot.env.old && \ +echo -n "u-boot-env:New" > u-boot.env.new && \ +openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/ -keyout SIGNER.key -out SIGNER.crt -nodes -days 365 && \ +openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/ -keyout SIGNER2.key -out SIGNER2.crt -nodes -days 365 && \ +cert-to-efi-sig-list SIGNER.crt SIGNER.esl && \ +chmod -R uog+rw /tmp/capsules/ + # Build genimage (required by some targets to generate disk images) RUN wget -O - https://github.com/pengutronix/genimage/releases/download/v14/genimage-14.tar.xz | tar -C /tmp -xJ && \ cd /tmp/genimage-14 && \ -- 2.34.1
[PATCH v5 01/12] binman: bintool: Build a tool from a list of commands
Add support to build a tool from source with a list of commands. This
is useful when a tool can be built with multiple commands instead of a
single command.
Signed-off-by: Sughosh Ganu
---
Changes since V4:
* Pass the single command target names directly to the function
instead of putting them in a separate list.
tools/binman/bintool.py | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
index 0b0f56dbbb..3c4ad1adbb 100644
--- a/tools/binman/bintool.py
+++ b/tools/binman/bintool.py
@@ -328,7 +328,7 @@ class Bintool:
return result.stdout
@classmethod
-def build_from_git(cls, git_repo, make_target, bintool_path, flags=None):
+def build_from_git(cls, git_repo, make_targets, bintool_path, flags=None):
"""Build a bintool from a git repo
This clones the repo in a temporary directory, builds it with 'make',
@@ -336,7 +336,8 @@ class Bintool:
Args:
git_repo (str): URL of git repo
-make_target (str): Target to pass to 'make' to build the tool
+make_targets (list of str): List of targets to pass to 'make' to
build
+the tool
bintool_path (str): Relative path of the tool in the repo, after
build is complete
flags (list of str): Flags or variables to pass to make, or None
@@ -350,12 +351,14 @@ class Bintool:
tmpdir = tempfile.mkdtemp(prefix='binmanf.')
print(f"- clone git repo '{git_repo}' to '{tmpdir}'")
tools.run('git', 'clone', '--depth', '1', git_repo, tmpdir)
-print(f"- build target '{make_target}'")
-cmd = ['make', '-C', tmpdir, '-j', f'{multiprocessing.cpu_count()}',
- make_target]
-if flags:
-cmd += flags
-tools.run(*cmd)
+for target in make_targets:
+print(f"- build target '{target}'")
+cmd = ['make', '-C', tmpdir, '-j',
f'{multiprocessing.cpu_count()}',
+ target]
+if flags:
+cmd += flags
+tools.run(*cmd)
+
fname = os.path.join(tmpdir, bintool_path)
if not os.path.exists(fname):
print(f"- File '{fname}' was not produced")
--
2.34.1
[PATCH v5 00/12] Integrate EFI capsule tasks into u-boot's build flow
This patchset aims to bring two capsule related tasks under the u-boot build flow. One is the embedding of the public key into the platform's dtb. The public key is in the form of an EFI Signature List(ESL) file and is used for capsule authentication. This is being achieved by adding the signature node containing the capsule public key in the architecture's u-boot.dtsi file. Currently, the u-boot.dtsi file has been added for the sandbox and arm architectures. The path to the ESL file is being provided through a Kconfig symbol(CONFIG_EFI_CAPSULE_ESL_FILE). Changes have also been made to the test flow so that the keys used for signing the capsule, and the ESL file, are generated prior to invoking the u-boot's build, which enables embedding the ESL file into the dtb as part of the u-boot build. The other task is related to generation of capsules. Support is being added to generate capsules by specifying the capsule parameters in a config file. Calling the mkeficapsule tool then results in generation of the corresponding capsule files. The capsules can be generated as part of u-boot build, and this is being achieved through binman, by adding a capsule entry type. The capsules can be generated either by specifying the capsule parameters in a config file, or through specifying them as properties under the capsule entry node. If using the config file, the path to the config file is to be specified through a Kconfig symbol(CONFIG_EFI_CAPSULE_CFG_FILE). Changes have also been made to the efi capsule update feature testing setup on the sandbox variants. Currently, the capsule files and the public key ESL file are generated after u-boot has been built. This logic has been changed so that the capsule input files along with the keys needed for capsule signing and authentication are generated prior to initiation of the u-boot build. The placement of all the files needed for generation of capsules, along with the generated capsule files is under the /tmp/capsules/ directory. Currently, the capsule update feature is tested on the sandbox and sandbox_flattree variants in CI. The capsule generation through config file is enabled for the sandbox variant, with the sandbox_flattree variant generating capsules through the command-line parameters. The document has been updated to reflect the above changes. Changes since V4: * Rebase on top of current HEAD. * Pass the single command target names directly to the function instead of putting them in a separate list. * Fix multi line comment format. * Drop additional blank line. * Remove the check for CONFIG_EFI_HAVE_CAPSULE_SUPPORT from arm's u-boot.dtsi. * Wrap the help text in the EFI_CAPSULE_ESL_FILE config at 72 chars. * New patch which moves the setting up of the files needed for testing the EFI capsule update feature to the Dockerfile. * Remove blank lines after function comments. * Fix a couple of typos. * Use single quotes for strings. * Put the GUIDs in variables with relevant names. * Declare certain values in local variables instead of member values. * Add comments for explaning the payload offsets in the capsule file. * Drop the test case for generating the capsule from the config file. * Define payload data for the capsule tests. * Add logic to find input and output files in capsule generation in the indir and outdir directories when absolute path is not passed. * Use a relative path for CONFIG_EFI_CAPSULE_CFG_FILE. * Remove logic to copy capsule config file to /tmp/capsules/ directory, as the capsule entry can handle relative paths. * Add a comment in the capsule config file for the image GUIDs being used. * Use lower case for image GUIDs. * Define macros for the image GUIDs being used for generating the capsules. * Use lower case for image GUIDs. Sughosh Ganu (12): binman: bintool: Build a tool from a list of commands nuvoton: npcm845-evb: Add a newline at the end of file capsule: authenticate: Add capsule public key in platform's dtb doc: capsule: Document the new mechanism to embed ESL file into dtb tools: mkeficapsule: Add support for parsing capsule params from config file Dockerfile: capsule: Setup the files needed for capsule update testing binman: capsule: Add support for generating capsules doc: Add documentation to highlight capsule generation related updates test: py: Setup capsule files for testing test: capsule: Remove public key embed logic from capsule update test sandbox: capsule: Add a config file for generating capsules sandbox: capsule: Generate capsule related files through binman arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +- arch/arm/dts/u-boot.dtsi | 14 + arch/sandbox/dts/u-boot.dtsi | 288 ++ configs/sandbox_defconfig | 3 + configs/sandbox_flattree_defconfig| 1 + configs/sandbox_spl_defconfig | 1 + doc/develop/uefi/uefi.rst | 106 +- lib/efi_loader
[PATCH v5 04/12] doc: capsule: Document the new mechanism to embed ESL file into dtb
Update the document to specify how the EFI Signature List(ESL) file
can be embedded into the platform's dtb as part of the u-boot build.
Signed-off-by: Sughosh Ganu
Reviewed-by: Simon Glass
---
Changes since V4: None
doc/develop/uefi/uefi.rst | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index a7a41f2fac..b2854b52a6 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -522,20 +522,16 @@ and used by the steps highlighted below.
...
}
-You can do step-4 manually with
+You can perform step-4 by defining the Kconfig symbol
+CONFIG_EFI_CAPSULE_ESL_FILE. Once this has been done, the signature
+node can be added to the u-boot.dtsi file. For reference, check the
+u-boot.dtsi file for the sandbox architecture. If this node has not
+been added to the architecture's u-boot.dtsi file, this needs to be
+done. The node has currently been added for the sandbox and arm
+architectures' in the u-boot.dtsi file. Once the u-boot.dtsi file has
+been added with the signature node, the esl file will automatically
+get embedded into the platform's dtb as part of u-boot build.
-.. code-block:: console
-
-$ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
-$ fdtoverlay -i orig.dtb -o new.dtb -v signature.dtbo
-
-where signature.dts looks like::
-
-&{/} {
-signature {
-capsule-key = /incbin/("CRT.esl");
-};
-};
Anti-rollback Protection
--
2.34.1
[PATCH v5 03/12] capsule: authenticate: Add capsule public key in platform's dtb
The EFI capsule authentication logic in u-boot expects the public key
in the form of an EFI Signature List(ESL) to be provided as part of
the platform's dtb. Currently, the embedding of the ESL file into the
dtb needs to be done manually.
Add a signature node in the u-boot dtsi file and include the public
key through the capsule-key property. This file is per architecture,
and is currently being added for sandbox and arm architectures. It
will have to be added for other architectures which need to enable
capsule authentication support.
The path to the ESL file is specified through the
CONFIG_EFI_CAPSULE_ESL_FILE symbol.
Signed-off-by: Sughosh Ganu
---
Changes since V4:
* Fix multi line comment format.
* Drop additional blank line.
* Remove the check for CONFIG_EFI_HAVE_CAPSULE_SUPPORT from arm's
u-boot.dtsi.
* Wrap the help text in the EFI_CAPSULE_ESL_FILE config at 72 chars.
arch/arm/dts/u-boot.dtsi | 14 ++
arch/sandbox/dts/u-boot.dtsi | 17 +
lib/efi_loader/Kconfig | 9 +
lib/efi_loader/Makefile | 7 +++
4 files changed, 47 insertions(+)
create mode 100644 arch/arm/dts/u-boot.dtsi
create mode 100644 arch/sandbox/dts/u-boot.dtsi
diff --git a/arch/arm/dts/u-boot.dtsi b/arch/arm/dts/u-boot.dtsi
new file mode 100644
index 00..4f31da4521
--- /dev/null
+++ b/arch/arm/dts/u-boot.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * Devicetree file with miscellaneous nodes that will be included
+ * at build time into the DTB. Currently being used for including
+ * capsule related information.
+ */
+
+#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
+/ {
+ signature {
+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
+ };
+};
+#endif /* CONFIG_EFI_CAPSULE_AUTHENTICATE */
diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
new file mode 100644
index 00..60bd004937
--- /dev/null
+++ b/arch/sandbox/dts/u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Devicetree file with miscellaneous nodes that will be included
+ * at build time into the DTB. Currently being used for including
+ * capsule related information.
+ *
+ */
+
+#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
+/ {
+#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
+ signature {
+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
+ };
+#endif
+};
+#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index a22e47616f..0d559ff3a1 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -235,6 +235,15 @@ config EFI_CAPSULE_MAX
Select the max capsule index value used for capsule report
variables. This value is used to create CapsuleMax variable.
+config EFI_CAPSULE_ESL_FILE
+ string "Path to the EFI Signature List File"
+ default ""
+ depends on EFI_CAPSULE_AUTHENTICATE
+ help
+ Provides the absolute path to the EFI Signature List file which
+ will be embedded in the platform's device tree and used for
+ capsule authentication at the time of capsule update.
+
config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 1a8c8d7cab..c52c9d27bd 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -89,3 +89,10 @@ obj-$(CONFIG_EFI_ECPT) += efi_conformance.o
EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
$(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
+
+ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
+EFI_CAPSULE_KEY_PATH := $(subst $\",,$(CONFIG_EFI_CAPSULE_ESL_FILE))
+ifeq ("$(wildcard $(EFI_CAPSULE_KEY_PATH))","")
+$(error .esl cerificate not found. Configure your CONFIG_EFI_CAPSULE_ESL_FILE)
+endif
+endif
--
2.34.1
[PATCH v5 02/12] nuvoton: npcm845-evb: Add a newline at the end of file
Add a newline at the end of the dts, without which the build fails when including the u-boot.dtsi file. Signed-off-by: Sughosh Ganu Reviewed-by: Simon Glass --- Changes since V4: None arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/nuvoton-npcm845-evb.dts b/arch/arm/dts/nuvoton-npcm845-evb.dts index 3cab7807e3..a93666cb41 100644 --- a/arch/arm/dts/nuvoton-npcm845-evb.dts +++ b/arch/arm/dts/nuvoton-npcm845-evb.dts @@ -354,4 +354,4 @@ _pins _pins >; -}; \ No newline at end of file +}; -- 2.34.1
Re: [PATCH] efi_loader: Allow also empty capsule to be process
On Thu, 20 Jul 2023 at 14:56, Michal Simek wrote: > > > > On 7/20/23 10:45, Sughosh Ganu wrote: > > On Thu, 20 Jul 2023 at 13:26, Michal Simek wrote: > >> > >> > >> > >> On 7/20/23 08:36, Sughosh Ganu wrote: > >>> On Thu, 20 Jul 2023 at 11:37, Michal Simek wrote: > >>>> > >>>> Hi, > >>>> > >>>> On 7/20/23 07:49, AKASHI Takahiro wrote: > >>>>> Hi, > >>>>> > >>>>> On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote: > >>>>>> > >>>>>> > >>>>>> On 7/18/23 17:41, Heinrich Schuchardt wrote: > >>>>>>> On 13.07.23 16:35, Michal Simek wrote: > >>>>>>>> Empty capsule are also allowed to be process. Without it updated > >>>>>>>> images > >>>>>>>> can't change their Image Acceptance state from no to yes. > >>>>>>> > >>>>>>> Is there any documentation describing the usage of empty capsule to > >>>>>>> set > >>>>>>> the image acceptance state? > >>>>>> > >>>>>> I actually don't know about documentation. I was talking to Ilias to > >>>>>> make > >>>>>> sure that documentation is up2date because there are missing couple of > >>>>>> things there. > >>>>> > >>>>> Sughosh should have more to say here about A/B update. > >>>>> > >>>>>> I am testing A/B update and if you setup oemflags to 0x8000 then > >>>>>> capsules > >>>>>> are not automatically accepted and waiting for acceptance capsule to be > >>>>>> passed. > >>>>>> When I tested it I found out that they are not process that's why I > >>>>>> created > >>>>>> this patch. > >>>>> > >>>>> The path you tried to modify is only executed by "efidebug capsule > >>>>> update" > >>>>> or more specifically via the runtime service, UPDATE_CAPSULE. > >>>>> > >>>>> But this API is NOT officially supported in the current capsule > >>>>> implementation > >>>>> (at least, in my initial intention). > >>>>> The only way to invoke capsule updates is to reboot the system. > >>>>> If you want to test A/B update, please do the reboot. > >>>> > >>>> I realized that to get full flow you need to use capsule update on disk > >>>> to get > >>>> all functionalities. But it is very impractical. Actually I would expect > >>>> via > >>>> efidebug you should be able to perform all steps as capsule update > >>>> performs when > >>>> you do reboot. > >>>> I would also understand that via efidebug you are not able to apply any > >>>> capsule > >>>> but I don't think it is right that you can apply just update capsules > >>>> but not > >>>> empty capsules. I would understand none or all but not something in the > >>>> middle. > >>> > >>> The A/B update functionality requires using the capsule-on-disk > >>> functionality for performing the updates. This is also mentioned in > >>> the fwu_updates.rst document. You should be able to apply empty > >>> capsules even with the 'efidebug disk-update' command. > >> > >> Yes this is working fine. > >> > >> ZynqMP> efidebug capsule disk-update > >> # > >> Applying capsule capsule1.bin succeeded. > >> # > >> Applying capsule capsule2.bin succeeded. > >> Reboot after firmware update. > >> > >> I tested it also with empty capsules which are also process properly. > >> > >>> I have never > >>> used the 'efidebug capsule update' command, so I'm not sure if that is > >>> supported. Like Takahiro mentioned, if you place the capsules(genuine > >>> or empty) under the /EFI/UpdateCapsule/ directory, the update should > >>> happen automatically, since the fwu update feature also enables the > >>> EFI_CAPSULE_ON_DISK_EARLY config. > >> > >> Yes that's work fine on production systems. > >> But from my point of view there shouldn't be really a problem to also apply > >> empty capsule via efidebug capsule update to be able to see that steps and > >> changes in mdata structure without performing reset. > > > > The 'efidebug capsule update' command calls the efi_update_capsule > > function, which implements the UpdateCapsule runtime service call. The > > initial versions of my fwu patches were indeed adding support for this > > path, but one of the review comments was to restrict support only for > > the capsule-on-disk path when performing the update in u-boot, since > > we are not using the runtime call in u-boot. > > I don't think this is a valid argument. As I said I would understand if there > is > no interface for any capsule. It means having support for both or none is IMHO > the way we should support. > Can you please point me to that discussion? There is mention of the point in this discussion [1]. Even this thread has Takahiro mention the point he is making above, that maybe there shouldn't be the efi_update_capsule function. -sughosh [1] - https://lists.denx.de/pipermail/u-boot/2022-February/473891.html
Re: [PATCH v4 06/12] binman: capsule: Add support for generating capsules
hi Simon, On Thu, 20 Jul 2023 at 00:41, Simon Glass wrote: > > Hi Sughosh, > > On Wed, 19 Jul 2023 at 02:42, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Wed, 19 Jul 2023 at 06:41, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Mon, 17 Jul 2023 at 04:44, Sughosh Ganu > > > wrote: > > > > > > > > hi Simon, > > > > > > > > On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote: > > > > > > > > > > Hi Sughosh, > > > > > > > > > > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > Add support in binman for generating capsules. The capsule > > > > > > parameters > > > > > > can be specified either through a config file or through the capsule > > > > > > binman entry. Also add test cases in binman for capsule generation, > > > > > > and enable this testing on the sandbox_spl variant. > > > > > > > > > > Can you use sandbox instead, or perhaps sandbox_spl? SPL is really for > > > > > SPL testing. > > > > > > > > Er, I am actually using the sandbox_spl variant. > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > --- > > > > > > Changes since V3: > > > > > > * Add test cases for covering the various capsule generation > > > > > > scenarios. > > > > > > * Add function comments in the mkeficapsule bintool. > > > > > > * Fix the fetch method of the mkeficapsule bintool to enable > > > > > > building > > > > > > the tool. > > > > > > * Add more details about the capsule parameters in the documentation > > > > > > as well as the code. > > > > > > * Fix order of module imports, and addition of blank lines in the > > > > > > capsule.py file. > > > > > > * Use SetContents in the ObtainContents method. > > > > > > > > > > > > configs/sandbox_spl_defconfig | 1 + > > > > > > tools/binman/btool/mkeficapsule.py| 158 > > > > > > ++ > > > > > > tools/binman/entries.rst | 37 > > > > > > tools/binman/etype/capsule.py | 132 +++ > > > > > > tools/binman/ftest.py | 127 ++ > > > > > > tools/binman/test/282_capsule.dts | 18 ++ > > > > > > tools/binman/test/283_capsule_signed.dts | 20 +++ > > > > > > tools/binman/test/284_capsule_conf.dts| 14 ++ > > > > > > tools/binman/test/285_capsule_missing_key.dts | 19 +++ > > > > > > .../binman/test/286_capsule_missing_index.dts | 17 ++ > > > > > > .../binman/test/287_capsule_missing_guid.dts | 17 ++ > > > > > > .../test/288_capsule_missing_payload.dts | 17 ++ > > > > > > tools/binman/test/289_capsule_missing.dts | 17 ++ > > > > > > tools/binman/test/290_capsule_version.dts | 19 +++ > > > > > > tools/binman/test/capsule_cfg.txt | 6 + > > > > > > 15 files changed, 619 insertions(+) > > > > > > create mode 100644 tools/binman/btool/mkeficapsule.py > > > > > > create mode 100644 tools/binman/etype/capsule.py > > > > > > create mode 100644 tools/binman/test/282_capsule.dts > > > > > > create mode 100644 tools/binman/test/283_capsule_signed.dts > > > > > > create mode 100644 tools/binman/test/284_capsule_conf.dts > > > > > > create mode 100644 tools/binman/test/285_capsule_missing_key.dts > > > > > > create mode 100644 tools/binman/test/286_capsule_missing_index.dts > > > > > > create mode 100644 tools/binman/test/287_capsule_missing_guid.dts > > > > > > create mode 100644 > > > > > > tools/binman/test/288_capsule_missing_payload.dts > > > > > > create mode 100644 tools/binman/test/289_capsule_missing.dts > > > > > > create mode 100644 tools/binman/test/290_capsule_version.dts > > > > > > create mode 100644 tools/binman/test/capsule_cfg.txt > > > > > >
Re: [PATCH] efi_loader: Allow also empty capsule to be process
On Thu, 20 Jul 2023 at 13:26, Michal Simek wrote: > > > > On 7/20/23 08:36, Sughosh Ganu wrote: > > On Thu, 20 Jul 2023 at 11:37, Michal Simek wrote: > >> > >> Hi, > >> > >> On 7/20/23 07:49, AKASHI Takahiro wrote: > >>> Hi, > >>> > >>> On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote: > >>>> > >>>> > >>>> On 7/18/23 17:41, Heinrich Schuchardt wrote: > >>>>> On 13.07.23 16:35, Michal Simek wrote: > >>>>>> Empty capsule are also allowed to be process. Without it updated images > >>>>>> can't change their Image Acceptance state from no to yes. > >>>>> > >>>>> Is there any documentation describing the usage of empty capsule to set > >>>>> the image acceptance state? > >>>> > >>>> I actually don't know about documentation. I was talking to Ilias to make > >>>> sure that documentation is up2date because there are missing couple of > >>>> things there. > >>> > >>> Sughosh should have more to say here about A/B update. > >>> > >>>> I am testing A/B update and if you setup oemflags to 0x8000 then capsules > >>>> are not automatically accepted and waiting for acceptance capsule to be > >>>> passed. > >>>> When I tested it I found out that they are not process that's why I > >>>> created > >>>> this patch. > >>> > >>> The path you tried to modify is only executed by "efidebug capsule update" > >>> or more specifically via the runtime service, UPDATE_CAPSULE. > >>> > >>> But this API is NOT officially supported in the current capsule > >>> implementation > >>> (at least, in my initial intention). > >>> The only way to invoke capsule updates is to reboot the system. > >>> If you want to test A/B update, please do the reboot. > >> > >> I realized that to get full flow you need to use capsule update on disk to > >> get > >> all functionalities. But it is very impractical. Actually I would expect > >> via > >> efidebug you should be able to perform all steps as capsule update > >> performs when > >> you do reboot. > >> I would also understand that via efidebug you are not able to apply any > >> capsule > >> but I don't think it is right that you can apply just update capsules but > >> not > >> empty capsules. I would understand none or all but not something in the > >> middle. > > > > The A/B update functionality requires using the capsule-on-disk > > functionality for performing the updates. This is also mentioned in > > the fwu_updates.rst document. You should be able to apply empty > > capsules even with the 'efidebug disk-update' command. > > Yes this is working fine. > > ZynqMP> efidebug capsule disk-update > # > Applying capsule capsule1.bin succeeded. > # > Applying capsule capsule2.bin succeeded. > Reboot after firmware update. > > I tested it also with empty capsules which are also process properly. > > > I have never > > used the 'efidebug capsule update' command, so I'm not sure if that is > > supported. Like Takahiro mentioned, if you place the capsules(genuine > > or empty) under the /EFI/UpdateCapsule/ directory, the update should > > happen automatically, since the fwu update feature also enables the > > EFI_CAPSULE_ON_DISK_EARLY config. > > Yes that's work fine on production systems. > But from my point of view there shouldn't be really a problem to also apply > empty capsule via efidebug capsule update to be able to see that steps and > changes in mdata structure without performing reset. The 'efidebug capsule update' command calls the efi_update_capsule function, which implements the UpdateCapsule runtime service call. The initial versions of my fwu patches were indeed adding support for this path, but one of the review comments was to restrict support only for the capsule-on-disk path when performing the update in u-boot, since we are not using the runtime call in u-boot. -sughosh > > Again I have no issue with code which is using capsule-on-disk feature but I > think that pretty much all these steps which are done automatically should be > possible to do through steps to see them. That's what you can do with bootm > start and simply stepping through it. > > I am testing 2 images per bank and I can simply load other partition by simple > comm
Re: [PATCH] efi_loader: Allow also empty capsule to be process
On Thu, 20 Jul 2023 at 11:37, Michal Simek wrote: > > Hi, > > On 7/20/23 07:49, AKASHI Takahiro wrote: > > Hi, > > > > On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote: > >> > >> > >> On 7/18/23 17:41, Heinrich Schuchardt wrote: > >>> On 13.07.23 16:35, Michal Simek wrote: > Empty capsule are also allowed to be process. Without it updated images > can't change their Image Acceptance state from no to yes. > >>> > >>> Is there any documentation describing the usage of empty capsule to set > >>> the image acceptance state? > >> > >> I actually don't know about documentation. I was talking to Ilias to make > >> sure that documentation is up2date because there are missing couple of > >> things there. > > > > Sughosh should have more to say here about A/B update. > > > >> I am testing A/B update and if you setup oemflags to 0x8000 then capsules > >> are not automatically accepted and waiting for acceptance capsule to be > >> passed. > >> When I tested it I found out that they are not process that's why I created > >> this patch. > > > > The path you tried to modify is only executed by "efidebug capsule update" > > or more specifically via the runtime service, UPDATE_CAPSULE. > > > > But this API is NOT officially supported in the current capsule > > implementation > > (at least, in my initial intention). > > The only way to invoke capsule updates is to reboot the system. > > If you want to test A/B update, please do the reboot. > > I realized that to get full flow you need to use capsule update on disk to get > all functionalities. But it is very impractical. Actually I would expect via > efidebug you should be able to perform all steps as capsule update performs > when > you do reboot. > I would also understand that via efidebug you are not able to apply any > capsule > but I don't think it is right that you can apply just update capsules but not > empty capsules. I would understand none or all but not something in the > middle. The A/B update functionality requires using the capsule-on-disk functionality for performing the updates. This is also mentioned in the fwu_updates.rst document. You should be able to apply empty capsules even with the 'efidebug disk-update' command. I have never used the 'efidebug capsule update' command, so I'm not sure if that is supported. Like Takahiro mentioned, if you place the capsules(genuine or empty) under the /EFI/UpdateCapsule/ directory, the update should happen automatically, since the fwu update feature also enables the EFI_CAPSULE_ON_DISK_EARLY config. -sughosh > > Thanks, > Michal
Re: [PATCH v4 12/12] sandbox: capsule: Generate capsule related files through binman
hi Simon,
On Wed, 19 Jul 2023 at 06:41, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Mon, 17 Jul 2023 at 05:18, Sughosh Ganu wrote:
> >
> > hi Simon,
> >
> > On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu
> > > wrote:
> > > >
> > > > The EFI capsule files can now be generated as part of u-boot
> > > > build. This is done through binman. Add capsule entry nodes in the
> > > > u-boot.dtsi for the sandbox architecture for generating the
> > > > capsules. Remove the corresponding generation of capsules from the
> > > > capsule update conftest file.
> > > >
> > > > The capsules are generated through the config file for the sandbox
> > > > variant, and through explicit parameters for the sandbox_flattree
> > > > variant.
> > > >
> > > > Also generate the FIT image used for testing the capsule update
> > > > feature on the sandbox_flattree variant through binman. Remove the now
> > > > superfluous its file which was used for generating this FIT image.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > Changes since V3:
> > > > * Use blob nodes instead of incbin for including the binaries in FIT
> > > > image.
> > > > * Enable generation of capsules with versioning support.
> > > >
> > > > arch/sandbox/dts/u-boot.dtsi | 265 ++
> > > > test/py/tests/test_efi_capsule/conftest.py| 127 -
> > > > .../tests/test_efi_capsule/uboot_bin_env.its | 36 ---
> > > > 3 files changed, 265 insertions(+), 163 deletions(-)
> > > > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> > > >
> > > > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > > > index 60bd004937..7b0250ac81 100644
> > > > --- a/arch/sandbox/dts/u-boot.dtsi
> > > > +++ b/arch/sandbox/dts/u-boot.dtsi
> > > > @@ -13,5 +13,270 @@
> > > > capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > > > };
> > > > #endif
> > > > +
> > > > + binman: binman {
> > > > + multiple-images;
> > > > + };
> > > > +};
> > > > +
> > > > + {
> > > > + itb {
> > > > + filename = "/tmp/capsules/uboot_bin_env.itb";
> > > > +
> > > > + fit {
> > > > + description = "Automatic U-Boot environment
> > > > update";
> > > > + #address-cells = <2>;
> > > > +
> > > > + images {
> > > > + u-boot-bin {
> > > > + description = "U-Boot binary on
> > > > SPI Flash";
> > > > + compression = "none";
> > > > + type = "firmware";
> > > > + arch = "sandbox";
> > > > + load = <0>;
> > > > + blob {
> > > > + filename =
> > > > "/tmp/capsules/u-boot.bin.new";
> > > > + };
> > > > +
> > > > + hash-1 {
> > > > + algo = "sha1";
> > > > + };
> > > > + };
> > > > + u-boot-env {
> > > > + description = "U-Boot
> > > > environment on SPI Flash";
> > > > + compression = "none";
> > > > + type = "firmware";
> > > > + arch = "sandbox";
> > > > + load = <0>;
> > > > + blob {
> > > > +
Re: [PATCH v4 06/12] binman: capsule: Add support for generating capsules
hi Simon, On Wed, 19 Jul 2023 at 06:41, Simon Glass wrote: > > Hi Sughosh, > > On Mon, 17 Jul 2023 at 04:44, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu > > > wrote: > > > > > > > > Add support in binman for generating capsules. The capsule parameters > > > > can be specified either through a config file or through the capsule > > > > binman entry. Also add test cases in binman for capsule generation, > > > > and enable this testing on the sandbox_spl variant. > > > > > > Can you use sandbox instead, or perhaps sandbox_spl? SPL is really for > > > SPL testing. > > > > Er, I am actually using the sandbox_spl variant. > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > --- > > > > Changes since V3: > > > > * Add test cases for covering the various capsule generation > > > > scenarios. > > > > * Add function comments in the mkeficapsule bintool. > > > > * Fix the fetch method of the mkeficapsule bintool to enable building > > > > the tool. > > > > * Add more details about the capsule parameters in the documentation > > > > as well as the code. > > > > * Fix order of module imports, and addition of blank lines in the > > > > capsule.py file. > > > > * Use SetContents in the ObtainContents method. > > > > > > > > configs/sandbox_spl_defconfig | 1 + > > > > tools/binman/btool/mkeficapsule.py| 158 ++ > > > > tools/binman/entries.rst | 37 > > > > tools/binman/etype/capsule.py | 132 +++ > > > > tools/binman/ftest.py | 127 ++ > > > > tools/binman/test/282_capsule.dts | 18 ++ > > > > tools/binman/test/283_capsule_signed.dts | 20 +++ > > > > tools/binman/test/284_capsule_conf.dts| 14 ++ > > > > tools/binman/test/285_capsule_missing_key.dts | 19 +++ > > > > .../binman/test/286_capsule_missing_index.dts | 17 ++ > > > > .../binman/test/287_capsule_missing_guid.dts | 17 ++ > > > > .../test/288_capsule_missing_payload.dts | 17 ++ > > > > tools/binman/test/289_capsule_missing.dts | 17 ++ > > > > tools/binman/test/290_capsule_version.dts | 19 +++ > > > > tools/binman/test/capsule_cfg.txt | 6 + > > > > 15 files changed, 619 insertions(+) > > > > create mode 100644 tools/binman/btool/mkeficapsule.py > > > > create mode 100644 tools/binman/etype/capsule.py > > > > create mode 100644 tools/binman/test/282_capsule.dts > > > > create mode 100644 tools/binman/test/283_capsule_signed.dts > > > > create mode 100644 tools/binman/test/284_capsule_conf.dts > > > > create mode 100644 tools/binman/test/285_capsule_missing_key.dts > > > > create mode 100644 tools/binman/test/286_capsule_missing_index.dts > > > > create mode 100644 tools/binman/test/287_capsule_missing_guid.dts > > > > create mode 100644 tools/binman/test/288_capsule_missing_payload.dts > > > > create mode 100644 tools/binman/test/289_capsule_missing.dts > > > > create mode 100644 tools/binman/test/290_capsule_version.dts > > > > create mode 100644 tools/binman/test/capsule_cfg.txt > > > > > > This looks pretty good to me. Some nits below > > > > > > > > > > > diff --git a/configs/sandbox_spl_defconfig > > > > b/configs/sandbox_spl_defconfig > > > > index dd848c57c6..2fcc789347 100644 > > > > --- a/configs/sandbox_spl_defconfig > > > > +++ b/configs/sandbox_spl_defconfig > > > > @@ -248,3 +248,4 @@ CONFIG_UNIT_TEST=y > > > > CONFIG_SPL_UNIT_TEST=y > > > > CONFIG_UT_TIME=y > > > > CONFIG_UT_DM=y > > > > +CONFIG_TOOLS_MKEFICAPSULE=y > > > > > > Why enabling this here? I don't think it is needed in sandbox_spl, but > > > in any case it should be in a different patch if needed. > > > > The binman tests run on the sandbox_spl variant. When running the > > capsule generation tests, the mkeficapsule tool should be present on > > the board variant no? > > Can we run this on the 'sandbox'
Re: [PATCH v4 08/12] CI: capsule: Setup the files needed for capsule update testing
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
>
> Hi,
>
> On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote:
> >
> > Support has being added through earlier commits to build capsules
> > and embed the public key needed for capsule authentication as part of
> > u-boot build.
> >
> > From the testing point-of-view, this means the input files needed for
> > generating the above have to be setup before invoking the build. Set
> > this up in the CI configuration files for testing the capsule update
> > feature.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V3:
> > * Remove whitespace in the command to generate capsule keys.
> >
> > .azure-pipelines.yml | 24
> > .gitlab-ci.yml | 22 ++
>
> Can you add this to the Dockerfile instead? It looks like this will
> run on each build.
Okay. Let me try this out.
-sughosh
>
> > 2 files changed, 46 insertions(+)
> >
> > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > index 06c46b681c..d732ba443d 100644
> > --- a/.azure-pipelines.yml
> > +++ b/.azure-pipelines.yml
> > @@ -398,6 +398,17 @@ stages:
> >wget -O -
> > https://github.com/riscv-software-src/opensbi/releases/download/v1.2/opensbi-1.2-rv-bin.tar.xz
> > | tar -C /tmp -xJ;
> >export
> > OPENSBI=/tmp/opensbi-1.2-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
> >fi
> > + mkdir -p /tmp/capsules/;
> > + echo -n "u-boot:Old" >/tmp/capsules/u-boot.bin.old;
> > + echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> > + echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> > + echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > + if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
> > "sandbox_flattree" ]]; then
> > + openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out
> > /tmp/capsules/SIGNER.crt -nodes -days 365;
> > + openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
> > /tmp/capsules/SIGNER2.crt -nodes -days 365;
> > + cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
> > /tmp/capsules/SIGNER.esl;
> > + fi
> > +
> ># the below corresponds to .gitlab-ci.yml "script"
> >cd ${WORK_DIR}
> >export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD};
> > @@ -582,6 +593,19 @@ stages:
> >cd ${WORK_DIR}
> ># make environment variables available as tests are running
> > inside a container
> >export BUILDMAN="${BUILDMAN}"
> > + if [[ "${BUILDMAN}" == "sandbox" ]] || [[ "${BUILDMAN}" ==
> > "sandbox x86" ]]; then
> > + if [ ! -d "/tmp/capsules/" ]; then
> > + mkdir -p /tmp/capsules/;
> > + echo -n "u-boot:Old" >/tmp/capsules/u-boot.bin.old;
> > + echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> > + echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> > + echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > +
> > + openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out
> > /tmp/capsules/SIGNER.crt -nodes -days 365;
> > + openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
> > /tmp/capsules/SIGNER2.crt -nodes -days 365;
> > + cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
> > /tmp/capsules/SIGNER.esl;
> > + fi
> > + fi
> >git config --global --add safe.directory ${WORK_DIR}
> >EOF
> >cat << "EOF" >> build.sh
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index cfd58513c3..aec6ffaf1c 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -37,6 +37,17 @@ stages:
> > export
> > OPENSBI=/tmp/opensbi-1.2-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
> >fi
> >
> > +- mkdir -p /tmp/capsules/;
> > +- echo -n &q
Re: [PATCH v4 12/12] sandbox: capsule: Generate capsule related files through binman
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote:
> >
> > The EFI capsule files can now be generated as part of u-boot
> > build. This is done through binman. Add capsule entry nodes in the
> > u-boot.dtsi for the sandbox architecture for generating the
> > capsules. Remove the corresponding generation of capsules from the
> > capsule update conftest file.
> >
> > The capsules are generated through the config file for the sandbox
> > variant, and through explicit parameters for the sandbox_flattree
> > variant.
> >
> > Also generate the FIT image used for testing the capsule update
> > feature on the sandbox_flattree variant through binman. Remove the now
> > superfluous its file which was used for generating this FIT image.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V3:
> > * Use blob nodes instead of incbin for including the binaries in FIT
> > image.
> > * Enable generation of capsules with versioning support.
> >
> > arch/sandbox/dts/u-boot.dtsi | 265 ++
> > test/py/tests/test_efi_capsule/conftest.py| 127 -
> > .../tests/test_efi_capsule/uboot_bin_env.its | 36 ---
> > 3 files changed, 265 insertions(+), 163 deletions(-)
> > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> >
> > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > index 60bd004937..7b0250ac81 100644
> > --- a/arch/sandbox/dts/u-boot.dtsi
> > +++ b/arch/sandbox/dts/u-boot.dtsi
> > @@ -13,5 +13,270 @@
> > capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > };
> > #endif
> > +
> > + binman: binman {
> > + multiple-images;
> > + };
> > +};
> > +
> > + {
> > + itb {
> > + filename = "/tmp/capsules/uboot_bin_env.itb";
> > +
> > + fit {
> > + description = "Automatic U-Boot environment update";
> > + #address-cells = <2>;
> > +
> > + images {
> > + u-boot-bin {
> > + description = "U-Boot binary on SPI
> > Flash";
> > + compression = "none";
> > + type = "firmware";
> > + arch = "sandbox";
> > + load = <0>;
> > + blob {
> > + filename =
> > "/tmp/capsules/u-boot.bin.new";
> > + };
> > +
> > + hash-1 {
> > + algo = "sha1";
> > + };
> > + };
> > + u-boot-env {
> > + description = "U-Boot environment
> > on SPI Flash";
> > + compression = "none";
> > + type = "firmware";
> > + arch = "sandbox";
> > + load = <0>;
> > + blob {
> > + filename =
> > "/tmp/capsules/u-boot.env.new";
> > + };
> > +
> > + hash-1 {
> > + algo = "sha1";
> > + };
> > + };
> > + };
> > + };
> > + };
> > +
> > +#ifdef CONFIG_EFI_USE_CAPSULE_CFG_FILE
> > + capsule1 {
> > + capsule {
> > + cfg-file = CONFIG_EFI_CAPSULE_CFG_FILE;
> > + };
> > + };
> > +#else
> > + capsule2 {
> > + capsule {
> > + image-index = <0x1>;
> > + image-type-id =
> > "09D7CF52-0720-4710-91D1-08469B7FE9C8";
>
> We seem to have a persisten
Re: [PATCH v4 01/12] binman: bintool: Build a tool from a list of commands
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote:
> >
> > Add support to build a tool from source with a list of commands. This
> > is useful when a tool can be built with multiple commands instead of a
> > single command.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V3:
> > * New patch to support passing multiple commands to the build_from_git
> > function to build the tool.
> >
> > tools/binman/bintool.py| 19 +++
> > tools/binman/btool/_testing.py | 3 ++-
> > tools/binman/btool/fiptool.py | 4 +++-
> > tools/binman/btool/futility.py | 4 +++-
> > 4 files changed, 19 insertions(+), 11 deletions(-)
> >
> > diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
> > index 81629683df..279bf2fec4 100644
> > --- a/tools/binman/bintool.py
> > +++ b/tools/binman/bintool.py
> > @@ -328,7 +328,7 @@ class Bintool:
> > return result.stdout
> >
> > @classmethod
> > -def build_from_git(cls, git_repo, make_target, bintool_path,
> > flags=None):
> > +def build_from_git(cls, git_repo, make_targets, bintool_path,
> > flags=None):
> > """Build a bintool from a git repo
> >
> > This clones the repo in a temporary directory, builds it with
> > 'make',
> > @@ -336,7 +336,8 @@ class Bintool:
> >
> > Args:
> > git_repo (str): URL of git repo
> > -make_target (str): Target to pass to 'make' to build the tool
> > +make_targets (list of str): List of targets to pass to 'make'
> > to build
> > +the tool
> > bintool_path (str): Relative path of the tool in the repo,
> > after
> > build is complete
> > flags (list of str): Flags or variables to pass to make, or
> > None
> > @@ -350,12 +351,14 @@ class Bintool:
> > tmpdir = tempfile.mkdtemp(prefix='binmanf.')
> > print(f"- clone git repo '{git_repo}' to '{tmpdir}'")
> > tools.run('git', 'clone', '--depth', '1', git_repo, tmpdir)
> > -print(f"- build target '{make_target}'")
> > -cmd = ['make', '-C', tmpdir, '-j',
> > f'{multiprocessing.cpu_count()}',
> > - make_target]
> > -if flags:
> > -cmd += flags
> > -tools.run(*cmd)
> > +for target in make_targets:
> > +print(f"- build target '{target}'")
> > +cmd = ['make', '-C', tmpdir, '-j',
> > f'{multiprocessing.cpu_count()}',
> > + target]
> > +if flags:
> > +cmd += flags
> > +tools.run(*cmd)
> > +
> > fname = os.path.join(tmpdir, bintool_path)
> > if not os.path.exists(fname):
> > print(f"- File '{fname}' was not produced")
> > diff --git a/tools/binman/btool/_testing.py b/tools/binman/btool/_testing.py
> > index 4005e8a8a5..c0109c76bf 100644
> > --- a/tools/binman/btool/_testing.py
> > +++ b/tools/binman/btool/_testing.py
> > @@ -32,5 +32,6 @@ class Bintool_testing(bintool.Bintool):
> > return self.apt_install('package')
> > return self.fetch_from_drive('junk')
> > if method == bintool.FETCH_BUILD:
> > -return self.build_from_git('url', 'target', 'pathname')
> > +cmd = ['target']
> > +return self.build_from_git('url', cmd, 'pathname')
>
> Instead of the 'cmd' variable here, can you just put ['target'] as the
> function arg? Same below. It doesn't really add anything.
Okay. Will change.
-sughosh
>
> > return None
> > diff --git a/tools/binman/btool/fiptool.py b/tools/binman/btool/fiptool.py
> > index c80f8275c4..b275fee43b 100644
> > --- a/tools/binman/btool/fiptool.py
> > +++ b/tools/binman/btool/fiptool.py
> > @@ -107,8 +107,10 @@ class Bintoolfiptool(bintool.Bintool):
> > """
> > if method != bintool.FETCH_BUILD:
> > return None
> > +
> > +cmd = ['fiptool']
> > result = self.build_from_git(
> > 'https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git',
> > -'fiptool',
> > +cmd,
> > 'tools/fiptool/fiptool')
> > return result
> > diff --git a/tools/binman/btool/futility.py
Re: [PATCH v4 06/12] binman: capsule: Add support for generating capsules
hi Simon, On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote: > > Hi Sughosh, > > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote: > > > > Add support in binman for generating capsules. The capsule parameters > > can be specified either through a config file or through the capsule > > binman entry. Also add test cases in binman for capsule generation, > > and enable this testing on the sandbox_spl variant. > > Can you use sandbox instead, or perhaps sandbox_spl? SPL is really for > SPL testing. Er, I am actually using the sandbox_spl variant. > > > > > Signed-off-by: Sughosh Ganu > > --- > > Changes since V3: > > * Add test cases for covering the various capsule generation > > scenarios. > > * Add function comments in the mkeficapsule bintool. > > * Fix the fetch method of the mkeficapsule bintool to enable building > > the tool. > > * Add more details about the capsule parameters in the documentation > > as well as the code. > > * Fix order of module imports, and addition of blank lines in the > > capsule.py file. > > * Use SetContents in the ObtainContents method. > > > > configs/sandbox_spl_defconfig | 1 + > > tools/binman/btool/mkeficapsule.py| 158 ++ > > tools/binman/entries.rst | 37 > > tools/binman/etype/capsule.py | 132 +++ > > tools/binman/ftest.py | 127 ++ > > tools/binman/test/282_capsule.dts | 18 ++ > > tools/binman/test/283_capsule_signed.dts | 20 +++ > > tools/binman/test/284_capsule_conf.dts| 14 ++ > > tools/binman/test/285_capsule_missing_key.dts | 19 +++ > > .../binman/test/286_capsule_missing_index.dts | 17 ++ > > .../binman/test/287_capsule_missing_guid.dts | 17 ++ > > .../test/288_capsule_missing_payload.dts | 17 ++ > > tools/binman/test/289_capsule_missing.dts | 17 ++ > > tools/binman/test/290_capsule_version.dts | 19 +++ > > tools/binman/test/capsule_cfg.txt | 6 + > > 15 files changed, 619 insertions(+) > > create mode 100644 tools/binman/btool/mkeficapsule.py > > create mode 100644 tools/binman/etype/capsule.py > > create mode 100644 tools/binman/test/282_capsule.dts > > create mode 100644 tools/binman/test/283_capsule_signed.dts > > create mode 100644 tools/binman/test/284_capsule_conf.dts > > create mode 100644 tools/binman/test/285_capsule_missing_key.dts > > create mode 100644 tools/binman/test/286_capsule_missing_index.dts > > create mode 100644 tools/binman/test/287_capsule_missing_guid.dts > > create mode 100644 tools/binman/test/288_capsule_missing_payload.dts > > create mode 100644 tools/binman/test/289_capsule_missing.dts > > create mode 100644 tools/binman/test/290_capsule_version.dts > > create mode 100644 tools/binman/test/capsule_cfg.txt > > This looks pretty good to me. Some nits below > > > > > diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig > > index dd848c57c6..2fcc789347 100644 > > --- a/configs/sandbox_spl_defconfig > > +++ b/configs/sandbox_spl_defconfig > > @@ -248,3 +248,4 @@ CONFIG_UNIT_TEST=y > > CONFIG_SPL_UNIT_TEST=y > > CONFIG_UT_TIME=y > > CONFIG_UT_DM=y > > +CONFIG_TOOLS_MKEFICAPSULE=y > > Why enabling this here? I don't think it is needed in sandbox_spl, but > in any case it should be in a different patch if needed. The binman tests run on the sandbox_spl variant. When running the capsule generation tests, the mkeficapsule tool should be present on the board variant no? > > > diff --git a/tools/binman/btool/mkeficapsule.py > > b/tools/binman/btool/mkeficapsule.py > > new file mode 100644 > > index 00..ba6b666714 > > --- /dev/null > > +++ b/tools/binman/btool/mkeficapsule.py > > @@ -0,0 +1,158 @@ > > +# SPDX-License-Identifier: GPL-2.0+ > > +# Copyright 2023 Linaro Limited > > +# > > +"""Bintool implementation for mkeficapsule tool > > + > > +mkeficapsule is a tool used for generating EFI capsules. > > + > > +The following are the command-line options to be provided > > +to the tool > > +Usage: mkeficapsule [options] > > +Options: > > + -g, --guid guid for image blob type > > + -i, --index update image index > > + -I, --instanceupdate hardware instance > > + -v, --fw-version firmware version > > + -p, --private-key private key file > > + -c, --certificate signer's certifica
Re: [PATCH v4 11/12] sandbox: capsule: Add a config file for generating capsules
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
>
> Hi,
>
> On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote:
> >
> > Support has been added to the mkeficapsule tool to generate capsules
> > by parsing the capsule parameters through a config file. Add a config
> > file for generating capsules. These capsules will be used for testing
> > the capsule update feature on sandbox platform.
> >
> > Enable generation of capsules through the config file on the sandbox
> > variant.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V3:
> > * Use fstrings for format specifiers.
> > * Add entries for generating capsules with version parameter.
> >
> > .azure-pipelines.yml | 2 +
> > .gitlab-ci.yml| 2 +
> > configs/sandbox_defconfig | 2 +
> > test/py/conftest.py | 5 +
> > .../test_efi_capsule/sandbox_capsule_cfg.txt | 162 ++
> > 5 files changed, 173 insertions(+)
> > create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> >
> > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > index d732ba443d..240ee4f692 100644
> > --- a/.azure-pipelines.yml
> > +++ b/.azure-pipelines.yml
> > @@ -403,6 +403,7 @@ stages:
> >echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> >echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> >echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > + cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> > /tmp/capsules/;
> >if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
> > "sandbox_flattree" ]]; then
> >openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out
> > /tmp/capsules/SIGNER.crt -nodes -days 365;
> >openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
> > /tmp/capsules/SIGNER2.crt -nodes -days 365;
> > @@ -600,6 +601,7 @@ stages:
> >echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> >echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> >echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > + cp
> > test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt /tmp/capsules/;
> >
> >openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out
> > /tmp/capsules/SIGNER.crt -nodes -days 365;
> >openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
> > /tmp/capsules/SIGNER2.crt -nodes -days 365;
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index aec6ffaf1c..42456e5f3f 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -42,6 +42,7 @@ stages:
> > - echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> > - echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> > - echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > +- cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> > /tmp/capsules/;
> > - if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
> > "sandbox_flattree" ]]; then
> > openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days
> > 365;
> > openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes
> > -days 365;
> > @@ -148,6 +149,7 @@ build all other platforms:
> > echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> > echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> > echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > +cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> > /tmp/capsules/;
> >
> > openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days
> > 365;
> > openssl req -x5
Re: [PATCH v4 03/12] capsule: authenticate: Add capsule public key in platform's dtb
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote:
> >
> > The EFI capsule authentication logic in u-boot expects the public key
> > in the form of an EFI Signature List(ESL) to be provided as part of
> > the platform's dtb. Currently, the embedding of the ESL file into the
> > dtb needs to be done manually.
> >
> > Add a signature node in the u-boot dtsi file and include the public
> > key through the capsule-key property. This file is per architecture,
> > and is currently being added for sandbox and arm architectures. It
> > will have to be added for other architectures which need to enable
> > capsule authentication support.
> >
> > The path to the ESL file is specified through the
> > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V3:
> > * Put the two ifdef statements together in arm architecture's
> > u-boot.dtsi file.
> > * Remove the extra blank line in the Kconfig.
> >
> > arch/arm/dts/u-boot.dtsi | 17 +
> > arch/sandbox/dts/u-boot.dtsi | 17 +
> > lib/efi_loader/Kconfig | 10 ++
> > lib/efi_loader/Makefile | 7 +++
> > 4 files changed, 51 insertions(+)
> > create mode 100644 arch/arm/dts/u-boot.dtsi
> > create mode 100644 arch/sandbox/dts/u-boot.dtsi
>
> This approach seems OK to me for now. It is a bit strange to specify a
> CONFIG option to add something to the DT, but we can always adjust it
> later if needed.
>
> >
> > diff --git a/arch/arm/dts/u-boot.dtsi b/arch/arm/dts/u-boot.dtsi
> > new file mode 100644
> > index 00..2a9359c43c
> > --- /dev/null
> > +++ b/arch/arm/dts/u-boot.dtsi
> > @@ -0,0 +1,17 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
>
> /**
>
> for multi-line comments
Okay
>
> > + * Devicetree file with miscellaneous nodes that will be included
> > + * at build time into the DTB. Currently being used for including
> > + * capsule related information.
> > + *
>
> drop blank line
Okay
>
> > + */
> > +
> > +#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
> > +#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
>
> Can you combine these, or can you omit the first one?
I will drop the first line. Should build for all platforms I believe.
>
> > +/ {
> > + signature {
> > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > + };
> > +};
> > +#endif /* CONFIG_EFI_CAPSULE_AUTHENTICATE */
> > +#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
> > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > new file mode 100644
> > index 00..60bd004937
> > --- /dev/null
> > +++ b/arch/sandbox/dts/u-boot.dtsi
> > @@ -0,0 +1,17 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Devicetree file with miscellaneous nodes that will be included
> > + * at build time into the DTB. Currently being used for including
> > + * capsule related information.
> > + *
> > + */
> > +
> > +#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
> > +/ {
> > +#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> > + signature {
> > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > + };
> > +#endif
> > +};
> > +#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index a22e47616f..9abb9a4db3 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -235,6 +235,16 @@ config EFI_CAPSULE_MAX
> > Select the max capsule index value used for capsule report
> > variables. This value is used to create CapsuleMax variable.
> >
> > +config EFI_CAPSULE_ESL_FILE
> > + string "Path to the EFI Signature List File"
> > + default ""
> > + depends on EFI_CAPSULE_AUTHENTICATE
> > + help
> > + Provides the absolute path to the EFI Signature List
> > + file which will be embedded in the platform's device
> > + tree and used for capsule authentication at the time
> > + of capsule update.
>
> Can you wrap to 72 chars or so?
Okay
-sughosh
>
> > +
> > config EFI_DEVICE_PATH_TO_TEXT
> > bool "Device path to text protocol"
> > default y
> > diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> > index 1a8c8d7cab..c52c9d27bd 100644
> > --- a/lib/efi_loader/Makefile
> > +++ b/lib/efi_loader/Makefile
> > @@ -89,3 +89,10 @@ obj-$(CONFIG_EFI_ECPT) += efi_conformance.o
> >
> > EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
> > $(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
> > +
> > +ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
> > +EFI_CAPSULE_KEY_PATH := $(subst $\",,$(CONFIG_EFI_CAPSULE_ESL_FILE))
> > +ifeq ("$(wildcard $(EFI_CAPSULE_KEY_PATH))","")
> > +$(error .esl cerificate not found. Configure your
> > CONFIG_EFI_CAPSULE_ESL_FILE)
> > +endif
> > +endif
> > --
> > 2.34.1
> >
>
> REgards,
> Simon
[PATCH v4 12/12] sandbox: capsule: Generate capsule related files through binman
The EFI capsule files can now be generated as part of u-boot
build. This is done through binman. Add capsule entry nodes in the
u-boot.dtsi for the sandbox architecture for generating the
capsules. Remove the corresponding generation of capsules from the
capsule update conftest file.
The capsules are generated through the config file for the sandbox
variant, and through explicit parameters for the sandbox_flattree
variant.
Also generate the FIT image used for testing the capsule update
feature on the sandbox_flattree variant through binman. Remove the now
superfluous its file which was used for generating this FIT image.
Signed-off-by: Sughosh Ganu
---
Changes since V3:
* Use blob nodes instead of incbin for including the binaries in FIT
image.
* Enable generation of capsules with versioning support.
arch/sandbox/dts/u-boot.dtsi | 265 ++
test/py/tests/test_efi_capsule/conftest.py| 127 -
.../tests/test_efi_capsule/uboot_bin_env.its | 36 ---
3 files changed, 265 insertions(+), 163 deletions(-)
delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
index 60bd004937..7b0250ac81 100644
--- a/arch/sandbox/dts/u-boot.dtsi
+++ b/arch/sandbox/dts/u-boot.dtsi
@@ -13,5 +13,270 @@
capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
};
#endif
+
+ binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ itb {
+ filename = "/tmp/capsules/uboot_bin_env.itb";
+
+ fit {
+ description = "Automatic U-Boot environment update";
+ #address-cells = <2>;
+
+ images {
+ u-boot-bin {
+ description = "U-Boot binary on SPI
Flash";
+ compression = "none";
+ type = "firmware";
+ arch = "sandbox";
+ load = <0>;
+ blob {
+ filename =
"/tmp/capsules/u-boot.bin.new";
+ };
+
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ u-boot-env {
+ description = "U-Boot environment on
SPI Flash";
+ compression = "none";
+ type = "firmware";
+ arch = "sandbox";
+ load = <0>;
+ blob {
+ filename =
"/tmp/capsules/u-boot.env.new";
+ };
+
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ };
+ };
+ };
+
+#ifdef CONFIG_EFI_USE_CAPSULE_CFG_FILE
+ capsule1 {
+ capsule {
+ cfg-file = CONFIG_EFI_CAPSULE_CFG_FILE;
+ };
+ };
+#else
+ capsule2 {
+ capsule {
+ image-index = <0x1>;
+ image-type-id = "09D7CF52-0720-4710-91D1-08469B7FE9C8";
+ filename = "/tmp/capsules/u-boot.bin.new";
+ capsule = "/tmp/capsules/Test01";
+ };
+ };
+
+ capsule3 {
+ capsule {
+ image-index = <0x2>;
+ image-type-id = "5A7021F5-FEF2-48B4-AABA-832E777418C0";
+ filename = "/tmp/capsules/u-boot.env.new";
+ capsule = "/tmp/capsules/Test02";
+ };
+ };
+
+ capsule4 {
+ capsule {
+ image-index = <0x1>;
+ image-type-id = "058B7D83-50D5-4C47-A195-60D86AD341C4";
+ filename = "/tmp/capsules/u-boot.bin.new";
+ capsule = "/tmp/capsules/Test03";
+ };
+ };
+
+ capsule5 {
+ capsule {
+ image-index = <0x1>;
+ image-type-id = "3673B45D-6A7C-46F3-9E60-ADABB03F7937";
+ filename = "/tmp/capsules/uboot_bin_env.itb";
[PATCH v4 11/12] sandbox: capsule: Add a config file for generating capsules
Support has been added to the mkeficapsule tool to generate capsules
by parsing the capsule parameters through a config file. Add a config
file for generating capsules. These capsules will be used for testing
the capsule update feature on sandbox platform.
Enable generation of capsules through the config file on the sandbox
variant.
Signed-off-by: Sughosh Ganu
---
Changes since V3:
* Use fstrings for format specifiers.
* Add entries for generating capsules with version parameter.
.azure-pipelines.yml | 2 +
.gitlab-ci.yml| 2 +
configs/sandbox_defconfig | 2 +
test/py/conftest.py | 5 +
.../test_efi_capsule/sandbox_capsule_cfg.txt | 162 ++
5 files changed, 173 insertions(+)
create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index d732ba443d..240ee4f692 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -403,6 +403,7 @@ stages:
echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+ cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
/tmp/capsules/;
if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
"sandbox_flattree" ]]; then
openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt
-nodes -days 365;
openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
/tmp/capsules/SIGNER2.crt -nodes -days 365;
@@ -600,6 +601,7 @@ stages:
echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+ cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
/tmp/capsules/;
openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt
-nodes -days 365;
openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
/tmp/capsules/SIGNER2.crt -nodes -days 365;
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index aec6ffaf1c..42456e5f3f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -42,6 +42,7 @@ stages:
- echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
- echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
- echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+- cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt /tmp/capsules/;
- if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
"sandbox_flattree" ]]; then
openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days 365;
openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes -days
365;
@@ -148,6 +149,7 @@ build all other platforms:
echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
/tmp/capsules/;
openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days 365;
openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes -days
365;
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 560f3317d9..f3c09f845a 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -341,6 +341,8 @@ CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
+CONFIG_EFI_CAPSULE_CFG_FILE="/tmp/capsules/sandbox_capsule_cfg.txt"
+CONFIG_EFI_USE_CAPSULE_CFG_FILE=y
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/test/py/conftest.py b/test/py/conftest.py
index 1092cb713b..20b8dc1913 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -158,6 +158,11 @@ def setup_capsule_build(source_dir, build_dir, board_type,
log):
f'-out {capsule_sig_dir}{sig_name}.crt
[PATCH v4 10/12] test: capsule: Remove public key embed logic from capsule update test
The embedding of the public key EFI Signature List(ESL) file into the
platform's DTB is now done at the time of u-boot build. Remove this
logic from the capsule update test' configuration.
Include the public key for the sandbox and sandbox_flattree variant
as part of the build.
Signed-off-by: Sughosh Ganu
Reviewed-by: Simon Glass
---
Changes since V3:
* Rebase on top of current master to work with test configuration for
version support in capsule updates.
configs/sandbox_defconfig| 1 +
configs/sandbox_flattree_defconfig | 1 +
test/py/tests/test_efi_capsule/conftest.py | 37
test/py/tests/test_efi_capsule/signature.dts | 10 --
4 files changed, 9 insertions(+), 40 deletions(-)
delete mode 100644 test/py/tests/test_efi_capsule/signature.dts
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 4cef6c5153..560f3317d9 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -340,6 +340,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/configs/sandbox_flattree_defconfig
b/configs/sandbox_flattree_defconfig
index e7657d40dc..8d60744771 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -226,6 +226,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
CONFIG_UNIT_TEST=y
CONFIG_UT_TIME=y
CONFIG_UT_DM=y
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index 054be1ee97..99b502902e 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -25,48 +25,25 @@ def efi_capsule_data(request, u_boot_config):
image_path = u_boot_config.persistent_data_dir + '/test_efi_capsule.img'
try:
+capsules_path_dir = '/tmp/capsules/'
# Create a target device
check_call('dd if=/dev/zero of=./spi.bin bs=1MiB count=16', shell=True)
check_call('rm -rf %s' % mnt_point, shell=True)
check_call('mkdir -p %s' % data_dir, shell=True)
check_call('mkdir -p %s' % install_dir, shell=True)
-
-capsule_auth_enabled = u_boot_config.buildconfig.get(
-'config_efi_capsule_authenticate')
-if capsule_auth_enabled:
-# Create private key (SIGNER.key) and certificate (SIGNER.crt)
-check_call('cd %s; '
- 'openssl req -x509 -sha256 -newkey rsa:2048 '
-'-subj /CN=TEST_SIGNER/ -keyout SIGNER.key '
-'-out SIGNER.crt -nodes -days 365'
- % data_dir, shell=True)
-check_call('cd %s; %scert-to-efi-sig-list SIGNER.crt SIGNER.esl'
- % (data_dir, EFITOOLS_PATH), shell=True)
-
-# Update dtb adding capsule certificate
-check_call('cd %s; '
- 'cp %s/test/py/tests/test_efi_capsule/signature.dts .'
- % (data_dir, u_boot_config.source_dir), shell=True)
-check_call('cd %s; '
- 'dtc -@ -I dts -O dtb -o signature.dtbo signature.dts; '
- 'fdtoverlay -i %s/arch/sandbox/dts/test.dtb '
-'-o test_sig.dtb signature.dtbo'
- % (data_dir, u_boot_config.build_dir), shell=True)
-
-# Create *malicious* private key (SIGNER2.key) and certificate
-# (SIGNER2.crt)
-check_call('cd %s; '
- 'openssl req -x509 -sha256 -newkey rsa:2048 '
-'-subj /CN=TEST_SIGNER/ -keyout SIGNER2.key '
-'-out SIGNER2.crt -nodes -days 365'
- % data_dir, shell=True)
+check_call('cp %s/* %s ' % (capsules_path_dir, data_dir), shell=True)
# Update dtb to add the version information
check_call('cd %s; '
'cp %s/test/py/tests/test_efi_capsule/version.dts .'
% (data_dir, u_boot_config.source_dir), shell=True)
+
+capsule_auth_enabled = u_boot_config.buildconfig.get(
+'config_efi_capsule_authenticate')
if capsule_auth_enabled:
+check_call('cp %s/arch/sandbox/dts/test.dtb %s/test_sig.dtb' %
+ (u_boot_config.build_dir, data_dir), shell=True)
check_call('cd %s; '
'dtc -@ -I dts -O dtb -o version.dtbo version.dts; '
'fdtoverlay -i test_sig.dtb '
diff --git a/test/py/tests/test_efi_capsule/signature.dts
b/test/py/tests/test_efi_capsule/signature.d
[PATCH v4 09/12] test: py: Setup capsule files for testing
Support has being added through earlier commits to build capsules and
embed the public key needed for capsule authentication as part of
u-boot build.
>From the testing point-of-view, this means the input files needed for
the above have to be setup before invoking the build. Set this up in
the pytest configuration file for testing the capsule update feature.
Signed-off-by: Sughosh Ganu
Reviewed-by: Simon Glass
---
Changes since V3:
* Use fstrings for format specifiers.
test/py/conftest.py | 84 +
1 file changed, 84 insertions(+)
diff --git a/test/py/conftest.py b/test/py/conftest.py
index fc9dd3a83f..1092cb713b 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -80,6 +80,86 @@ def pytest_addoption(parser):
help='Run sandbox under gdbserver. The argument is the channel '+
'over which gdbserver should communicate, e.g. localhost:1234')
+def setup_capsule_build(source_dir, build_dir, board_type, log):
+"""Setup the platform's build for testing capsule updates
+
+This generates the payload/input files needed for testing the
+capsule update functionality, along with the keys for signing
+the capsules. An EFI Signature List(ESL) file, which houses the
+public key for capsule authentication is generated as
+well.
+
+The ESL file is subsequently embedded into the platform's
+dtb during the u-boot build, to be used for capsule
+authentication.
+
+Two sets of keys are generated, namely SIGNER and SIGNER2.
+The SIGNER2 key pair is used as a malicious key for testing the
+the capsule authentication functionality.
+
+All the generated files are placed under the /tmp/capsules/
+directory.
+
+Args:
+soruce_dir (str): Directory containing source code
+build_dir (str): Directory to build in
+board_type (str): board_type parameter (e.g. 'sandbox')
+log (Logfile): Log file to use
+
+Returns:
+Nothing.
+"""
+def run_command(name, cmd, source_dir):
+with log.section(name):
+if isinstance(cmd, str):
+cmd = cmd.split()
+runner = log.get_runner(name, None)
+runner.run(cmd, cwd=source_dir)
+runner.close()
+log.status_pass('OK')
+
+def gen_capsule_payloads(capsule_dir):
+fname = f'{capsule_dir}u-boot.bin.old'
+with open(fname, 'w') as fd:
+fd.write('u-boot:Old')
+
+fname = f'{capsule_dir}u-boot.bin.new'
+with open(fname, 'w') as fd:
+fd.write('u-boot:New')
+
+fname = f'{capsule_dir}u-boot.env.old'
+with open(fname, 'w') as fd:
+fd.write('u-boot-env:Old')
+
+fname = f'{capsule_dir}u-boot.env.new'
+with open(fname, 'w') as fd:
+fd.write('u-boot-env:New')
+
+capsule_sig_dir = '/tmp/capsules/'
+sig_name = 'SIGNER'
+mkdir_p(capsule_sig_dir)
+name = 'openssl'
+cmd = ( 'openssl req -x509 -sha256 -newkey rsa:2048 '
+'-subj /CN=TEST_SIGNER/ -keyout '
+f'{capsule_sig_dir}{sig_name}.key '
+f'-out {capsule_sig_dir}{sig_name}.crt -nodes -days 365' )
+run_command(name, cmd, source_dir)
+
+name = 'cert-to-efi-sig-list'
+cmd = ( f'cert-to-efi-sig-list {capsule_sig_dir}{sig_name}.crt '
+f'{capsule_sig_dir}{sig_name}.esl' )
+run_command(name, cmd, source_dir)
+
+sig_name = 'SIGNER2'
+name = 'openssl'
+cmd = ( 'openssl req -x509 -sha256 -newkey rsa:2048 '
+'-subj /CN=TEST_SIGNER/ -keyout '
+f'{capsule_sig_dir}{sig_name}.key '
+f'-out {capsule_sig_dir}{sig_name}.crt -nodes -days 365' )
+run_command(name, cmd, source_dir)
+
+gen_capsule_payloads(capsule_sig_dir)
+
def run_build(config, source_dir, build_dir, board_type, log):
"""run_build: Build U-Boot
@@ -90,6 +170,10 @@ def run_build(config, source_dir, build_dir, board_type,
log):
board_type (str): board_type parameter (e.g. 'sandbox')
log (Logfile): Log file to use
"""
+capsule_boards = ( 'sandbox', 'sandbox64', 'sandbox_flattree' )
+if board_type in capsule_boards:
+setup_capsule_build(source_dir, build_dir, board_type, log)
+
if config.getoption('buildman'):
if build_dir != source_dir:
dest_args = ['-o', build_dir, '-w']
--
2.34.1
[PATCH v4 08/12] CI: capsule: Setup the files needed for capsule update testing
Support has being added through earlier commits to build capsules
and embed the public key needed for capsule authentication as part of
u-boot build.
>From the testing point-of-view, this means the input files needed for
generating the above have to be setup before invoking the build. Set
this up in the CI configuration files for testing the capsule update
feature.
Signed-off-by: Sughosh Ganu
---
Changes since V3:
* Remove whitespace in the command to generate capsule keys.
.azure-pipelines.yml | 24
.gitlab-ci.yml | 22 ++
2 files changed, 46 insertions(+)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 06c46b681c..d732ba443d 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -398,6 +398,17 @@ stages:
wget -O -
https://github.com/riscv-software-src/opensbi/releases/download/v1.2/opensbi-1.2-rv-bin.tar.xz
| tar -C /tmp -xJ;
export
OPENSBI=/tmp/opensbi-1.2-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
fi
+ mkdir -p /tmp/capsules/;
+ echo -n "u-boot:Old" >/tmp/capsules/u-boot.bin.old;
+ echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
+ echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
+ echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+ if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
"sandbox_flattree" ]]; then
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt
-nodes -days 365;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
/tmp/capsules/SIGNER2.crt -nodes -days 365;
+ cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
/tmp/capsules/SIGNER.esl;
+ fi
+
# the below corresponds to .gitlab-ci.yml "script"
cd ${WORK_DIR}
export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD};
@@ -582,6 +593,19 @@ stages:
cd ${WORK_DIR}
# make environment variables available as tests are running inside a
container
export BUILDMAN="${BUILDMAN}"
+ if [[ "${BUILDMAN}" == "sandbox" ]] || [[ "${BUILDMAN}" == "sandbox
x86" ]]; then
+ if [ ! -d "/tmp/capsules/" ]; then
+ mkdir -p /tmp/capsules/;
+ echo -n "u-boot:Old" >/tmp/capsules/u-boot.bin.old;
+ echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
+ echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
+ echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt
-nodes -days 365;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
/tmp/capsules/SIGNER2.crt -nodes -days 365;
+ cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
/tmp/capsules/SIGNER.esl;
+ fi
+ fi
git config --global --add safe.directory ${WORK_DIR}
EOF
cat << "EOF" >> build.sh
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index cfd58513c3..aec6ffaf1c 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -37,6 +37,17 @@ stages:
export
OPENSBI=/tmp/opensbi-1.2-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
fi
+- mkdir -p /tmp/capsules/;
+- echo -n "u-boot:Old" >/tmp/capsules/u-boot.bin.old;
+- echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
+- echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
+- echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+- if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
"sandbox_flattree" ]]; then
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days 365;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes -days
365;
+ cert-to-efi-sig-list /tmp/capsules/SIGNER.crt /tmp/capsules/SIGNER.esl;
+ fi
+
after_script:
- cp -v /tmp/${TEST_PY_BD}/*.{html,css} .
- rm -rf /tmp/uboot-test-hooks /tmp/venv
@@ -131,6 +142,17 @@ build all other platforms:
stage: world build
script:
- ret=0;
+ if [ ! -d "/tmp/capsules/" ]; then
+mkdir -p /tmp/capsules/;
+echo -n "u-boot:Old"
[PATCH v4 07/12] doc: Add documentation to highlight capsule generation related updates
The UEFI capsule can now be generate by specifying the capsule
parameters through a config file. Additionally, the capsules can be
generated as part of u-boot build, through binman. Highlight these
changes in the documentation.
Signed-off-by: Sughosh Ganu
---
Changes since V3:
* Move the paragraph on version support under a separate subsection.
* Move the description on generating capsules through config file
under the section to describe capsule generation.
* Add a subsection highlighting generation of capsules through
binman.
doc/develop/uefi/uefi.rst | 84 +++
1 file changed, 84 insertions(+)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 3d07aa33b8..251eaa13fd 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -318,6 +318,79 @@ Run the following command
--guid \
+Alternatively, the capsules can be generated through a config
+file. When generating the capsules through a config file, the Kconfig
+symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the
+path to the config file.
+
+The config file describes the parameters that are used for generating
+one or more capsules. The parameters for a given capsule file are
+specified within curly braces, in the form of "key:value" pairs. All
+the parameters that are currently supported by the mkeficapsule tool
+can be specified through the config file.
+
+The following are some example payload parameters specified through
+the config file.
+
+.. code-block:: none
+
+ {
+ image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
+ hardware-instance: 0
+ monotonic-count: 1
+ payload: u-boot.bin
+ image-index: 1
+ fw-version: 2
+ private-key: /path/to/priv/key
+ pub-key-cert: /path/to/pub/key
+ capsule: u-boot.capsule
+ }
+ {
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ hardware-instance: 0
+ payload: u-boot.itb
+ image-index: 2
+ fw-version: 7
+ oemflags: 0x8000
+ capsule: fit.capsule
+ }
+ {
+ capsule-type: accept
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ capsule: accept.capsule
+ }
+ {
+ capsule-type: revert
+ capsule: revert.capsule
+ }
+
+The following are the keys that specify the capsule parameters
+
+..code-block:: none
+
+image-guid: Image GUID
+image-index: Image index value
+fw-version: Image version
+private-key: Path to the private key file used for capsule signing
+pub-key-cert: Path to the public key crt file used for capsule signing
+payload: Path to the capsule payload file
+capsule: Path to the output capsule file that is generated
+hardware-instance: Hardware Instance value
+monotonic-count: Monotonic count value
+capsule-type: Specifies capsule type. normal(default), accept or revert
+oemflags: 16bit Oemflags value to be used(populated in capsule header)
+
+When generating capsules through a config file, the command would look
+like
+
+.. code-block:: console
+
+$ mkeficapsule --cfg-file
+
+
+Capsule with firmware version
+*
+
The UEFI specification does not define the firmware versioning mechanism.
EDK II reference implementation inserts the FMP Payload Header right before
the payload. It coutains the fw_version and lowest supported version,
@@ -345,6 +418,17 @@ add --fw-version option in mkeficapsule tool.
If the --fw-version option is not set, FMP Payload Header is not inserted
and fw_version is set as 0.
+
+Capsule Generation through binman
+*
+
+Support has also been added to generate capsules during u-boot build
+through binman. This requires the platform's DTB to be populated with
+the capsule entry nodes for binman. The capsules then can be generated
+by specifying the capsule parameters either through a config file, or
+by specifying them as properties in the capsule entry node.
+
+
Performing the update
*
--
2.34.1
[PATCH v4 06/12] binman: capsule: Add support for generating capsules
Add support in binman for generating capsules. The capsule parameters
can be specified either through a config file or through the capsule
binman entry. Also add test cases in binman for capsule generation,
and enable this testing on the sandbox_spl variant.
Signed-off-by: Sughosh Ganu
---
Changes since V3:
* Add test cases for covering the various capsule generation
scenarios.
* Add function comments in the mkeficapsule bintool.
* Fix the fetch method of the mkeficapsule bintool to enable building
the tool.
* Add more details about the capsule parameters in the documentation
as well as the code.
* Fix order of module imports, and addition of blank lines in the
capsule.py file.
* Use SetContents in the ObtainContents method.
configs/sandbox_spl_defconfig | 1 +
tools/binman/btool/mkeficapsule.py| 158 ++
tools/binman/entries.rst | 37
tools/binman/etype/capsule.py | 132 +++
tools/binman/ftest.py | 127 ++
tools/binman/test/282_capsule.dts | 18 ++
tools/binman/test/283_capsule_signed.dts | 20 +++
tools/binman/test/284_capsule_conf.dts| 14 ++
tools/binman/test/285_capsule_missing_key.dts | 19 +++
.../binman/test/286_capsule_missing_index.dts | 17 ++
.../binman/test/287_capsule_missing_guid.dts | 17 ++
.../test/288_capsule_missing_payload.dts | 17 ++
tools/binman/test/289_capsule_missing.dts | 17 ++
tools/binman/test/290_capsule_version.dts | 19 +++
tools/binman/test/capsule_cfg.txt | 6 +
15 files changed, 619 insertions(+)
create mode 100644 tools/binman/btool/mkeficapsule.py
create mode 100644 tools/binman/etype/capsule.py
create mode 100644 tools/binman/test/282_capsule.dts
create mode 100644 tools/binman/test/283_capsule_signed.dts
create mode 100644 tools/binman/test/284_capsule_conf.dts
create mode 100644 tools/binman/test/285_capsule_missing_key.dts
create mode 100644 tools/binman/test/286_capsule_missing_index.dts
create mode 100644 tools/binman/test/287_capsule_missing_guid.dts
create mode 100644 tools/binman/test/288_capsule_missing_payload.dts
create mode 100644 tools/binman/test/289_capsule_missing.dts
create mode 100644 tools/binman/test/290_capsule_version.dts
create mode 100644 tools/binman/test/capsule_cfg.txt
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index dd848c57c6..2fcc789347 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -248,3 +248,4 @@ CONFIG_UNIT_TEST=y
CONFIG_SPL_UNIT_TEST=y
CONFIG_UT_TIME=y
CONFIG_UT_DM=y
+CONFIG_TOOLS_MKEFICAPSULE=y
diff --git a/tools/binman/btool/mkeficapsule.py
b/tools/binman/btool/mkeficapsule.py
new file mode 100644
index 00..ba6b666714
--- /dev/null
+++ b/tools/binman/btool/mkeficapsule.py
@@ -0,0 +1,158 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2023 Linaro Limited
+#
+"""Bintool implementation for mkeficapsule tool
+
+mkeficapsule is a tool used for generating EFI capsules.
+
+The following are the command-line options to be provided
+to the tool
+Usage: mkeficapsule [options]
+Options:
+ -g, --guid guid for image blob type
+ -i, --index update image index
+ -I, --instanceupdate hardware instance
+ -v, --fw-version firmware version
+ -p, --private-key private key file
+ -c, --certificate signer's certificate file
+ -m, --monotonic-count monotonic count
+ -d, --dump_sig dump signature (*.p7)
+ -A, --fw-accept firmware accept capsule, requires GUID, no image blob
+ -R, --fw-revert firmware revert capsule, takes no GUID, no image blob
+ -o, --capoemflag Capsule OEM Flag, an integer between 0x and 0x
+ -f, --cfg-file config file with capsule parameters
+ -h, --help print a help message
+
+"""
+
+from binman import bintool
+
+class Bintoolmkeficapsule(bintool.Bintool):
+"""Handles the 'mkeficapsule' tool
+
+This bintool is used for generating the EFI capsules. The
+capsule generation parameters can either be specified through
+command-line, or through a config file.
+
+"""
+def __init__(self, name):
+super().__init__(name, 'mkeficapsule tool for generating capsules')
+
+def capsule_cfg_file(self, cfg_file):
+"""Generate a capsule reading parameters from config file
+
+Args:
+cfg_file (str): Path to the config file
+
+Returns:
+str: Tool output
+"""
+
+args = [
+f'--cfg-file={cfg_file}'
+]
+return self.run_cmd(*args)
+
+def cmdline_capsule(self, image_index, image_guid, hardware_instance,
+payload, output_fname, version=0):
+"""
[PATCH v4 05/12] tools: mkeficapsule: Add support for parsing capsule params from config file
Add support for specifying the parameters needed for capsule
generation through a config file, instead of passing them through
command-line. Parameters for more than a single capsule file can be
specified, resulting in generation of multiple capsules through a
single invocation of the command.
This path is to be used for generating capsules through a make target,
with the parameters being parsed from the config file.
Signed-off-by: Sughosh Ganu
---
Changes since V3:
* Add support for firmware versioning, needed after rebasing on
current master.
tools/Kconfig | 16 ++
tools/Makefile | 1 +
tools/eficapsule.h | 115
tools/mkeficapsule.c | 87 +
tools/mkeficapsule_parse.c | 352 +
5 files changed, 540 insertions(+), 31 deletions(-)
create mode 100644 tools/mkeficapsule_parse.c
diff --git a/tools/Kconfig b/tools/Kconfig
index 6e23f44d55..88ea3567d0 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -98,6 +98,22 @@ config TOOLS_MKEFICAPSULE
optionally sign that file. If you want to enable UEFI capsule
update feature on your target, you certainly need this.
+config EFI_CAPSULE_CFG_FILE
+ string "Path to the EFI Capsule Config File"
+ default ""
+ help
+ Path to the EFI capsule config file which provides the
+ parameters needed to build capsule(s). Parameters can be
+ provided for multiple payloads resulting in corresponding
+ capsule images being generated.
+
+config EFI_USE_CAPSULE_CFG_FILE
+ bool "Use the config file for generating capsules"
+ help
+ Boolean option used to specify if the EFI capsules are to
+ be generated through parameters specified via the config
+ file or through command line.
+
menuconfig FSPI_CONF_HEADER
bool "FlexSPI Header Configuration"
help
diff --git a/tools/Makefile b/tools/Makefile
index 3d0c4b0dd6..eb129e3bb2 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
HOSTLDLIBS_mkeficapsule += \
$(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
+mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
mkfwumdata-objs := mkfwumdata.o generated/lib/crc32.o
HOSTLDLIBS_mkfwumdata += -luuid
diff --git a/tools/eficapsule.h b/tools/eficapsule.h
index 2099a2e9b8..d455ac1d6f 100644
--- a/tools/eficapsule.h
+++ b/tools/eficapsule.h
@@ -52,6 +52,12 @@ typedef struct {
/* flags */
#define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
+enum capsule_type {
+ CAPSULE_NORMAL_BLOB = 0,
+ CAPSULE_ACCEPT,
+ CAPSULE_REVERT,
+};
+
struct efi_capsule_header {
efi_guid_t capsule_guid;
uint32_t header_size;
@@ -113,6 +119,7 @@ struct efi_firmware_image_authentication {
struct win_certificate_uefi_guid auth_info;
} __packed;
+
/* fmp payload header */
#define SIGNATURE_16(A, B) ((A) | ((B) << 8))
#define SIGNATURE_32(A, B, C, D) \
@@ -143,4 +150,112 @@ struct fmp_payload_header_params {
uint32_t fw_version;
};
+/**
+ * struct efi_capsule_params - Capsule parameters
+ * @image_guid: Guid value of the payload input image
+ * @image_index: Image index value
+ * @hardware_instance: Hardware instance to be used for the image
+ * @fmp: FMP payload header used for storing firmware version
+ * @monotonic_count: Monotonic count value to be used for signed capsule
+ * @privkey_file: Path to private key used in capsule signing
+ * @cert_file: Path to public key certificate used in capsule signing
+ * @input_file: Path to payload input image
+ * @capsule_file: Path to the output capsule file
+ * @oemflags: Oemflags to be populated in the capsule header
+ * @capsule: Capsule Type, normal or accept or revert
+ */
+struct efi_capsule_params {
+ efi_guid_t *image_guid;
+ unsigned long image_index;
+ unsigned long hardware_instance;
+ struct fmp_payload_header_params fmp;
+ uint64_t monotonic_count;
+ char *privkey_file;
+ char *cert_file;
+ char *input_file;
+ char *capsule_file;
+ unsigned long oemflags;
+ enum capsule_type capsule;
+};
+
+/**
+ * capsule_with_cfg_file() - Generate capsule from config file
+ * @cfg_file: Path to the config file
+ *
+ * Parse the capsule parameters from the config file and use the
+ * parameters for generating one or more capsules.
+ *
+ * Return: None
+ *
+ */
+void capsule_with_cfg_file(const char *cfg_file);
+
+/**
+ * convert_uuid_to_guid() - convert UUID to GUID
+ * @buf: UUID binary
+ *
+ * UUID and GUID have the same data structure, but their binary
+ * formats are different due to the endianness. See lib/uuid.c.
+ * Since uuid_parse() can handle only UUID, this function must
+ * be called to get correct data for GUID when
[PATCH v4 04/12] doc: capsule: Document the new mechanism to embed ESL file into dtb
Update the document to specify how the EFI Signature List(ESL) file
can be embedded into the platform's dtb as part of the u-boot build.
Signed-off-by: Sughosh Ganu
Reviewed-by: Simon Glass
---
Changes since V3: None
doc/develop/uefi/uefi.rst | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 6626ceec52..3d07aa33b8 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -522,20 +522,16 @@ and used by the steps highlighted below.
...
}
-You can do step-4 manually with
+You can perform step-4 by defining the Kconfig symbol
+CONFIG_EFI_CAPSULE_ESL_FILE. Once this has been done, the signature
+node can be added to the u-boot.dtsi file. For reference, check the
+u-boot.dtsi file for the sandbox architecture. If this node has not
+been added to the architecture's u-boot.dtsi file, this needs to be
+done. The node has currently been added for the sandbox and arm
+architectures' in the u-boot.dtsi file. Once the u-boot.dtsi file has
+been added with the signature node, the esl file will automatically
+get embedded into the platform's dtb as part of u-boot build.
-.. code-block:: console
-
-$ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
-$ fdtoverlay -i orig.dtb -o new.dtb -v signature.dtbo
-
-where signature.dts looks like::
-
-&{/} {
-signature {
-capsule-key = /incbin/("CRT.esl");
-};
-};
Anti-rollback Protection
--
2.34.1
[PATCH v4 03/12] capsule: authenticate: Add capsule public key in platform's dtb
The EFI capsule authentication logic in u-boot expects the public key
in the form of an EFI Signature List(ESL) to be provided as part of
the platform's dtb. Currently, the embedding of the ESL file into the
dtb needs to be done manually.
Add a signature node in the u-boot dtsi file and include the public
key through the capsule-key property. This file is per architecture,
and is currently being added for sandbox and arm architectures. It
will have to be added for other architectures which need to enable
capsule authentication support.
The path to the ESL file is specified through the
CONFIG_EFI_CAPSULE_ESL_FILE symbol.
Signed-off-by: Sughosh Ganu
---
Changes since V3:
* Put the two ifdef statements together in arm architecture's
u-boot.dtsi file.
* Remove the extra blank line in the Kconfig.
arch/arm/dts/u-boot.dtsi | 17 +
arch/sandbox/dts/u-boot.dtsi | 17 +
lib/efi_loader/Kconfig | 10 ++
lib/efi_loader/Makefile | 7 +++
4 files changed, 51 insertions(+)
create mode 100644 arch/arm/dts/u-boot.dtsi
create mode 100644 arch/sandbox/dts/u-boot.dtsi
diff --git a/arch/arm/dts/u-boot.dtsi b/arch/arm/dts/u-boot.dtsi
new file mode 100644
index 00..2a9359c43c
--- /dev/null
+++ b/arch/arm/dts/u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Devicetree file with miscellaneous nodes that will be included
+ * at build time into the DTB. Currently being used for including
+ * capsule related information.
+ *
+ */
+
+#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
+#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
+/ {
+ signature {
+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
+ };
+};
+#endif /* CONFIG_EFI_CAPSULE_AUTHENTICATE */
+#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
new file mode 100644
index 00..60bd004937
--- /dev/null
+++ b/arch/sandbox/dts/u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Devicetree file with miscellaneous nodes that will be included
+ * at build time into the DTB. Currently being used for including
+ * capsule related information.
+ *
+ */
+
+#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
+/ {
+#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
+ signature {
+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
+ };
+#endif
+};
+#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index a22e47616f..9abb9a4db3 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -235,6 +235,16 @@ config EFI_CAPSULE_MAX
Select the max capsule index value used for capsule report
variables. This value is used to create CapsuleMax variable.
+config EFI_CAPSULE_ESL_FILE
+ string "Path to the EFI Signature List File"
+ default ""
+ depends on EFI_CAPSULE_AUTHENTICATE
+ help
+ Provides the absolute path to the EFI Signature List
+ file which will be embedded in the platform's device
+ tree and used for capsule authentication at the time
+ of capsule update.
+
config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 1a8c8d7cab..c52c9d27bd 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -89,3 +89,10 @@ obj-$(CONFIG_EFI_ECPT) += efi_conformance.o
EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
$(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
+
+ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
+EFI_CAPSULE_KEY_PATH := $(subst $\",,$(CONFIG_EFI_CAPSULE_ESL_FILE))
+ifeq ("$(wildcard $(EFI_CAPSULE_KEY_PATH))","")
+$(error .esl cerificate not found. Configure your CONFIG_EFI_CAPSULE_ESL_FILE)
+endif
+endif
--
2.34.1
[PATCH v4 02/12] nuvoton: npcm845-evb: Add a newline at the end of file
Add a newline at the end of the dts, without which the build fails when including the u-boot.dtsi file. Signed-off-by: Sughosh Ganu Reviewed-by: Simon Glass --- Changes since V3: None arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/nuvoton-npcm845-evb.dts b/arch/arm/dts/nuvoton-npcm845-evb.dts index 3cab7807e3..a93666cb41 100644 --- a/arch/arm/dts/nuvoton-npcm845-evb.dts +++ b/arch/arm/dts/nuvoton-npcm845-evb.dts @@ -354,4 +354,4 @@ _pins _pins >; -}; \ No newline at end of file +}; -- 2.34.1
[PATCH v4 01/12] binman: bintool: Build a tool from a list of commands
Add support to build a tool from source with a list of commands. This
is useful when a tool can be built with multiple commands instead of a
single command.
Signed-off-by: Sughosh Ganu
---
Changes since V3:
* New patch to support passing multiple commands to the build_from_git
function to build the tool.
tools/binman/bintool.py| 19 +++
tools/binman/btool/_testing.py | 3 ++-
tools/binman/btool/fiptool.py | 4 +++-
tools/binman/btool/futility.py | 4 +++-
4 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
index 81629683df..279bf2fec4 100644
--- a/tools/binman/bintool.py
+++ b/tools/binman/bintool.py
@@ -328,7 +328,7 @@ class Bintool:
return result.stdout
@classmethod
-def build_from_git(cls, git_repo, make_target, bintool_path, flags=None):
+def build_from_git(cls, git_repo, make_targets, bintool_path, flags=None):
"""Build a bintool from a git repo
This clones the repo in a temporary directory, builds it with 'make',
@@ -336,7 +336,8 @@ class Bintool:
Args:
git_repo (str): URL of git repo
-make_target (str): Target to pass to 'make' to build the tool
+make_targets (list of str): List of targets to pass to 'make' to
build
+the tool
bintool_path (str): Relative path of the tool in the repo, after
build is complete
flags (list of str): Flags or variables to pass to make, or None
@@ -350,12 +351,14 @@ class Bintool:
tmpdir = tempfile.mkdtemp(prefix='binmanf.')
print(f"- clone git repo '{git_repo}' to '{tmpdir}'")
tools.run('git', 'clone', '--depth', '1', git_repo, tmpdir)
-print(f"- build target '{make_target}'")
-cmd = ['make', '-C', tmpdir, '-j', f'{multiprocessing.cpu_count()}',
- make_target]
-if flags:
-cmd += flags
-tools.run(*cmd)
+for target in make_targets:
+print(f"- build target '{target}'")
+cmd = ['make', '-C', tmpdir, '-j',
f'{multiprocessing.cpu_count()}',
+ target]
+if flags:
+cmd += flags
+tools.run(*cmd)
+
fname = os.path.join(tmpdir, bintool_path)
if not os.path.exists(fname):
print(f"- File '{fname}' was not produced")
diff --git a/tools/binman/btool/_testing.py b/tools/binman/btool/_testing.py
index 4005e8a8a5..c0109c76bf 100644
--- a/tools/binman/btool/_testing.py
+++ b/tools/binman/btool/_testing.py
@@ -32,5 +32,6 @@ class Bintool_testing(bintool.Bintool):
return self.apt_install('package')
return self.fetch_from_drive('junk')
if method == bintool.FETCH_BUILD:
-return self.build_from_git('url', 'target', 'pathname')
+cmd = ['target']
+return self.build_from_git('url', cmd, 'pathname')
return None
diff --git a/tools/binman/btool/fiptool.py b/tools/binman/btool/fiptool.py
index c80f8275c4..b275fee43b 100644
--- a/tools/binman/btool/fiptool.py
+++ b/tools/binman/btool/fiptool.py
@@ -107,8 +107,10 @@ class Bintoolfiptool(bintool.Bintool):
"""
if method != bintool.FETCH_BUILD:
return None
+
+cmd = ['fiptool']
result = self.build_from_git(
'https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git',
-'fiptool',
+cmd,
'tools/fiptool/fiptool')
return result
diff --git a/tools/binman/btool/futility.py b/tools/binman/btool/futility.py
index 04c9aefe9b..4b22547368 100644
--- a/tools/binman/btool/futility.py
+++ b/tools/binman/btool/futility.py
@@ -168,9 +168,11 @@ class Bintoolfutility(bintool.Bintool):
#
# Unfortunately this requires logging in and obtaining a line for the
# .gitcookies file. So use a mirror instead.
+
+cmd = ['all']
result = self.build_from_git(
'https://github.com/sjg20/vboot_reference.git',
-'all',
+cmd,
'build/futility/futility',
flags=['USE_FLASHROM=0'])
return result
--
2.34.1
[PATCH v4 00/12] Integrate EFI capsule tasks into u-boot's build flow
This patchset aims to bring two capsule related tasks under the u-boot build flow. One is the embedding of the public key into the platform's dtb. The public key is in the form of an EFI Signature List(ESL) file and is used for capsule authentication. This is being achieved by adding the signature node containing the capsule public key in the architecture's u-boot.dtsi file. Currently, the u-boot.dtsi file has been added for the sandbox and arm architectures. The path to the ESL file is being provided through a Kconfig symbol(CONFIG_EFI_CAPSULE_ESL_FILE). Changes have also been made to the test flow so that the keys used for signing the capsule, and the ESL file, are generated prior to invoking the u-boot's build, which enables embedding the ESL file into the dtb as part of the u-boot build. The other task is related to generation of capsules. Support is being added to generate capsules by specifying the capsule parameters in a config file. Calling the mkeficapsule tool then results in generation of the corresponding capsule files. The capsules can be generated as part of u-boot build, and this is being achieved through binman, by adding a capsule entry type. The capsules can be generated either by specifying the capsule parameters in a config file, or through specifying them as properties under the capsule entry node. If using the config file, the path to the config file is to be specified through a Kconfig symbol(CONFIG_EFI_CAPSULE_CFG_FILE). Changes have also been made to the efi capsule update feature testing setup on the sandbox variants. Currently, the capsule files and the public key ESL file are generated after u-boot has been built. This logic has been changed so that the capsule input files along with the keys needed for capsule signing and authentication are generated prior to initiation of the u-boot build. The placement of all the files needed for generation of capsules, along with the generated capsule files is under the /tmp/capsules/ directory. Currently, the capsule update feature is tested on the sandbox and sandbox_flattree variants in CI. The capsule generation through config file is enabled for the sandbox variant, with the sandbox_flattree variant generating capsules through the command-line parameters. The document has been updated to reflect the above changes. Changes since V3: * New patch to support passing multiple commands to the build_from_git * Put the two ifdef statements together in arm architecture's u-boot.dtsi file. * Remove the extra blank line in the Kconfig. function to build the tool. * Add support for firmware versioning, needed after rebasing on current master. * Add test cases for covering the various capsule generation scenarios. * Add function comments in the mkeficapsule bintool. * Fix the fetch method of the mkeficapsule bintool to enable building the tool. * Add more details about the capsule parameters in the documentation as well as the code. * Fix order of module imports, and addition of blank lines in the capsule.py file. * Use SetContents in the ObtainContents method. * Move the paragraph on version support under a separate subsection. * Move the description on generating capsules through config file under the section to describe capsule generation. * Add a subsection highlighting generation of capsules through binman. * Remove whitespace in the command to generate capsule keys. * Use fstrings for format specifiers. * Rebase on top of current master to work with test configuration for version support in capsule updates. * Use fstrings for format specifiers. * Add entries for generating capsules with version parameter. * Use blob nodes instead of incbin for including the binaries in FIT image. * Enable generation of capsules with versioning support. Sughosh Ganu (12): binman: bintool: Build a tool from a list of commands nuvoton: npcm845-evb: Add a newline at the end of file capsule: authenticate: Add capsule public key in platform's dtb doc: capsule: Document the new mechanism to embed ESL file into dtb tools: mkeficapsule: Add support for parsing capsule params from config file binman: capsule: Add support for generating capsules doc: Add documentation to highlight capsule generation related updates CI: capsule: Setup the files needed for capsule update testing test: py: Setup capsule files for testing test: capsule: Remove public key embed logic from capsule update test sandbox: capsule: Add a config file for generating capsules sandbox: capsule: Generate capsule related files through binman .azure-pipelines.yml | 26 ++ .gitlab-ci.yml| 24 ++ arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +- arch/arm/dts/u-boot.dtsi | 17 + arch/sandbox/dts/u-boot.dtsi | 282 ++ configs/sandbox_defconfig | 3 + configs/sandbox_flattree_defconfig| 1
Re: [PATCH v2 5/8] tools: mkeficapsule: Add support for parsing capsule params from config file
On Fri, 14 Jul 2023 at 16:14, Michal Simek wrote: > > > > On 6/24/23 15:41, Sughosh Ganu wrote: > > Add support for specifying the parameters needed for capsule > > generation through a config file, instead of passing them through > > command-line. Parameters for more than a single capsule file can be > > specified, resulting in generation of multiple capsules through a > > single invocation of the command. > > > > This path is to be used for generating capsules through a make target, > > with the parameters being parsed from the config file. > > > > Can you please also add support for adding comment to config file? > Pretty much just ignore lines which starts with /* or so. Comments are currently supported with the '#' character, so that lines starting with # are considered as comments. -sughosh
Re: [PATCH v3 11/11] sandbox: capsule: Generate capsule related files through binman
hi Simon,
On Tue, 11 Jul 2023 at 03:09, Simon Glass wrote:
>
> Hi,
>
> On Sun, 9 Jul 2023 at 07:34, Sughosh Ganu wrote:
> >
> > The EFI capsule files can now be generated as part of u-boot
> > build. This is done through binman. Add capsule entry nodes in the
> > u-boot.dtsi for the sandbox architecture for generating the
> > capsules. Remove the corresponding generation of capsules from the
> > capsule update conftest file.
> >
> > The capsules are generated through the config file for the sandbox
> > variant, and through explicit parameters for the sandbox_flattree
> > variant.
> >
> > Also generate the FIT image used for testing the capsule update
> > feature on the sandbox_flattree variant through binman. Remove the now
> > superfluous its file which was used for generating this FIT image.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V2:
> > * New patch for generating the capsules and capsule input files
> > through binman.
> >
> > arch/sandbox/dts/u-boot.dtsi | 143 ++
> > test/py/tests/test_efi_capsule/conftest.py| 62
> > .../tests/test_efi_capsule/uboot_bin_env.its | 36 -
> > 3 files changed, 143 insertions(+), 98 deletions(-)
> > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> >
> > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > index 60bd004937..292fb86a50 100644
> > --- a/arch/sandbox/dts/u-boot.dtsi
> > +++ b/arch/sandbox/dts/u-boot.dtsi
> > @@ -13,5 +13,148 @@
> > capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > };
> > #endif
> > +
> > + binman: binman {
> > + multiple-images;
> > + };
> > +};
> > +
> > + {
> > + itb {
> > + filename = "/tmp/capsules/uboot_bin_env.itb";
>
> You can't really do this, since that dir may not exist. Can you drop the path?
This directory does exist. I am adding logic to add the directory in
patches 7 and 8 to ensure that the /tmp/capsules/ directory exists for
the capsule updates testing, both for CI runs as well as local pytest
test runs.
>
> > +
> > + fit {
> > + description = "Automatic U-Boot environment update";
> > + #address-cells = <2>;
> > +
> > + images {
> > + u-boot-bin {
> > + description = "U-Boot binary on SPI
> > Flash";
> > + data =
> > /incbin/("/tmp/capsules/u-boot.bin.new");
>
> See FIT docs for how to include data in a FIT with binman.
>
> Basically you add it below *
Okay. WIll change this.
>
> > + compression = "none";
> > + type = "firmware";
> > + arch = "sandbox";
> > + load = <0>;
> > + hash-1 {
> > + algo = "sha1";
> > + };
>
> *
>blob {
> filename = "u-boot.bin.new";
>}
>
> Please fix throughout.
>
> > + };
> > + u-boot-env {
> > + description = "U-Boot environment
> > on SPI Flash";
> > + data =
> > /incbin/("/tmp/capsules/u-boot.env.new");
> > + compression = "none";
> > + type = "firmware";
> > + arch = "sandbox";
> > + load = <0>;
> > + hash-1 {
> > + algo = "sha1";
> > + };
> > + };
> > + };
> > + };
> > + };
> > +
> > +#ifdef CONFIG_EFI_USE_CAPSULE_CFG_FILE
> > + capsule1 {
> > + capsule {
> > + cfg-file = CONFIG_EFI_CAPSULE_CFG_FILE;
> > + };
> > + };
> > +#else
> &
Re: [PATCH v3 10/11] sandbox: capsule: Add a config file for generating capsules
hi Simon,
On Tue, 11 Jul 2023 at 03:08, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Sun, 9 Jul 2023 at 07:34, Sughosh Ganu wrote:
> >
> > Support has been added to the mkeficapsule tool to generate capsules
> > by parsing the capsule parameters through a config file. Add a config
> > file for generating capsules. These capsules will be used for testing
> > the capsule update feature on sandbox platform.
> >
> > Enable generation of capsules through the config file on the sandbox
> > variant.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V2:
> > * New patch to add the capsule generation config file for sandbox.
> >
> > .azure-pipelines.yml | 1 +
> > .gitlab-ci.yml| 1 +
> > configs/sandbox_defconfig | 2 +
> > test/py/conftest.py | 5 ++
> > .../test_efi_capsule/sandbox_capsule_cfg.txt | 75 +++
> > 5 files changed, 84 insertions(+)
> > create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> >
> > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > index 75075bbd07..cc196bf98c 100644
> > --- a/.azure-pipelines.yml
> > +++ b/.azure-pipelines.yml
> > @@ -403,6 +403,7 @@ stages:
> >echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> >echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> >echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > + cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> > /tmp/capsules/;
> >if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
> > "sandbox_flattree" ]]; then
> >openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out
> > /tmp/capsules/SIGNER.crt -nodes -days 365;
> >openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
> > /tmp/capsules/SIGNER2.crt -nodes -days 365;
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index 577eebd678..614bf61962 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -42,6 +42,7 @@ stages:
> > - echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> > - echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> > - echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > +- cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> > /tmp/capsules/;
> > - if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
> > "sandbox_flattree" ]]; then
> > openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days
> > 365;
> > openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes
> > -days 365;
> > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> > index d8a2386bb0..0f4c59e1a8 100644
> > --- a/configs/sandbox_defconfig
> > +++ b/configs/sandbox_defconfig
> > @@ -340,6 +340,8 @@ CONFIG_EFI_CAPSULE_ON_DISK=y
> > CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> > CONFIG_EFI_CAPSULE_AUTHENTICATE=y
> > CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
> > +CONFIG_EFI_CAPSULE_CFG_FILE="/tmp/capsules/sandbox_capsule_cfg.txt"
> > +CONFIG_EFI_USE_CAPSULE_CFG_FILE=y
> > CONFIG_EFI_SECURE_BOOT=y
> > CONFIG_TEST_FDTDEC=y
> > CONFIG_UNIT_TEST=y
> > diff --git a/test/py/conftest.py b/test/py/conftest.py
> > index 661ed74fae..f32ab1a70c 100644
> > --- a/test/py/conftest.py
> > +++ b/test/py/conftest.py
> > @@ -161,6 +161,11 @@ def setup_capsule_build(source_dir, build_dir,
> > board_type, log):
> > )
> > run_command(name, cmd, source_dir)
> >
> > +capsule_cfg_file =
> > 'test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt'
> > +name = 'cp'
> > +cmd = ( ' cp %s %s' % (capsule_cfg_file, capsule_sig_dir))
>
> I forgot to mention this before, but you should use f strings:
>
> cmd = f'cp {capsule_cfg_file} ...'
Will do.
>
> Please check the other files too, as it is a pain to clean it up
> later. You can run 'pylint' on your source to check it.
Do the pylint checks not run as pa
Re: [PATCH v3 06/11] binman: capsule: Add support for generating capsules
hi Simon,
On Tue, 11 Jul 2023 at 03:08, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Sun, 9 Jul 2023 at 07:34, Sughosh Ganu wrote:
> >
> > Add support in binman for generating capsules. The capsule parameters
> > can be specified either through a config file or through the capsule
> > binman entry.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V2:
> > * New patch which generates capsules through binman replacing the
> > earlier make target.
> >
> > tools/binman/btool/mkeficapsule.py | 91 +
> > tools/binman/entries.rst | 27
> > tools/binman/etype/capsule.py | 102 +
> > 3 files changed, 220 insertions(+)
> > create mode 100644 tools/binman/btool/mkeficapsule.py
> > create mode 100644 tools/binman/etype/capsule.py
>
> Please do check test coverage (binman test -T). You are missing quite
> a lot in two two files you have added.
I was aware of adding tests in binman, but since the capsules
generated through binman are getting tested in the capsule update
functionality, I thought this would be superfluous. If this is
mandatory, I will add the tests. Will also address the rest of your
comments for this patch.
-sughosh
>
> >
> > diff --git a/tools/binman/btool/mkeficapsule.py
> > b/tools/binman/btool/mkeficapsule.py
> > new file mode 100644
> > index 00..9f656c12cf
> > --- /dev/null
> > +++ b/tools/binman/btool/mkeficapsule.py
> > @@ -0,0 +1,91 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +# Copyright 2023 Linaro Limited
> > +#
> > +"""Bintool implementation for mkeficapsule tool
> > +
> > +mkeficapsule is a tool used for generating EFI capsules.
> > +
> > +The following are the command-line options to be provided
> > +to the tool
> > +Usage: mkeficapsule [options]
> > +Options:
> > + -g, --guid guid for image blob type
> > + -i, --index update image index
> > + -I, --instanceupdate hardware instance
> > + -p, --private-key private key file
> > + -c, --certificate signer's certificate file
> > + -m, --monotonic-count monotonic count
> > + -d, --dump_sig dump signature (*.p7)
> > + -A, --fw-accept firmware accept capsule, requires GUID, no image
> > blob
> > + -R, --fw-revert firmware revert capsule, takes no GUID, no image
> > blob
> > + -o, --capoemflag Capsule OEM Flag, an integer between 0x and
> > 0x
> > + -f, --cfg-file config file with capsule parameters
> > + -h, --help print a help message
> > +
> > +"""
> > +
> > +from binman import bintool
> > +
> > +class Bintoolmkeficapsule(bintool.Bintool):
> > +"""Handles the 'mkeficapsule' tool
> > +
> > +This bintool is used for generating the EFI capsules. The
> > +capsule generation parameters can either be specified through
> > +command-line, or through a config file.
> > +
> > +"""
> > +def __init__(self, name):
> > +super().__init__(name, 'mkeficapsule tool for generating capsules')
> > +
> > +def capsule_cfg_file(self, cfg_file):
>
> """Function comment
>
> Args:
>cfg_file (str): ...
> """
>
> Please fix throughout
>
> > +
> > +args = [
> > +f'--cfg-file={cfg_file}'
> > +]
> > +self.run_cmd(*args)
> > +
> > +def cmdline_capsule(self, image_index, image_guid, hardware_instance,
> > +payload, output_fname):
> > +
> > +args = [
> > +f'--index={image_index}',
> > +f'--guid={image_guid}',
> > +f'--instance={hardware_instance}',
> > +payload,
> > +output_fname
> > +]
> > +self.run_cmd(*args)
> > +
> > +def cmdline_auth_capsule(self, image_index, image_guid,
> > hardware_instance,
> > + monotonic_count, priv_key, pub_key,
> > + payload, output_fname):
> > +
> > +args = [
> > +f'--index={image_index}',
> > +f'--guid={image_guid}',
> > +f'--instance={hardware_instance}',
> > +f'--monotonic-count={monotonic_count}',
> > +f'--private-key={priv_key}',
> > +f'--certi
Re: [PATCH v3 02/11] capsule: authenticate: Add capsule public key in platform's dtb
hi Heinrich,
On Sun, 9 Jul 2023 at 19:22, Heinrich Schuchardt wrote:
>
>
>
> Am 9. Juli 2023 15:33:17 MESZ schrieb Sughosh Ganu :
> >The EFI capsule authentication logic in u-boot expects the public key
> >in the form of an EFI Signature List(ESL) to be provided as part of
> >the platform's dtb. Currently, the embedding of the ESL file into the
> >dtb needs to be done manually.
> >
> >Add a signature node in the u-boot dtsi file and include the public
> >key through the capsule-key property. This file is per architecture,
> >and is currently being added for sandbox and arm architectures. It
>
> The device-tree compiler can pick up files from /include/. If the dtsi file
> is not architecture specific, we should avoid code duplication.
The idea here was to have the dtsi file get included automatically
during build, and that happens only when the dtsi file, with a
specific name, is in the same directory as the dts being built. The
include directory is just a location where files would be searched for
when building, but the corresponding dtsi file will have to be
explicitly included in the dts being built. So this would mean every
board dts file needing to include the capsule dtsi file, instead of
automatic inclusion. I believe putting this dtsi file in the dts
directory of an architecture which is using capsule updates is easier
than including it in every board's dts.
The initial implementation was generating the signature node in a dtbo
on the fly, and including it into the corresponding dtb as it was
built. This is the approach that was taken in v1 [1], but Simon did
not like it, and Jonas suggested this approach [2].
-sughosh
[1] - https://lists.denx.de/pipermail/u-boot/2023-June/520121.html
[2] - https://lists.denx.de/pipermail/u-boot/2023-June/521195.html
>
> We should treat all EFI architectures the same.
>
> Best regards
>
> Heinrich
>
> >will have to be added for other architectures which need to enable
> >capsule authentication support.
> >
> >The path to the ESL file is specified through the
> >CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> >
> >Signed-off-by: Sughosh Ganu
> >---
> >Changes since V2:
> >* Add the public key ESL file through the u-boot.dtsi.
> >* Add the dtsi files for sandbox and arm architectures.
> >* Add a check in the Makefile that the ESL file path is not empty.
> >
> > arch/arm/dts/u-boot.dtsi | 17 +
> > arch/sandbox/dts/u-boot.dtsi | 17 +
> > lib/efi_loader/Kconfig | 11 +++
> > lib/efi_loader/Makefile | 7 +++
> > 4 files changed, 52 insertions(+)
> > create mode 100644 arch/arm/dts/u-boot.dtsi
> > create mode 100644 arch/sandbox/dts/u-boot.dtsi
> >
> >diff --git a/arch/arm/dts/u-boot.dtsi b/arch/arm/dts/u-boot.dtsi
> >new file mode 100644
> >index 00..60bd004937
> >--- /dev/null
> >+++ b/arch/arm/dts/u-boot.dtsi
> >@@ -0,0 +1,17 @@
> >+// SPDX-License-Identifier: GPL-2.0+
> >+/*
> >+ * Devicetree file with miscellaneous nodes that will be included
> >+ * at build time into the DTB. Currently being used for including
> >+ * capsule related information.
> >+ *
> >+ */
> >+
> >+#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
> >+/ {
> >+#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> >+ signature {
> >+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> >+ };
> >+#endif
> >+};
> >+#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
> >diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> >new file mode 100644
> >index 00..60bd004937
> >--- /dev/null
> >+++ b/arch/sandbox/dts/u-boot.dtsi
> >@@ -0,0 +1,17 @@
> >+// SPDX-License-Identifier: GPL-2.0+
> >+/*
> >+ * Devicetree file with miscellaneous nodes that will be included
> >+ * at build time into the DTB. Currently being used for including
> >+ * capsule related information.
> >+ *
> >+ */
> >+
> >+#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
> >+/ {
> >+#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> >+ signature {
> >+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> >+ };
> >+#endif
> >+};
> >+#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
> >diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> >index c5835e6ef6..1326a1d109 100644
> >--- a/lib/efi_loader/Kconfig
> >+++ b/lib/efi_loader/Kconfig
> >@@ -234,6 +234,17 @@ config EFI_CAPSULE_MAX
> > Select the max capsule index value used for capsule report
> > variables. This value is used to create CapsuleMax varia
[PATCH v3 11/11] sandbox: capsule: Generate capsule related files through binman
The EFI capsule files can now be generated as part of u-boot
build. This is done through binman. Add capsule entry nodes in the
u-boot.dtsi for the sandbox architecture for generating the
capsules. Remove the corresponding generation of capsules from the
capsule update conftest file.
The capsules are generated through the config file for the sandbox
variant, and through explicit parameters for the sandbox_flattree
variant.
Also generate the FIT image used for testing the capsule update
feature on the sandbox_flattree variant through binman. Remove the now
superfluous its file which was used for generating this FIT image.
Signed-off-by: Sughosh Ganu
---
Changes since V2:
* New patch for generating the capsules and capsule input files
through binman.
arch/sandbox/dts/u-boot.dtsi | 143 ++
test/py/tests/test_efi_capsule/conftest.py| 62
.../tests/test_efi_capsule/uboot_bin_env.its | 36 -
3 files changed, 143 insertions(+), 98 deletions(-)
delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
index 60bd004937..292fb86a50 100644
--- a/arch/sandbox/dts/u-boot.dtsi
+++ b/arch/sandbox/dts/u-boot.dtsi
@@ -13,5 +13,148 @@
capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
};
#endif
+
+ binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ itb {
+ filename = "/tmp/capsules/uboot_bin_env.itb";
+
+ fit {
+ description = "Automatic U-Boot environment update";
+ #address-cells = <2>;
+
+ images {
+ u-boot-bin {
+ description = "U-Boot binary on SPI
Flash";
+ data =
/incbin/("/tmp/capsules/u-boot.bin.new");
+ compression = "none";
+ type = "firmware";
+ arch = "sandbox";
+ load = <0>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ u-boot-env {
+ description = "U-Boot environment on
SPI Flash";
+ data =
/incbin/("/tmp/capsules/u-boot.env.new");
+ compression = "none";
+ type = "firmware";
+ arch = "sandbox";
+ load = <0>;
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ };
+ };
+ };
+
+#ifdef CONFIG_EFI_USE_CAPSULE_CFG_FILE
+ capsule1 {
+ capsule {
+ cfg-file = CONFIG_EFI_CAPSULE_CFG_FILE;
+ };
+ };
+#else
+ capsule2 {
+ capsule {
+ image-index = <0x1>;
+ image-type-id = "09D7CF52-0720-4710-91D1-08469B7FE9C8";
+ filename = "/tmp/capsules/u-boot.bin.new";
+ capsule = "/tmp/capsules/Test01";
+ };
+ };
+
+ capsule3 {
+ capsule {
+ image-index = <0x2>;
+ image-type-id = "5A7021F5-FEF2-48B4-AABA-832E777418C0";
+ filename = "/tmp/capsules/u-boot.env.new";
+ capsule = "/tmp/capsules/Test02";
+ };
+ };
+
+ capsule4 {
+ capsule {
+ image-index = <0x1>;
+ image-type-id = "058B7D83-50D5-4C47-A195-60D86AD341C4";
+ filename = "/tmp/capsules/u-boot.bin.new";
+ capsule = "/tmp/capsules/Test03";
+ };
+ };
+
+ capsule5 {
+ capsule {
+ image-index = <0x1>;
+ image-type-id = "3673B45D-6A7C-46F3-9E60-ADABB03F7937";
+ filename = "/tmp/capsules/uboot_bin_env.itb";
+ capsule = "/tmp/capsules/Test04";
+ };
+ };
+
+ capsule6 {
+ capsule {
+ image-index = <0x1>;
+ image-type-id = "
[PATCH v3 10/11] sandbox: capsule: Add a config file for generating capsules
Support has been added to the mkeficapsule tool to generate capsules
by parsing the capsule parameters through a config file. Add a config
file for generating capsules. These capsules will be used for testing
the capsule update feature on sandbox platform.
Enable generation of capsules through the config file on the sandbox
variant.
Signed-off-by: Sughosh Ganu
---
Changes since V2:
* New patch to add the capsule generation config file for sandbox.
.azure-pipelines.yml | 1 +
.gitlab-ci.yml| 1 +
configs/sandbox_defconfig | 2 +
test/py/conftest.py | 5 ++
.../test_efi_capsule/sandbox_capsule_cfg.txt | 75 +++
5 files changed, 84 insertions(+)
create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 75075bbd07..cc196bf98c 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -403,6 +403,7 @@ stages:
echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+ cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
/tmp/capsules/;
if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
"sandbox_flattree" ]]; then
openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt
-nodes -days 365;
openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
/tmp/capsules/SIGNER2.crt -nodes -days 365;
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 577eebd678..614bf61962 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -42,6 +42,7 @@ stages:
- echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
- echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
- echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+- cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt /tmp/capsules/;
- if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
"sandbox_flattree" ]]; then
openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days 365;
openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes -days
365;
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index d8a2386bb0..0f4c59e1a8 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -340,6 +340,8 @@ CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
+CONFIG_EFI_CAPSULE_CFG_FILE="/tmp/capsules/sandbox_capsule_cfg.txt"
+CONFIG_EFI_USE_CAPSULE_CFG_FILE=y
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/test/py/conftest.py b/test/py/conftest.py
index 661ed74fae..f32ab1a70c 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -161,6 +161,11 @@ def setup_capsule_build(source_dir, build_dir, board_type,
log):
)
run_command(name, cmd, source_dir)
+capsule_cfg_file = 'test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt'
+name = 'cp'
+cmd = ( ' cp %s %s' % (capsule_cfg_file, capsule_sig_dir))
+run_command(name, cmd, source_dir)
+
gen_capsule_payloads(capsule_sig_dir)
def run_build(config, source_dir, build_dir, board_type, log):
diff --git a/test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
b/test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
new file mode 100644
index 00..4e5065d538
--- /dev/null
+++ b/test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
@@ -0,0 +1,75 @@
+{
+ image-index: 1
+ image-guid: 09D7CF52-0720-4710-91D1-08469B7FE9C8
+ payload: /tmp/capsules/u-boot.bin.new
+ capsule: /tmp/capsules/Test01
+}
+{
+ image-index: 2
+ image-guid: 5A7021F5-FEF2-48B4-AABA-832E777418C0
+ payload: /tmp/capsules/u-boot.env.new
+ capsule: /tmp/capsules/Test02
+}
+{
+ image-index: 1
+ image-guid: 058B7D83-50D5-4C47-A195-60D86AD341C4
+ payload: /tmp/capsules/u-boot.bin.new
+ capsule: /tmp/capsules/Test03
+
+}
+{
+ image-index: 1
+ image-guid: 3673B45D-6A7C-46F3-9E60-ADABB03F7937
+ payload: /tmp/capsules/uboot_bin_env.itb
+ capsule: /tmp/capsules/Test04
+
+}
+{
+ image-index: 1
+ image-guid: 058B7D83-50D5-4C47-A195-60D86AD341C4
+ payload: /tmp/capsules/uboot_bin_env.itb
+ capsule: /tmp/capsules/Tes
[PATCH v3 09/11] test: capsule: Remove public key embed logic from capsule update test
The embedding of the public key EFI Signature List(ESL) file into the
platform's DTB is now done at the time of u-boot build. Remove this
logic from the capsule update test' configuration.
Include the public key for the sandbox and sandbox_flattree variant
as part of the build.
Signed-off-by: Sughosh Ganu
---
Changes since V2:
* New patch for removing the capsule key and ESL generation logic from
the capsule test config file.
configs/sandbox_defconfig| 1 +
configs/sandbox_flattree_defconfig | 1 +
test/py/tests/test_efi_capsule/conftest.py | 30 +++-
test/py/tests/test_efi_capsule/signature.dts | 10 ---
4 files changed, 6 insertions(+), 36 deletions(-)
delete mode 100644 test/py/tests/test_efi_capsule/signature.dts
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 1ec44d5b33..d8a2386bb0 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -339,6 +339,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/configs/sandbox_flattree_defconfig
b/configs/sandbox_flattree_defconfig
index e7657d40dc..8d60744771 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -226,6 +226,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
CONFIG_UNIT_TEST=y
CONFIG_UT_TIME=y
CONFIG_UT_DM=y
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index a337e62936..9b0f7e635d 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -25,42 +25,20 @@ def efi_capsule_data(request, u_boot_config):
image_path = u_boot_config.persistent_data_dir + '/test_efi_capsule.img'
try:
+capsules_path_dir = '/tmp/capsules/'
# Create a target device
check_call('dd if=/dev/zero of=./spi.bin bs=1MiB count=16', shell=True)
check_call('rm -rf %s' % mnt_point, shell=True)
check_call('mkdir -p %s' % data_dir, shell=True)
check_call('mkdir -p %s' % install_dir, shell=True)
+check_call('cp %s/* %s ' % (capsules_path_dir, data_dir), shell=True)
capsule_auth_enabled = u_boot_config.buildconfig.get(
'config_efi_capsule_authenticate')
if capsule_auth_enabled:
-# Create private key (SIGNER.key) and certificate (SIGNER.crt)
-check_call('cd %s; '
- 'openssl req -x509 -sha256 -newkey rsa:2048 '
-'-subj /CN=TEST_SIGNER/ -keyout SIGNER.key '
-'-out SIGNER.crt -nodes -days 365'
- % data_dir, shell=True)
-check_call('cd %s; %scert-to-efi-sig-list SIGNER.crt SIGNER.esl'
- % (data_dir, EFITOOLS_PATH), shell=True)
-
-# Update dtb adding capsule certificate
-check_call('cd %s; '
- 'cp %s/test/py/tests/test_efi_capsule/signature.dts .'
- % (data_dir, u_boot_config.source_dir), shell=True)
-check_call('cd %s; '
- 'dtc -@ -I dts -O dtb -o signature.dtbo signature.dts; '
- 'fdtoverlay -i %s/arch/sandbox/dts/test.dtb '
-'-o test_sig.dtb signature.dtbo'
- % (data_dir, u_boot_config.build_dir), shell=True)
-
-# Create *malicious* private key (SIGNER2.key) and certificate
-# (SIGNER2.crt)
-check_call('cd %s; '
- 'openssl req -x509 -sha256 -newkey rsa:2048 '
-'-subj /CN=TEST_SIGNER/ -keyout SIGNER2.key '
-'-out SIGNER2.crt -nodes -days 365'
- % data_dir, shell=True)
+check_call('cp %s/arch/sandbox/dts/test.dtb %s/test_sig.dtb' %
+ (u_boot_config.build_dir, data_dir), shell=True)
# Create capsule files
# two regions: one for u-boot.bin and the other for u-boot.env
diff --git a/test/py/tests/test_efi_capsule/signature.dts
b/test/py/tests/test_efi_capsule/signature.dts
deleted file mode 100644
index 078cfc76c9..00
--- a/test/py/tests/test_efi_capsule/signature.dts
+++ /dev/null
@@ -1,10 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-
-/dts-v1/;
-/plugin/;
-
-&{/} {
- signature {
- capsule-key = /incbin/("SIGNER.esl");
- };
-};
--
2.34.1
[PATCH v3 08/11] test: py: Setup capsule files for testing
Support has being added through earlier commits to build capsules and
embed the public key needed for capsule authentication as part of
u-boot build.
>From the testing point-of-view, this means the input files needed for
the above have to be setup before invoking the build. Set this up in
the pytest configuration file for testing the capsule update feature.
Signed-off-by: Sughosh Ganu
---
Changes since V2:
* New patch for setting up the capsule files in the pytest setup
before initiation of u-boot build.
test/py/conftest.py | 87 +
1 file changed, 87 insertions(+)
diff --git a/test/py/conftest.py b/test/py/conftest.py
index fc9dd3a83f..661ed74fae 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -80,6 +80,89 @@ def pytest_addoption(parser):
help='Run sandbox under gdbserver. The argument is the channel '+
'over which gdbserver should communicate, e.g. localhost:1234')
+def setup_capsule_build(source_dir, build_dir, board_type, log):
+"""Setup the platform's build for testing capsule updates
+
+This generates the payload/input files needed for testing the
+capsule update functionality, along with the keys for signing
+the capsules. An EFI Signature List(ESL) file, which houses the
+public key for capsule authentication is generated as
+well.
+
+The ESL file is subsequently embedded into the platform's
+dtb during the u-boot build, to be used for capsule
+authentication.
+
+Two sets of keys are generated, namely SIGNER and SIGNER2.
+The SIGNER2 key pair is used as a malicious key for testing the
+the capsule authentication functionality.
+
+All the generated files are placed under the /tmp/capsules/
+directory.
+
+Args:
+soruce_dir (str): Directory containing source code
+build_dir (str): Directory to build in
+board_type (str): board_type parameter (e.g. 'sandbox')
+log (Logfile): Log file to use
+
+Returns:
+Nothing.
+"""
+def run_command(name, cmd, source_dir):
+with log.section(name):
+if isinstance(cmd, str):
+cmd = cmd.split()
+runner = log.get_runner(name, None)
+runner.run(cmd, cwd=source_dir)
+runner.close()
+log.status_pass('OK')
+
+def gen_capsule_payloads(capsule_dir):
+fname = '%su-boot.bin.old' % capsule_dir
+with open(fname, 'w') as fd:
+fd.write('u-boot:Old')
+
+fname = '%su-boot.bin.new' % capsule_dir
+with open(fname, 'w') as fd:
+fd.write('u-boot:New')
+
+fname = '%su-boot.env.old' % capsule_dir
+with open(fname, 'w') as fd:
+fd.write('u-boot-env:Old')
+
+fname = '%su-boot.env.new' % capsule_dir
+with open(fname, 'w') as fd:
+fd.write('u-boot-env:New')
+
+capsule_sig_dir = '/tmp/capsules/'
+sig_name = 'SIGNER'
+mkdir_p(capsule_sig_dir)
+name = 'openssl'
+cmd = ( 'openssl req -x509 -sha256 -newkey rsa:2048 '
+'-subj /CN=TEST_SIGNER/ -keyout %s%s.key '
+'-out %s%s.crt -nodes -days 365'
+% (capsule_sig_dir, sig_name, capsule_sig_dir, sig_name)
+ )
+run_command(name, cmd, source_dir)
+
+name = 'cert-to-efi-sig-list'
+cmd = ( 'cert-to-efi-sig-list %s%s.crt %s%s.esl'
+% (capsule_sig_dir, sig_name, capsule_sig_dir, sig_name)
+ )
+run_command(name, cmd, source_dir)
+
+sig_name = 'SIGNER2'
+name = 'openssl'
+cmd = ( 'openssl req -x509 -sha256 -newkey rsa:2048 '
+'-subj /CN=TEST_SIGNER/ -keyout %s%s.key '
+'-out %s%s.crt -nodes -days 365'
+% (capsule_sig_dir, sig_name, capsule_sig_dir, sig_name)
+ )
+run_command(name, cmd, source_dir)
+
+gen_capsule_payloads(capsule_sig_dir)
+
def run_build(config, source_dir, build_dir, board_type, log):
"""run_build: Build U-Boot
@@ -90,6 +173,10 @@ def run_build(config, source_dir, build_dir, board_type,
log):
board_type (str): board_type parameter (e.g. 'sandbox')
log (Logfile): Log file to use
"""
+capsule_boards = ( 'sandbox', 'sandbox64', 'sandbox_flattree' )
+if board_type in capsule_boards:
+setup_capsule_build(source_dir, build_dir, board_type, log)
+
if config.getoption('buildman'):
if build_dir != source_dir:
dest_args = ['-o', build_dir, '-w']
--
2.34.1
[PATCH v3 07/11] CI: capsule: Setup the files needed for capsule update testing
Support has being added through earlier commits to build capsules
and embed the public key needed for capsule authentication as part of
u-boot build.
>From the testing point-of-view, this means the input files needed for
generating the above have to be setup before invoking the build. Set
this up in the CI configuration files for testing the capsule update
feature.
Signed-off-by: Sughosh Ganu
---
Changes since V2:
* New patch setting up the capsule files needed for CI run
.azure-pipelines.yml | 21 +
.gitlab-ci.yml | 19 +++
2 files changed, 40 insertions(+)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 96b2ab4d75..75075bbd07 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -398,6 +398,17 @@ stages:
wget -O -
https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
| tar -C /tmp -xJ;
export
OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
fi
+ mkdir -p /tmp/capsules/;
+ echo -n "u-boot:Old" >/tmp/capsules/u-boot.bin.old;
+ echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
+ echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
+ echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+ if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
"sandbox_flattree" ]]; then
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt
-nodes -days 365;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
/tmp/capsules/SIGNER2.crt -nodes -days 365;
+ cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
/tmp/capsules/SIGNER.esl;
+ fi
+
# the below corresponds to .gitlab-ci.yml "script"
cd ${WORK_DIR}
export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD};
@@ -582,6 +593,16 @@ stages:
cd ${WORK_DIR}
# make environment variables available as tests are running inside a
container
export BUILDMAN="${BUILDMAN}"
+ if [[ "${BUILDMAN}" == "sandbox" ]] || [[ "${BUILDMAN}" == "sandbox
x86" ]]; then
+ if [ ! -d "/tmp/capsules/" ]; then
+ mkdir -p /tmp/capsules/;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt
-n
+odes -days 365;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
/tmp/capsules/SIGNER2.crt
+-nodes -days 365;
+ cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
/tmp/capsules/SIGNER.esl;
+ fi
+ fi
git config --global --add safe.directory ${WORK_DIR}
EOF
cat << "EOF" >> build.sh
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index e6c6ab3586..577eebd678 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -37,6 +37,17 @@ stages:
export
OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
fi
+- mkdir -p /tmp/capsules/;
+- echo -n "u-boot:Old" >/tmp/capsules/u-boot.bin.old;
+- echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
+- echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
+- echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
+- if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
"sandbox_flattree" ]]; then
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days 365;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes -days
365;
+ cert-to-efi-sig-list /tmp/capsules/SIGNER.crt /tmp/capsules/SIGNER.esl;
+ fi
+
after_script:
- cp -v /tmp/${TEST_PY_BD}/*.{html,css} .
- rm -rf /tmp/uboot-test-hooks /tmp/venv
@@ -131,6 +142,14 @@ build all other platforms:
stage: world build
script:
- ret=0;
+ if [ ! -d "/tmp/capsules/" ]; then
+mkdir -p /tmp/capsules/;
+openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days
+ 365;
+openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes -da
+ys 365;
+cert-to-efi-sig-list /tmp/capsules/SIGNER.crt /tmp/capsules/SIGNER.esl;
+ fi
git config --global --add safe.directory "${CI_PROJECT_DIR}";
./tools/buildman/buildman -o /tmp -PEWM -x arm,powerpc || ret=$?;
if [[ $ret -ne 0 ]]; then
--
2.34.1
[PATCH v3 06/11] binman: capsule: Add support for generating capsules
Add support in binman for generating capsules. The capsule parameters
can be specified either through a config file or through the capsule
binman entry.
Signed-off-by: Sughosh Ganu
---
Changes since V2:
* New patch which generates capsules through binman replacing the
earlier make target.
tools/binman/btool/mkeficapsule.py | 91 +
tools/binman/entries.rst | 27
tools/binman/etype/capsule.py | 102 +
3 files changed, 220 insertions(+)
create mode 100644 tools/binman/btool/mkeficapsule.py
create mode 100644 tools/binman/etype/capsule.py
diff --git a/tools/binman/btool/mkeficapsule.py
b/tools/binman/btool/mkeficapsule.py
new file mode 100644
index 00..9f656c12cf
--- /dev/null
+++ b/tools/binman/btool/mkeficapsule.py
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2023 Linaro Limited
+#
+"""Bintool implementation for mkeficapsule tool
+
+mkeficapsule is a tool used for generating EFI capsules.
+
+The following are the command-line options to be provided
+to the tool
+Usage: mkeficapsule [options]
+Options:
+ -g, --guid guid for image blob type
+ -i, --index update image index
+ -I, --instanceupdate hardware instance
+ -p, --private-key private key file
+ -c, --certificate signer's certificate file
+ -m, --monotonic-count monotonic count
+ -d, --dump_sig dump signature (*.p7)
+ -A, --fw-accept firmware accept capsule, requires GUID, no image blob
+ -R, --fw-revert firmware revert capsule, takes no GUID, no image blob
+ -o, --capoemflag Capsule OEM Flag, an integer between 0x and 0x
+ -f, --cfg-file config file with capsule parameters
+ -h, --help print a help message
+
+"""
+
+from binman import bintool
+
+class Bintoolmkeficapsule(bintool.Bintool):
+"""Handles the 'mkeficapsule' tool
+
+This bintool is used for generating the EFI capsules. The
+capsule generation parameters can either be specified through
+command-line, or through a config file.
+
+"""
+def __init__(self, name):
+super().__init__(name, 'mkeficapsule tool for generating capsules')
+
+def capsule_cfg_file(self, cfg_file):
+
+args = [
+f'--cfg-file={cfg_file}'
+]
+self.run_cmd(*args)
+
+def cmdline_capsule(self, image_index, image_guid, hardware_instance,
+payload, output_fname):
+
+args = [
+f'--index={image_index}',
+f'--guid={image_guid}',
+f'--instance={hardware_instance}',
+payload,
+output_fname
+]
+self.run_cmd(*args)
+
+def cmdline_auth_capsule(self, image_index, image_guid, hardware_instance,
+ monotonic_count, priv_key, pub_key,
+ payload, output_fname):
+
+args = [
+f'--index={image_index}',
+f'--guid={image_guid}',
+f'--instance={hardware_instance}',
+f'--monotonic-count={monotonic_count}',
+f'--private-key={priv_key}',
+f'--certificate={pub_key}',
+payload,
+output_fname
+]
+self.run_cmd(*args)
+
+def fetch(self, method):
+"""Fetch handler for mkeficapsule
+
+This builds the tool from source
+
+Returns:
+tuple:
+str: Filename of fetched file to copy to a suitable directory
+str: Name of temp directory to remove, or None
+"""
+if method != bintool.FETCH_BUILD:
+return None
+result = self.build_from_git(
+'https://source.denx.de/u-boot/u-boot.git',
+'tools',
+'tools/mkeficapsule')
+return result
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index b71af801fd..9a263e8691 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -283,6 +283,33 @@ entry; similarly for SPL.
+.. _etype_capsule:
+
+Entry: capsule: Entry for generating EFI Capsule files
+--
+
+This is an entry for generating EFI capsules.
+
+The parameters needed for generation of the capsules can either be
+provided separately, or through a config file.
+
+Properties / Entry arguments:
+- cfg-file: Config file for providing capsule
+ parameters.
+- image-index: Unique number for identifying
+ corresponding payload image.
+- image-type-id: Image GUID which will be used
+ for identifying the image.
+- hardware-instance: Optional number for identifying
+ unique hardware instance of a device in the system.
+- monotomic-count: Count used when signing an image.
+- private-key: Path to private
[PATCH v3 05/11] doc: Add documentation to describe capsule config file format
The UEFI capsule can be generated either through command-line
parameters, or, by specifying those in a config file. Add
documentation to describe the format of the config file.
Signed-off-by: Sughosh Ganu
---
Changes since V2: None
doc/develop/uefi/uefi.rst | 64 +++
1 file changed, 64 insertions(+)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index c04e62f3a5..ddf8e20cb0 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -442,6 +442,70 @@ following command can be issued
--guid c1b629f1-ce0e-4894-82bf-f0a38387e630 \
optee.bin optee.capsule
+Or alternatively, the capsule can be generated through a make target
+
+.. code-block:: bash
+
+$ make capsule
+
+Issuing the above make command requires specifying the capsule
+parameters through a config file instead. The Kconfig symbol
+CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the path to
+the config file.
+
+The config file describes the parameters that are used for generating
+one or more capsules. The parameters for a given capsule file are
+specified within curly braces, in the form of "key:value" pairs. All
+the parameters that are currently supported by the mkeficapsule tool
+can be specified through the config file.
+
+The following are some example payload parameters specified through
+the config file.
+
+.. code-block:: none
+
+ {
+ image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
+ hardware-instance: 0
+ monotonic-count: 1
+ payload: u-boot.bin
+ image-index: 1
+ private-key: /path/to/priv/key
+ pub-key-cert: /path/to/pub/key
+ capsule: u-boot.capsule
+ }
+ {
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ hardware-instance: 0
+ payload: u-boot.itb
+ image-index: 2
+ oemflags: 0x8000
+ capsule: fit.capsule
+ }
+ {
+ capsule-type: accept
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ capsule: accept.capsule
+ }
+ {
+ capsule-type: revert
+ capsule: revert.capsule
+ }
+
+The following are the keys that specify the capsule parameters
+
+..code-block:: none
+
+image-guid: Image GUID
+image-index: Image index value
+private-key: Path to the private key file used for capsule signing
+pub-key-cert: Path to the public key crt file used for capsule signing
+payload: Path to the capsule payload file
+capsule: Path to the output capsule file that is generated
+hardware-instance: Hardware Instance value
+monotonic-count: Monotonic count value
+capsule-type: Specifies capsule type. normal(default), accept or revert
+oemflags: 16bit Oemflags value to be used(populated in capsule header)
Enabling Capsule Authentication
***
--
2.34.1
[PATCH v3 04/11] tools: mkeficapsule: Add support for parsing capsule params from config file
Add support for specifying the parameters needed for capsule
generation through a config file, instead of passing them through
command-line. Parameters for more than a single capsule file can be
specified, resulting in generation of multiple capsules through a
single invocation of the command.
This path is to be used for generating capsules through a make target,
with the parameters being parsed from the config file.
Signed-off-by: Sughosh Ganu
---
Changes since V2:
* Add a Kconfig boolean symbol CONFIG_EFI_USE_CAPSULE_CFG_FILE which
can be used to generate capsules through config file or parameters.
tools/Kconfig | 16 ++
tools/Makefile | 1 +
tools/eficapsule.h | 110
tools/mkeficapsule.c | 84 +
tools/mkeficapsule_parse.c | 345 +
5 files changed, 526 insertions(+), 30 deletions(-)
create mode 100644 tools/mkeficapsule_parse.c
diff --git a/tools/Kconfig b/tools/Kconfig
index 539708f277..9b744aba31 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -98,6 +98,22 @@ config TOOLS_MKEFICAPSULE
optionally sign that file. If you want to enable UEFI capsule
update feature on your target, you certainly need this.
+config EFI_CAPSULE_CFG_FILE
+ string "Path to the EFI Capsule Config File"
+ default ""
+ help
+ Path to the EFI capsule config file which provides the
+ parameters needed to build capsule(s). Parameters can be
+ provided for multiple payloads resulting in corresponding
+ capsule images being generated.
+
+config EFI_USE_CAPSULE_CFG_FILE
+ bool "Use the config file for generating capsules"
+ help
+ Boolean option used to specify if the EFI capsules are to
+ be generated through parameters specified via the config
+ file or through command line.
+
menuconfig FSPI_CONF_HEADER
bool "FlexSPI Header Configuration"
help
diff --git a/tools/Makefile b/tools/Makefile
index d793cf3bec..ef366f3d61 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
HOSTLDLIBS_mkeficapsule += \
$(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
+mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
# We build some files with extra pedantic flags to try to minimize things
# that won't build on some weird host compiler -- though there are lots of
diff --git a/tools/eficapsule.h b/tools/eficapsule.h
index 072a4b5598..42e66c6d6a 100644
--- a/tools/eficapsule.h
+++ b/tools/eficapsule.h
@@ -52,6 +52,38 @@ typedef struct {
/* flags */
#define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
+enum capsule_type {
+ CAPSULE_NORMAL_BLOB = 0,
+ CAPSULE_ACCEPT,
+ CAPSULE_REVERT,
+};
+
+/**
+ * struct efi_capsule_params - Capsule parameters
+ * @image_guid: Guid value of the payload input image
+ * @image_index: Image index value
+ * @hardware_instance: Hardware instance to be used for the image
+ * @monotonic_count: Monotonic count value to be used for signed capsule
+ * @privkey_file: Path to private key used in capsule signing
+ * @cert_file: Path to public key certificate used in capsule signing
+ * @input_file: Path to payload input image
+ * @capsule_file: Path to the output capsule file
+ * @oemflags: Oemflags to be populated in the capsule header
+ * @capsule: Capsule Type, normal or accept or revert
+ */
+struct efi_capsule_params {
+ efi_guid_t *image_guid;
+ unsigned long image_index;
+ unsigned long hardware_instance;
+ uint64_t monotonic_count;
+ char *privkey_file;
+ char *cert_file;
+ char *input_file;
+ char *capsule_file;
+ unsigned long oemflags;
+ enum capsule_type capsule;
+};
+
struct efi_capsule_header {
efi_guid_t capsule_guid;
uint32_t header_size;
@@ -113,4 +145,82 @@ struct efi_firmware_image_authentication {
struct win_certificate_uefi_guid auth_info;
} __packed;
+/**
+ * capsule_with_cfg_file() - Generate capsule from config file
+ * @cfg_file: Path to the config file
+ *
+ * Parse the capsule parameters from the config file and use the
+ * parameters for generating one or more capsules.
+ *
+ * Return: None
+ *
+ */
+void capsule_with_cfg_file(const char *cfg_file);
+
+/**
+ * convert_uuid_to_guid() - convert UUID to GUID
+ * @buf: UUID binary
+ *
+ * UUID and GUID have the same data structure, but their binary
+ * formats are different due to the endianness. See lib/uuid.c.
+ * Since uuid_parse() can handle only UUID, this function must
+ * be called to get correct data for GUID when parsing a string.
+ *
+ * The correct data will be returned in @buf.
+ */
+void convert_uuid_to_guid(unsigned char *buf);
+
+/**
+ * create_empty_capsule() - Generate an empty capsule
+ * @path: Path to the emp
[PATCH v3 02/11] capsule: authenticate: Add capsule public key in platform's dtb
The EFI capsule authentication logic in u-boot expects the public key
in the form of an EFI Signature List(ESL) to be provided as part of
the platform's dtb. Currently, the embedding of the ESL file into the
dtb needs to be done manually.
Add a signature node in the u-boot dtsi file and include the public
key through the capsule-key property. This file is per architecture,
and is currently being added for sandbox and arm architectures. It
will have to be added for other architectures which need to enable
capsule authentication support.
The path to the ESL file is specified through the
CONFIG_EFI_CAPSULE_ESL_FILE symbol.
Signed-off-by: Sughosh Ganu
---
Changes since V2:
* Add the public key ESL file through the u-boot.dtsi.
* Add the dtsi files for sandbox and arm architectures.
* Add a check in the Makefile that the ESL file path is not empty.
arch/arm/dts/u-boot.dtsi | 17 +
arch/sandbox/dts/u-boot.dtsi | 17 +
lib/efi_loader/Kconfig | 11 +++
lib/efi_loader/Makefile | 7 +++
4 files changed, 52 insertions(+)
create mode 100644 arch/arm/dts/u-boot.dtsi
create mode 100644 arch/sandbox/dts/u-boot.dtsi
diff --git a/arch/arm/dts/u-boot.dtsi b/arch/arm/dts/u-boot.dtsi
new file mode 100644
index 00..60bd004937
--- /dev/null
+++ b/arch/arm/dts/u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Devicetree file with miscellaneous nodes that will be included
+ * at build time into the DTB. Currently being used for including
+ * capsule related information.
+ *
+ */
+
+#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
+/ {
+#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
+ signature {
+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
+ };
+#endif
+};
+#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
new file mode 100644
index 00..60bd004937
--- /dev/null
+++ b/arch/sandbox/dts/u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Devicetree file with miscellaneous nodes that will be included
+ * at build time into the DTB. Currently being used for including
+ * capsule related information.
+ *
+ */
+
+#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
+/ {
+#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
+ signature {
+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
+ };
+#endif
+};
+#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c5835e6ef6..1326a1d109 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -234,6 +234,17 @@ config EFI_CAPSULE_MAX
Select the max capsule index value used for capsule report
variables. This value is used to create CapsuleMax variable.
+config EFI_CAPSULE_ESL_FILE
+ string "Path to the EFI Signature List File"
+ default ""
+ depends on EFI_CAPSULE_AUTHENTICATE
+ help
+ Provides the absolute path to the EFI Signature List
+ file which will be embedded in the platform's device
+ tree and used for capsule authentication at the time
+ of capsule update.
+
+
config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 13a35eae6c..9fb04720d9 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -86,3 +86,10 @@ obj-$(CONFIG_EFI_ECPT) += efi_conformance.o
EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
$(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
+
+ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
+EFI_CAPSULE_KEY_PATH := $(subst $\",,$(CONFIG_EFI_CAPSULE_ESL_FILE))
+ifeq ("$(wildcard $(EFI_CAPSULE_KEY_PATH))","")
+$(error .esl cerificate not found. Configure your CONFIG_EFI_CAPSULE_ESL_FILE)
+endif
+endif
--
2.34.1
[PATCH v3 03/11] doc: capsule: Document the new mechanism to embed ESL file into dtb
Update the document to specify how the EFI Signature List(ESL) file
can be embedded into the platform's dtb as part of the u-boot build.
Signed-off-by: Sughosh Ganu
---
Changes since V2:
* Highlight the need to use the u-boot.dtsi file for embedding the
public key ESL into the DTB.
doc/develop/uefi/uefi.rst | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index ffe25ca231..c04e62f3a5 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -495,20 +495,16 @@ and used by the steps highlighted below.
...
}
-You can do step-4 manually with
+You can perform step-4 by defining the Kconfig symbol
+CONFIG_EFI_CAPSULE_ESL_FILE. Once this has been done, the signature
+node can be added to the u-boot.dtsi file. For reference, check the
+u-boot.dtsi file for the sandbox architecture. If this node has not
+been added to the architecture's u-boot.dtsi file, this needs to be
+done. The node has currently been added for the sandbox and arm
+architectures' in the u-boot.dtsi file. Once the u-boot.dtsi file has
+been added with the signature node, the esl file will automatically
+get embedded into the platform's dtb as part of u-boot build.
-.. code-block:: console
-
-$ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
-$ fdtoverlay -i orig.dtb -o new.dtb -v signature.dtbo
-
-where signature.dts looks like::
-
-&{/} {
-signature {
-capsule-key = /incbin/("CRT.esl");
-};
-};
Executing the boot manager
~~
--
2.34.1
[PATCH v3 01/11] nuvoton: npcm845-evb: Add a newline at the end of file
Add a newline at the end of the dts, without which the build fails when including the u-boot.dtsi file. Signed-off-by: Sughosh Ganu --- Changes since V2: * New patch arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/nuvoton-npcm845-evb.dts b/arch/arm/dts/nuvoton-npcm845-evb.dts index 3cab7807e3..a93666cb41 100644 --- a/arch/arm/dts/nuvoton-npcm845-evb.dts +++ b/arch/arm/dts/nuvoton-npcm845-evb.dts @@ -354,4 +354,4 @@ _pins _pins >; -}; \ No newline at end of file +}; -- 2.34.1
[PATCH v3 00/11] Integrate EFI capsule tasks into u-boot's build flow
This patchset aims to bring two capsule related tasks under the u-boot build flow. One is the embedding of the public key into the platform's dtb. The public key is in the form of an EFI Signature List(ESL) file and is used for capsule authentication. This is being achieved by adding the signature node containing the capsule public key in the architecture's u-boot.dtsi file. Currently, the u-boot.dtsi file has been added for the sandbox and arm architectures. The path to the ESL file is being provided through a Kconfig symbol(CONFIG_EFI_CAPSULE_ESL_FILE). Changes have also been made to the test flow so that the keys used for signing the capsule, and the ESL file, are generated prior to invoking the u-boot's build, which enables embedding the ESL file into the dtb as part of the u-boot build. The other task is related to generation of capsules. Support is being added to generate capsules by specifying the capsule parameters in a config file. Calling the mkeficapsule tool then results in generation of the corresponding capsule files. The capsules can be generated as part of u-boot build, and this is being achieved through binman, by adding a capsule entry type. The capsules can be generated either by specifying the capsule parameters in a config file, or through specifying them as properties under the capsule entry node. If using the config file, the path to the config file is to be specified through a Kconfig symbol(CONFIG_EFI_CAPSULE_CFG_FILE). Changes have also been made to the efi capsule update feature testing setup on the sandbox variants. Currently, the capsule files and the public key ESL file are generated after u-boot has been built. This logic has been changed so that the capsule input files along with the keys needed for capsule signing and authentication are generated prior to initiation of the u-boot build. The placement of all the files needed for generation of capsules, along with the generated capsule files is under the /tmp/capsules/ directory. Currently, the capsule update feature is tested on the sandbox and sandbox_flattree variants in CI. The capsule generation through config file is enabled for the sandbox variant, with the sandbox_flattree variant generating capsules through the command-line parameters. The document has been updated to reflect the above changes. Changes since V2: This version embeds the capsule auth related public key through the u-boot.dtsi file. The capsule generation has been moved to binman. The changes in the test setup have been split into multiple patches, instead of a single monolithic patch. * Add the public key ESL file through the u-boot.dtsi * Add the dtsi files for sandbox and arm architectures * Add a check in the Makefile that the ESL file path is not empty. * Highlight the need to use the u-boot.dtsi file for embedding the public key ESL into the DTB. * Add a Kconfig boolean symbol CONFIG_EFI_USE_CAPSULE_CFG_FILE which can be used to generate capsules through config file or parameters. * New patch which generates capsules through binman replacing the earlier make target. * New patch setting up the capsule files needed for CI run * New patch for setting up the capsule files in the pytest setup before initiation of u-boot build. * New patch for removing the capsule key and ESL generation logic from the capsule test config file. * New patch to add the capsule generation config file for sandbox. * New patch for generating the capsules and capsule input files through binman. Sughosh Ganu (11): nuvoton: npcm845-evb: Add a newline at the end of file capsule: authenticate: Add capsule public key in platform's dtb doc: capsule: Document the new mechanism to embed ESL file into dtb tools: mkeficapsule: Add support for parsing capsule params from config file doc: Add documentation to describe capsule config file format binman: capsule: Add support for generating capsules CI: capsule: Setup the files needed for capsule update testing test: py: Setup capsule files for testing test: capsule: Remove public key embed logic from capsule update test sandbox: capsule: Add a config file for generating capsules sandbox: capsule: Generate capsule related files through binman .azure-pipelines.yml | 22 ++ .gitlab-ci.yml| 20 + arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +- arch/arm/dts/u-boot.dtsi | 17 + arch/sandbox/dts/u-boot.dtsi | 160 configs/sandbox_defconfig | 3 + configs/sandbox_flattree_defconfig| 1 + doc/develop/uefi/uefi.rst | 86 - lib/efi_loader/Kconfig| 11 + lib/efi_loader/Makefile | 7 + test/py/conftest.py | 92 + test/py/tests/test_efi_capsule/conftest.py| 92 + .../test_efi_capsule/sandbox_capsule_cfg.txt | 75 test/py/tests
Re: [PATCH 5/7] Makefile: Add a target for building capsules
hi Simon, On Wed, 28 Jun 2023 at 15:49, Simon Glass wrote: > > Hi Sughosh, > > On Wed, 28 Jun 2023 at 11:00, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Wed, 28 Jun 2023 at 13:12, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Tue, 27 Jun 2023 at 18:42, Sughosh Ganu > > > wrote: > > > > > > > > hi Simon, > > > > > > > > On Tue, 27 Jun 2023 at 17:51, Simon Glass wrote: > > > > > > > > > > Hi Sughosh, > > > > > > > > > > On Tue, 27 Jun 2023 at 13:08, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > On Tue, 27 Jun 2023 at 16:50, Simon Glass wrote: > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > On Tue, 27 Jun 2023 at 05:57, Sughosh Ganu > > > > > > > wrote: > > > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > > > On Mon, 26 Jun 2023 at 17:43, Sughosh Ganu > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > > > > > On Mon, 26 Jun 2023 at 14:38, Simon Glass > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > > > > > On Wed, 21 Jun 2023 at 05:26, Sughosh Ganu > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > > > > > > > > > On Mon, 19 Jun 2023 at 18:07, Simon Glass > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 15 Jun 2023 at 17:25, Sughosh Ganu > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 15 Jun 2023 at 14:44, Simon Glass > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 13 Jun 2023 at 11:39, Sughosh Ganu > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Add a target for building EFI capsules. The > > > > > > > > > > > > > > > capsule parameters are > > > > > > > > > > > > > > > specified through a config file, and the path to > > > > > > > > > > > > > > > the config file is > > > > > > > > > > > > > > > specified through CONFIG_EFI_CAPSULE_CFG_FILE. > > > > > > > > > > > > > > > When the config file is > > > > > > > > > > > > > > > not specified, the command only builds tools. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > Makefile | 9 + > > > > > > > > > > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > > > > > > >
Re: [PATCH 5/7] Makefile: Add a target for building capsules
hi Simon, On Wed, 28 Jun 2023 at 13:12, Simon Glass wrote: > > Hi Sughosh, > > On Tue, 27 Jun 2023 at 18:42, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Tue, 27 Jun 2023 at 17:51, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Tue, 27 Jun 2023 at 13:08, Sughosh Ganu > > > wrote: > > > > > > > > hi Simon, > > > > > > > > On Tue, 27 Jun 2023 at 16:50, Simon Glass wrote: > > > > > > > > > > Hi Sughosh, > > > > > > > > > > On Tue, 27 Jun 2023 at 05:57, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > On Mon, 26 Jun 2023 at 17:43, Sughosh Ganu > > > > > > wrote: > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > On Mon, 26 Jun 2023 at 14:38, Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > On Wed, 21 Jun 2023 at 05:26, Sughosh Ganu > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > > > > > On Mon, 19 Jun 2023 at 18:07, Simon Glass > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > > > > > On Thu, 15 Jun 2023 at 17:25, Sughosh Ganu > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > > > > > > > > > On Thu, 15 Jun 2023 at 14:44, Simon Glass > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 13 Jun 2023 at 11:39, Sughosh Ganu > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Add a target for building EFI capsules. The capsule > > > > > > > > > > > > > parameters are > > > > > > > > > > > > > specified through a config file, and the path to the > > > > > > > > > > > > > config file is > > > > > > > > > > > > > specified through CONFIG_EFI_CAPSULE_CFG_FILE. When > > > > > > > > > > > > > the config file is > > > > > > > > > > > > > not specified, the command only builds tools. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > > > > > > --- > > > > > > > > > > > > > Makefile | 9 + > > > > > > > > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/Makefile b/Makefile > > > > > > > > > > > > > index 10bfaa52ad..96db29aa77 100644 > > > > > > > > > > > > > --- a/Makefile > > > > > > > > > > > > > +++ b/Makefile > > > > > > > > > > > > > @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb > > > > > > > > > > > > > dts/dt.dtb: u-boot > > > > > > > > > > > > > $(Q)$(MAKE) $(build)=dts dtbs > > > > > > > > > > > > > > > > > > > > > > > > > > +quiet_cmd_mkeficapsule = MKEFICAPSULE $@ > > > > > > > > > > > > > +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule $@ > > > > > > > > > > > > &
Re: [PATCH 5/7] Makefile: Add a target for building capsules
hi Simon, On Tue, 27 Jun 2023 at 17:51, Simon Glass wrote: > > Hi Sughosh, > > On Tue, 27 Jun 2023 at 13:08, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Tue, 27 Jun 2023 at 16:50, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Tue, 27 Jun 2023 at 05:57, Sughosh Ganu > > > wrote: > > > > > > > > hi Simon, > > > > > > > > On Mon, 26 Jun 2023 at 17:43, Sughosh Ganu > > > > wrote: > > > > > > > > > > hi Simon, > > > > > > > > > > On Mon, 26 Jun 2023 at 14:38, Simon Glass wrote: > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > On Wed, 21 Jun 2023 at 05:26, Sughosh Ganu > > > > > > wrote: > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > On Mon, 19 Jun 2023 at 18:07, Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > On Thu, 15 Jun 2023 at 17:25, Sughosh Ganu > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > > > > > On Thu, 15 Jun 2023 at 14:44, Simon Glass > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > > > > > On Tue, 13 Jun 2023 at 11:39, Sughosh Ganu > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Add a target for building EFI capsules. The capsule > > > > > > > > > > > parameters are > > > > > > > > > > > specified through a config file, and the path to the > > > > > > > > > > > config file is > > > > > > > > > > > specified through CONFIG_EFI_CAPSULE_CFG_FILE. When the > > > > > > > > > > > config file is > > > > > > > > > > > not specified, the command only builds tools. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > > > > --- > > > > > > > > > > > Makefile | 9 + > > > > > > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > > > > > > > > > > > diff --git a/Makefile b/Makefile > > > > > > > > > > > index 10bfaa52ad..96db29aa77 100644 > > > > > > > > > > > --- a/Makefile > > > > > > > > > > > +++ b/Makefile > > > > > > > > > > > @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb > > > > > > > > > > > dts/dt.dtb: u-boot > > > > > > > > > > > $(Q)$(MAKE) $(build)=dts dtbs > > > > > > > > > > > > > > > > > > > > > > +quiet_cmd_mkeficapsule = MKEFICAPSULE $@ > > > > > > > > > > > +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule $@ > > > > > > > > > > > + > > > > > > > > > > > +PHONY += capsule > > > > > > > > > > > +capsule: tools > > > > > > > > > > > +ifneq ($(CONFIG_EFI_CAPSULE_CFG_FILE),"") > > > > > > > > > > > + $(call cmd,mkeficapsule) > > > > > > > > > > > +endif > > > > > > > > > > > + > > > > > > > > > > > quiet_cmd_copy = COPY$@ > > > > > > > > > > >cmd_copy = cp $< $@ > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > 2.34.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We
Re: [PATCH 5/7] Makefile: Add a target for building capsules
hi Simon, On Tue, 27 Jun 2023 at 16:50, Simon Glass wrote: > > Hi Sughosh, > > On Tue, 27 Jun 2023 at 05:57, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Mon, 26 Jun 2023 at 17:43, Sughosh Ganu wrote: > > > > > > hi Simon, > > > > > > On Mon, 26 Jun 2023 at 14:38, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Wed, 21 Jun 2023 at 05:26, Sughosh Ganu > > > > wrote: > > > > > > > > > > hi Simon, > > > > > > > > > > On Mon, 19 Jun 2023 at 18:07, Simon Glass wrote: > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > On Thu, 15 Jun 2023 at 17:25, Sughosh Ganu > > > > > > wrote: > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > On Thu, 15 Jun 2023 at 14:44, Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > On Tue, 13 Jun 2023 at 11:39, Sughosh Ganu > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Add a target for building EFI capsules. The capsule > > > > > > > > > parameters are > > > > > > > > > specified through a config file, and the path to the config > > > > > > > > > file is > > > > > > > > > specified through CONFIG_EFI_CAPSULE_CFG_FILE. When the > > > > > > > > > config file is > > > > > > > > > not specified, the command only builds tools. > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > > --- > > > > > > > > > Makefile | 9 + > > > > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > > > > > > > diff --git a/Makefile b/Makefile > > > > > > > > > index 10bfaa52ad..96db29aa77 100644 > > > > > > > > > --- a/Makefile > > > > > > > > > +++ b/Makefile > > > > > > > > > @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb > > > > > > > > > dts/dt.dtb: u-boot > > > > > > > > > $(Q)$(MAKE) $(build)=dts dtbs > > > > > > > > > > > > > > > > > > +quiet_cmd_mkeficapsule = MKEFICAPSULE $@ > > > > > > > > > +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule $@ > > > > > > > > > + > > > > > > > > > +PHONY += capsule > > > > > > > > > +capsule: tools > > > > > > > > > +ifneq ($(CONFIG_EFI_CAPSULE_CFG_FILE),"") > > > > > > > > > + $(call cmd,mkeficapsule) > > > > > > > > > +endif > > > > > > > > > + > > > > > > > > > quiet_cmd_copy = COPY$@ > > > > > > > > >cmd_copy = cp $< $@ > > > > > > > > > > > > > > > > > > -- > > > > > > > > > 2.34.1 > > > > > > > > > > > > > > > > > > > > > > > > > We should be using binman to build images...you seem to be > > > > > > > > building > > > > > > > > something in parallel with that. Can you please take a look at > > > > > > > > binman? > > > > > > > > > > > > > > Again, I had explored using binman for this task. The one issue > > > > > > > where > > > > > > > I find the above flow better is that I can simply build my payload > > > > > > > image(s) followed by 'make capsule' to generate the capsules for > > > > > > > earlier generated images. In it's current form, I don't see an > > > > > > > easy > > > > > > > way to enforce this dependency in binman when I want to build the > > > > > > > payload followed by generation of capsules. I did see the mention > > > > >
Re: [PATCH 1/7] capsule: authenticate: Embed capsule public key in platform's dtb
hi Simon, On Tue, 27 Jun 2023 at 15:44, Simon Glass wrote: > > Hi, > > On Tue, 27 Jun 2023 at 10:55, Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > On Mon, 26 Jun 2023 at 14:19, Simon Glass wrote: > > > > > > Hi Ilias, > > > > > > On Mon, 26 Jun 2023 at 10:53, Ilias Apalodimas > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > [...] > > > > > > > > > > > > > > + > > > > > > > > > > +gen_capsule_signature_file signature.$$.dts > /dev/null > > > > > > > > > > 2>&1 > > > > > > > > > > +$CPP $dtc_cpp_flags -x assembler-with-cpp -o > > > > > > > > > > signature.$$.tmp signature.$$.dts > /dev/null 2>&1 > > > > > > > > > > +dtc -@ -O dtb -o signature.$$.dtbo signature.$$.tmp > > > > > > > > > > > /dev/null 2>&1 > > > > > > > > > > +fdtoverlay -i $1 -o temp.$$.dtb -v signature.$$.dtbo > > > > > > > > > > > /dev/null 2>&1 > > > > > > > > > > +mv temp.$$.dtb $1 > /dev/null 2>&1 > > > > > > > > > > +rm -f signature.$$.* > /dev/null 2>&1 > > > > > > > > > > -- > > > > > > > > > > 2.34.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can you please add this to binman instead? > > > > > > > > > > > > > > > > I had looked at using binman for this work earlier because I > > > > > > > > very much > > > > > > > > expected this comment from you :). Having said that, I am very > > > > > > > > much > > > > > > > > open to using binman instead if it turns out to be the better > > > > > > > > way of > > > > > > > > achieving this. What this patch does is that, with capsule > > > > > > > > authentication enabled, it embeds the public key esl file into > > > > > > > > the > > > > > > > > dtb's as they get built. As per my understanding, binman gets > > > > > > > > called > > > > > > > > at the end of the u-boot build, once the constituent images( > > > > > > > > e..g > > > > > > > > u-boot.bin = u-boot-no-dtb.bin + dtb) have been generated. So, > > > > > > > > if we > > > > > > > > call binman _after_ the requisite image(s) have been generated, > > > > > > > > we > > > > > > > > would need to 1) identify the dtb's in which the esl needs to be > > > > > > > > embedded, and then 2) generate the final image all over again. > > > > > > > > Don't > > > > > > > > you think this is non optimal? Or is there a way of generating > > > > > > > > the > > > > > > > > constituent images(including the dtb's) through binman instead? > > > > > > > > > > > > > > The best way to do that IMO is to generate a second file, .e.g. > > > > > > > u-boot-capsule.bin > > > > > > > > > > > > > > This make no sense to me whatsoever. Do we have an example in u-boot > > > > generating multiple dtb versions for other reasons/subsystems? > > > > > > > > > > That would break the scripts for platforms which might be using > > > > > > u-boot.bin as the image to boot from. I know that the ST platform > > > > > > which does enable capsule updates uses the u-boot-nodtb.bin as the > > > > > > BL33 image and the u-boot.dtb as BL33_CFG. Hence my question, if we > > > > > > have to use binman, is there a way to 1) modify the u-boot.dtb and > > > > > > then 2) regenerate u-boot.bin image. > > > > > > > > > > > > I know this is software, and everything can be done in a hacky way. > > > > > > But I was exploring using the u-boot node as a section entry, so > > > > > > that > > > > > > the u-boot.dtb can be modified and then binman would > > > > > > repackage/regenerate the u-boot.bin. But this is not working. > > > > > > > > > > NO, please do not do that. You should create a new file, not modify > > > > > u-boot.bin or u-boot.dtb. Please just don't mess around with this, it > > > > > will lead to all sorts of confusion. > > > > > > > > > > I thought we already had this discussion a while back? > > > > > > > > No we haven't. In fact I am struggling to see the confusion part. It's > > > > fine for the u-boot dtb to include all the internal nodes DM needs, but > > > > suddenly having the capsule signature is problematic? > > > > > > > > In the past the .esl file was part of the U-Boot binary and things were > > > > working perfectly fine. In fact you could update/downgrade u-boot and > > > > the > > > > signatures naturally followed along instead of having to update u-boot > > > > *and* the dtb, which we have to do today. You could also build a capsule > > > > way easier without injecting/removing signatures to the dtb. > > > > You were the one that insisted on reverting that and instead adding it > > > > on > > > > the dtb. We explained most of the downsides back then, along with some > > > > security concerns. We also mentioned that the signature in the dtb > > > > makes > > > > little sense since it's difference *per class of boards* and it's not > > > > something we could include in static dtb files, but that lead nowhere... > > > > > > > > As Sughosh already said there are platforms that use the generated > > > > u-boot > > > > dtb and the raw binary to assemble a FIP image. So why exactly adding > > > > the > > > > capsule
Re: [PATCH 5/7] Makefile: Add a target for building capsules
hi Simon, On Mon, 26 Jun 2023 at 17:43, Sughosh Ganu wrote: > > hi Simon, > > On Mon, 26 Jun 2023 at 14:38, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Wed, 21 Jun 2023 at 05:26, Sughosh Ganu wrote: > > > > > > hi Simon, > > > > > > On Mon, 19 Jun 2023 at 18:07, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Thu, 15 Jun 2023 at 17:25, Sughosh Ganu > > > > wrote: > > > > > > > > > > hi Simon, > > > > > > > > > > On Thu, 15 Jun 2023 at 14:44, Simon Glass wrote: > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > On Tue, 13 Jun 2023 at 11:39, Sughosh Ganu > > > > > > wrote: > > > > > > > > > > > > > > Add a target for building EFI capsules. The capsule parameters are > > > > > > > specified through a config file, and the path to the config file > > > > > > > is > > > > > > > specified through CONFIG_EFI_CAPSULE_CFG_FILE. When the config > > > > > > > file is > > > > > > > not specified, the command only builds tools. > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > --- > > > > > > > Makefile | 9 + > > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > > > diff --git a/Makefile b/Makefile > > > > > > > index 10bfaa52ad..96db29aa77 100644 > > > > > > > --- a/Makefile > > > > > > > +++ b/Makefile > > > > > > > @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb > > > > > > > dts/dt.dtb: u-boot > > > > > > > $(Q)$(MAKE) $(build)=dts dtbs > > > > > > > > > > > > > > +quiet_cmd_mkeficapsule = MKEFICAPSULE $@ > > > > > > > +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule $@ > > > > > > > + > > > > > > > +PHONY += capsule > > > > > > > +capsule: tools > > > > > > > +ifneq ($(CONFIG_EFI_CAPSULE_CFG_FILE),"") > > > > > > > + $(call cmd,mkeficapsule) > > > > > > > +endif > > > > > > > + > > > > > > > quiet_cmd_copy = COPY$@ > > > > > > >cmd_copy = cp $< $@ > > > > > > > > > > > > > > -- > > > > > > > 2.34.1 > > > > > > > > > > > > > > > > > > > We should be using binman to build images...you seem to be building > > > > > > something in parallel with that. Can you please take a look at > > > > > > binman? > > > > > > > > > > Again, I had explored using binman for this task. The one issue where > > > > > I find the above flow better is that I can simply build my payload > > > > > image(s) followed by 'make capsule' to generate the capsules for > > > > > earlier generated images. In it's current form, I don't see an easy > > > > > way to enforce this dependency in binman when I want to build the > > > > > payload followed by generation of capsules. I did see the mention of > > > > > encapsulating an entry within another dependent entry, but I think > > > > > that makes the implementation more complex than it ought to be. > > > > > > > > > > I think it is much easier to use the make flow to generate the images > > > > > followed by capsules, instead of tweaking the binman node to first > > > > > generate the payload images, followed by enabling the capsule node to > > > > > build the capsules. If there is an easy way of enforcing this > > > > > dependency, please let me know. Thanks > > > > > > > > Can you share your explorations? I think the capsule should be created > > > > as part of the build, if enabled. Rather than changing the input > > > > files, binman should produce new output files. > > > > > > This is an issue of handling dependencies in binman, and not changing > > > input files. We do not have support for telling binman "build/generate > > > this particular image first before you proceed t
Re: [PATCH 5/7] Makefile: Add a target for building capsules
hi Simon, On Mon, 26 Jun 2023 at 14:38, Simon Glass wrote: > > Hi Sughosh, > > On Wed, 21 Jun 2023 at 05:26, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Mon, 19 Jun 2023 at 18:07, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Thu, 15 Jun 2023 at 17:25, Sughosh Ganu > > > wrote: > > > > > > > > hi Simon, > > > > > > > > On Thu, 15 Jun 2023 at 14:44, Simon Glass wrote: > > > > > > > > > > Hi Sughosh, > > > > > > > > > > On Tue, 13 Jun 2023 at 11:39, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > Add a target for building EFI capsules. The capsule parameters are > > > > > > specified through a config file, and the path to the config file is > > > > > > specified through CONFIG_EFI_CAPSULE_CFG_FILE. When the config file > > > > > > is > > > > > > not specified, the command only builds tools. > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > --- > > > > > > Makefile | 9 + > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > diff --git a/Makefile b/Makefile > > > > > > index 10bfaa52ad..96db29aa77 100644 > > > > > > --- a/Makefile > > > > > > +++ b/Makefile > > > > > > @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb > > > > > > dts/dt.dtb: u-boot > > > > > > $(Q)$(MAKE) $(build)=dts dtbs > > > > > > > > > > > > +quiet_cmd_mkeficapsule = MKEFICAPSULE $@ > > > > > > +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule $@ > > > > > > + > > > > > > +PHONY += capsule > > > > > > +capsule: tools > > > > > > +ifneq ($(CONFIG_EFI_CAPSULE_CFG_FILE),"") > > > > > > + $(call cmd,mkeficapsule) > > > > > > +endif > > > > > > + > > > > > > quiet_cmd_copy = COPY$@ > > > > > >cmd_copy = cp $< $@ > > > > > > > > > > > > -- > > > > > > 2.34.1 > > > > > > > > > > > > > > > > We should be using binman to build images...you seem to be building > > > > > something in parallel with that. Can you please take a look at binman? > > > > > > > > Again, I had explored using binman for this task. The one issue where > > > > I find the above flow better is that I can simply build my payload > > > > image(s) followed by 'make capsule' to generate the capsules for > > > > earlier generated images. In it's current form, I don't see an easy > > > > way to enforce this dependency in binman when I want to build the > > > > payload followed by generation of capsules. I did see the mention of > > > > encapsulating an entry within another dependent entry, but I think > > > > that makes the implementation more complex than it ought to be. > > > > > > > > I think it is much easier to use the make flow to generate the images > > > > followed by capsules, instead of tweaking the binman node to first > > > > generate the payload images, followed by enabling the capsule node to > > > > build the capsules. If there is an easy way of enforcing this > > > > dependency, please let me know. Thanks > > > > > > Can you share your explorations? I think the capsule should be created > > > as part of the build, if enabled. Rather than changing the input > > > files, binman should produce new output files. > > > > This is an issue of handling dependencies in binman, and not changing > > input files. We do not have support for telling binman "build/generate > > this particular image first before you proceed to build the capsules > > using the earlier built images". I am not sure if this can be done in > > a generic manner in binman, so that irrespective of the image being > > generated, it can be specified to build capsules once the capsule > > input images have been generated. > > I'm just not sure what you are getting out here. > > See INPUTS-y for the input files to binman. Then binman uses these to > generate output files. It does not mess with the input files, nor > should it. Please read the top part of the Bi
[PATCH v2 1/8] fdt_add_pubkey: Add support for adding ESL public key under signature node
The fdt_add_pubkey tool is used for adding a public key to the
devicetree, which is then used for verifying the FIT signatures. Add a
function for embedding the public key in the form of an EFI Signature
List(ESL) file as a property under the signature node of the device
tree.
Unlike the public key added for FIT signature verification, the ESL
file contents are added as a whole, as a property under the signature
node in the DTB.
The public key in the ESL form is used by the capsule authentication
feature for authenticating the capsules, prior to update.
Signed-off-by: Sughosh Ganu
---
Changes since V1:
* New patch
* Use fdt_add_pubkey tool for adding the ESL into the dtb instead of
using the shell script used in the earlier version.
tools/Makefile | 2 +-
tools/fdt_add_pubkey.c | 16 +--
tools/fdt_add_pubkey_esl.c | 98 ++
3 files changed, 112 insertions(+), 4 deletions(-)
create mode 100644 tools/fdt_add_pubkey_esl.c
diff --git a/tools/Makefile b/tools/Makefile
index d793cf3bec..a5558eeb4d 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -152,7 +152,7 @@ dumpimage-objs := $(dumpimage-mkimage-objs) dumpimage.o
mkimage-objs := $(dumpimage-mkimage-objs) mkimage.o
fit_info-objs := $(dumpimage-mkimage-objs) fit_info.o
fit_check_sign-objs := $(dumpimage-mkimage-objs) fit_check_sign.o
-fdt_add_pubkey-objs := $(dumpimage-mkimage-objs) fdt_add_pubkey.o
+fdt_add_pubkey-objs := $(dumpimage-mkimage-objs) fdt_add_pubkey.o
fdt_add_pubkey_esl.o
file2include-objs := file2include.o
ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_TOOLS_LIBCRYPTO),)
diff --git a/tools/fdt_add_pubkey.c b/tools/fdt_add_pubkey.c
index 5582d7a8ef..f536ab543b 100644
--- a/tools/fdt_add_pubkey.c
+++ b/tools/fdt_add_pubkey.c
@@ -2,18 +2,21 @@
#include
#include "fit_common.h"
+extern int fdt_embed_esl(const char *esl_file, void *keydest);
+
static const char *cmdname;
static const char *algo_name = "sha1,rsa2048"; /* -a */
static const char *keydir = "."; /* -k */
static const char *keyname = "key"; /* -n */
static const char *require_keys; /* -r */
+static const char *esl_file; /* -e */
static const char *keydest; /* argv[n] */
static void __attribute__((__noreturn__)) print_usage(const char *msg)
{
fprintf(stderr, "Error: %s\n", msg);
- fprintf(stderr, "Usage: %s [-a ] [-k ] [-n ] [-r
]"
+ fprintf(stderr, "Usage: %s [-a ] [-e ] [-k ]
[-n ] [-r ]"
" \n", cmdname);
fprintf(stderr, "Help information: %s [-h]\n", cmdname);
exit(EXIT_FAILURE);
@@ -23,6 +26,7 @@ static void __attribute__((__noreturn__)) print_help(void)
{
fprintf(stderr, "Options:\n"
"\t-aCryptographic algorithm. Optional parameter,
default value: sha1,rsa2048\n"
+ "\t-eEFI Signature List(ESL) file to embed into
the FDT\n"
"\t-k Directory with public key. Optional
parameter, default value: .\n"
"\t-n Public key name. Optional parameter, default
value: key\n"
"\t-r Required: If present this indicates that the
key must be verified for the image / configuration to be considered valid.\n"
@@ -34,7 +38,7 @@ static void process_args(int argc, char *argv[])
{
int opt;
- while ((opt = getopt(argc, argv, "a:k:n:r:h")) != -1) {
+ while ((opt = getopt(argc, argv, "a:e:k:n:r:h")) != -1) {
switch (opt) {
case 'k':
keydir = optarg;
@@ -48,6 +52,9 @@ static void process_args(int argc, char *argv[])
case 'r':
require_keys = optarg;
break;
+ case 'e':
+ esl_file = optarg;
+ break;
case 'h':
print_help();
default:
@@ -106,7 +113,10 @@ static int add_pubkey(struct image_sign_info *info)
if (destfd < 0)
exit(EXIT_FAILURE);
- ret = info->crypto->add_verify_data(info, dest_blob);
+
+ ret = esl_file ? fdt_embed_esl(esl_file, dest_blob) :
+ info->crypto->add_verify_data(info, dest_blob);
+
if (ret == -ENOSPC)
continue;
else if (ret < 0)
diff --git a/tools/fdt_add_pubkey_esl.c b/tools/fdt_add_pubkey_esl.c
new file mode 100644
index 00..de6ee41535
--- /dev/null
+++ b/tools/fdt_add_pubkey_esl.c
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2023 Linaro Limited
+ *
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "mkimage.h"
+
+#define ESL_SIG_NODENAME &qu
[PATCH v2 3/8] test: py: Change capsule authenticate test flow
Currently, the keys and the EFI Signature List(ESL) file used for
testing capsule authentication functionality are being generated after
the u-boot image has been built. The ESL file is then embedded into
the platform's DTB for capsule authentication.
This flow has been changed through an earlier commit, which embeds the
ESL file into the platform's dtb(s) as part of the u-boot build. This
requires generating the keys and the ESL file prior to invoking the
u-boot build.
Bring about the same sequence of generating these files prior to
invoking the u-boot build while testing.
For testing the EFI capsule functionality through manual invocation of
pytest, changes have been made to the configuration to generate the
openssl keys and the ESL file prior to u-boot build. Similar changes
have been made in the CI test environment to generate the keys and the
ESL prior to the u-boot build.
The binman node needed for invoking the corresponding entry module for
embedding the ESL has been added for sandbox to facilitate testing.
Signed-off-by: Sughosh Ganu
---
Changes since V1:
* Add the logic to generate the keys in the yml files which get used
in the CI setup.
* Add a fdt-esl-embed node in sandbox's binman node with capsule
authentication enabled.
.azure-pipelines.yml | 17 ++
.gitlab-ci.yml | 15 +
arch/sandbox/dts/sandbox.dts | 4 ++
arch/sandbox/dts/sandbox_capsule.dtsi| 12
arch/sandbox/dts/test.dts| 4 ++
configs/sandbox_defconfig| 1 +
configs/sandbox_flattree_defconfig | 1 +
test/py/conftest.py | 64
test/py/tests/test_efi_capsule/conftest.py | 37 +++
test/py/tests/test_efi_capsule/signature.dts | 10 ---
10 files changed, 125 insertions(+), 40 deletions(-)
create mode 100644 arch/sandbox/dts/sandbox_capsule.dtsi
delete mode 100644 test/py/tests/test_efi_capsule/signature.dts
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 3c1846a5bc..7681fabdac 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -398,6 +398,14 @@ stages:
wget -O -
https://github.com/riscv/opensbi/releases/download/v0.9/opensbi-0.9-rv-bin.tar.xz
| tar -C /tmp -xJ;
export
OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
fi
+ if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
"sandbox_flattree" ]]; then
+ if [ ! -d "/tmp/capsules/" ]; then
+ mkdir -p /tmp/capsules/;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt
-nodes -days 365;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
/tmp/capsules/SIGNER2.crt -nodes -days 365;
+ cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
/tmp/capsules/SIGNER.esl;
+ fi
+ fi
# the below corresponds to .gitlab-ci.yml "script"
cd ${WORK_DIR}
export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD};
@@ -580,6 +588,15 @@ stages:
cd ${WORK_DIR}
# make environment variables available as tests are running inside a
container
export BUILDMAN="${BUILDMAN}"
+ if [[ "${BUILDMAN}" == "sandbox" ]] || [[ "${BUILDMAN}" == "sandbox
x86" ]]; then
+ if [ ! -d "/tmp/capsules/" ]; then
+ mkdir -p /tmp/capsules/;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt
-nodes -days 365;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj
/CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
/tmp/capsules/SIGNER2.crt -nodes -days 365;
+ cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
/tmp/capsules/SIGNER.esl;
+ fi
+ fi
+
git config --global --add safe.directory ${WORK_DIR}
EOF
cat << "EOF" >> build.sh
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index e6c6ab3586..caf2db9476 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -37,6 +37,14 @@ stages:
export
OPENSBI=/tmp/opensbi-0.9-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
fi
+- if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
"sandbox_flattree" ]]; then
+if [ ! -d "/tmp/capsules/" ]; then
+ mkdir -p /tmp/capsules/;
+ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
-keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days 3
[PATCH v2 6/8] Makefile: Add a target for building capsules
Add a target for building EFI capsules. The capsule parameters are specified through a config file, and the path to the config file is specified through CONFIG_EFI_CAPSULE_CFG_FILE. When the config file is not specified, the command only builds tools. Signed-off-by: Sughosh Ganu --- Changes since V1: * Call the mkeficapsule utility with the cfg-file parameter when building capsules via the config file. Makefile | 9 + 1 file changed, 9 insertions(+) diff --git a/Makefile b/Makefile index 444baaefd0..7d22427699 100644 --- a/Makefile +++ b/Makefile @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb dts/dt.dtb: u-boot $(Q)$(MAKE) $(build)=dts dtbs +quiet_cmd_mkeficapsule = MKEFICAPSULE +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule --cfg-file=$(CONFIG_EFI_CAPSULE_CFG_FILE) + +PHONY += capsule +capsule: tools +ifneq ($(CONFIG_EFI_CAPSULE_CFG_FILE),"") + $(call cmd,mkeficapsule) +endif + quiet_cmd_copy = COPY$@ cmd_copy = cp $< $@ -- 2.34.1
[PATCH v2 2/8] capsule: authenticate: Embed capsule public key in platform's dtb
The EFI capsule authentication logic in u-boot expects the public key in the form of an EFI Signature List(ESL) to be provided as part of the platform's dtb. Currently, the embedding of the ESL file into the dtb needs to be done manually. Use the fdt_add_pubkey tool from binman for embedding the ESL. The capsule update feature is supported for both raw and FIT images. Embedding of the ESL for raw images needs to be done through a binman entry, fdt-esl-embed. For the FIT image, a couple of properties have been added to the fit node which facilitate embedding the ESL into all the DTB's that are packaged into the FIT image. The path to the ESL file is specified through the CONFIG_EFI_CAPSULE_ESL_FILE symbol. Signed-off-by: Sughosh Ganu --- Changes since V1: * Achieve the embedding of the ESL into the DTB through binman * Add an entry type fdt-esl-embed for embedding the ESL for raw images. * Add logic in binman's fit entry type for embedding the ESL into all the DTB's which are part of the FIT image. * Add corresponding documentation entries in binman for the above changes. lib/efi_loader/Kconfig | 11 tools/binman/btool/fdt_add_pubkey.py | 73 + tools/binman/entries.rst | 49 + tools/binman/etype/fdt_esl_embed.py | 80 tools/binman/etype/fit.py| 31 +++ 5 files changed, 244 insertions(+) create mode 100644 tools/binman/btool/fdt_add_pubkey.py create mode 100644 tools/binman/etype/fdt_esl_embed.py diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index c5835e6ef6..1326a1d109 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -234,6 +234,17 @@ config EFI_CAPSULE_MAX Select the max capsule index value used for capsule report variables. This value is used to create CapsuleMax variable. +config EFI_CAPSULE_ESL_FILE + string "Path to the EFI Signature List File" + default "" + depends on EFI_CAPSULE_AUTHENTICATE + help + Provides the absolute path to the EFI Signature List + file which will be embedded in the platform's device + tree and used for capsule authentication at the time + of capsule update. + + config EFI_DEVICE_PATH_TO_TEXT bool "Device path to text protocol" default y diff --git a/tools/binman/btool/fdt_add_pubkey.py b/tools/binman/btool/fdt_add_pubkey.py new file mode 100644 index 00..071ad166ff --- /dev/null +++ b/tools/binman/btool/fdt_add_pubkey.py @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright 2023 Linaro Limited +# +"""Bintool implementation for fdt_add_pubkey tool + +fdt_add_pubkey is a tool used for embedding a public key +into the DTB file. + +Currently, this is being used for embedding the EFI Signature +List(ESL) file into the DTB provided. The contents of the ESL +file get added as a property, capsule-key under the signature +node. + +The following are the command line options to be provided to the tool. +Options: +-aCryptographic algorithm. Optional parameter, default value: sha1,rsa2048 +-eEFI Signature List(ESL) file to embed into the FDT +-k Directory with public key. Optional parameter, default value: . +-n Public key name. Optional parameter, default value: key +-r Required: If present this indicates that the key must be verified for the image / configuration to be considered valid. + FDT blob file for adding of the public key. Required parameter. + +""" + +from binman import bintool + +class Bintoolfdt_add_pubkey(bintool.Bintool): +"""Handles the 'fdt_add_pubkey' tool + +This bintool supports running the fdt_add_pubkey tool for +embedding the public key into the dtb file provided. + +Currently, this is being used for embedding the EFI Signature +List(ESL) file into the DTB provided. +""" +def __init__(self, name): +super().__init__(name, 'Tool for generating adding pubkey to platform dtb') + +def add_esl(self, esl_fname, dtb_fname): +"""Add an ESL public key into the DTB + +Args: +esl_fname: Path to the ESL file +dtb_name: Path to the DTB file + +Returns: +None +""" +args = [ +f'-e', +esl_fname, +dtb_fname +] + +self.run_cmd(*args) + +def fetch(self, method): +"""Fetch handler for fdt_add_pubkey + +This builds the tool from source + +Returns: +tuple: +str: Filename of fetched file to copy to a suitable directory +str: Name of temp directory to remove, or None +""" +if method != bintool.FETCH_BUILD: +
[PATCH v2 5/8] tools: mkeficapsule: Add support for parsing capsule params from config file
Add support for specifying the parameters needed for capsule
generation through a config file, instead of passing them through
command-line. Parameters for more than a single capsule file can be
specified, resulting in generation of multiple capsules through a
single invocation of the command.
This path is to be used for generating capsules through a make target,
with the parameters being parsed from the config file.
Signed-off-by: Sughosh Ganu
---
Changes since V1:
* Add a cfg-file parameter to pass the config file to the mkeficapsule
tool. This results in generation of the same tool image irrespective
of using command-line parameters or config file.
tools/Kconfig | 9 +
tools/Makefile | 1 +
tools/eficapsule.h | 110
tools/mkeficapsule.c | 84 +
tools/mkeficapsule_parse.c | 345 +
5 files changed, 519 insertions(+), 30 deletions(-)
create mode 100644 tools/mkeficapsule_parse.c
diff --git a/tools/Kconfig b/tools/Kconfig
index 539708f277..95f27b7c45 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
optionally sign that file. If you want to enable UEFI capsule
update feature on your target, you certainly need this.
+config EFI_CAPSULE_CFG_FILE
+ string "Path to the EFI Capsule Config File"
+ default ""
+ help
+ Path to the EFI capsule config file which provides the
+ parameters needed to build capsule(s). Parameters can be
+ provided for multiple payloads resulting in corresponding
+ capsule images being generated.
+
menuconfig FSPI_CONF_HEADER
bool "FlexSPI Header Configuration"
help
diff --git a/tools/Makefile b/tools/Makefile
index a5558eeb4d..833d8292e3 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
HOSTLDLIBS_mkeficapsule += \
$(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
+mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
# We build some files with extra pedantic flags to try to minimize things
# that won't build on some weird host compiler -- though there are lots of
diff --git a/tools/eficapsule.h b/tools/eficapsule.h
index 072a4b5598..42e66c6d6a 100644
--- a/tools/eficapsule.h
+++ b/tools/eficapsule.h
@@ -52,6 +52,38 @@ typedef struct {
/* flags */
#define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
+enum capsule_type {
+ CAPSULE_NORMAL_BLOB = 0,
+ CAPSULE_ACCEPT,
+ CAPSULE_REVERT,
+};
+
+/**
+ * struct efi_capsule_params - Capsule parameters
+ * @image_guid: Guid value of the payload input image
+ * @image_index: Image index value
+ * @hardware_instance: Hardware instance to be used for the image
+ * @monotonic_count: Monotonic count value to be used for signed capsule
+ * @privkey_file: Path to private key used in capsule signing
+ * @cert_file: Path to public key certificate used in capsule signing
+ * @input_file: Path to payload input image
+ * @capsule_file: Path to the output capsule file
+ * @oemflags: Oemflags to be populated in the capsule header
+ * @capsule: Capsule Type, normal or accept or revert
+ */
+struct efi_capsule_params {
+ efi_guid_t *image_guid;
+ unsigned long image_index;
+ unsigned long hardware_instance;
+ uint64_t monotonic_count;
+ char *privkey_file;
+ char *cert_file;
+ char *input_file;
+ char *capsule_file;
+ unsigned long oemflags;
+ enum capsule_type capsule;
+};
+
struct efi_capsule_header {
efi_guid_t capsule_guid;
uint32_t header_size;
@@ -113,4 +145,82 @@ struct efi_firmware_image_authentication {
struct win_certificate_uefi_guid auth_info;
} __packed;
+/**
+ * capsule_with_cfg_file() - Generate capsule from config file
+ * @cfg_file: Path to the config file
+ *
+ * Parse the capsule parameters from the config file and use the
+ * parameters for generating one or more capsules.
+ *
+ * Return: None
+ *
+ */
+void capsule_with_cfg_file(const char *cfg_file);
+
+/**
+ * convert_uuid_to_guid() - convert UUID to GUID
+ * @buf: UUID binary
+ *
+ * UUID and GUID have the same data structure, but their binary
+ * formats are different due to the endianness. See lib/uuid.c.
+ * Since uuid_parse() can handle only UUID, this function must
+ * be called to get correct data for GUID when parsing a string.
+ *
+ * The correct data will be returned in @buf.
+ */
+void convert_uuid_to_guid(unsigned char *buf);
+
+/**
+ * create_empty_capsule() - Generate an empty capsule
+ * @path: Path to the empty capsule file to be generated
+ * @guid: Guid value of the image for which empty capsule is generated
+ * @fw_accept: Flag to specify whether to generate accept or revert capsule
+ *
+ * Generate an empty capsule, either an accept
[PATCH v2 7/8] test: efi_capsule: Test capsule generation from config file
Support has been added to generate capsules through parameters
specified in the config file. To bring this under the testing ambit,
make changes in the EFI capsule test logic to generate the capsule
files by parsing the config file, when the path to the config file is
specified.
Signed-off-by: Sughosh Ganu
---
Changes since V1: None
configs/sandbox_defconfig | 1 +
test/py/tests/test_efi_capsule/conftest.py| 107 +++---
.../test_efi_capsule/sandbox_capsule_cfg.txt | 75
3 files changed, 139 insertions(+), 44 deletions(-)
create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index d8a2386bb0..ba26816898 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -340,6 +340,7 @@ CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
+CONFIG_EFI_CAPSULE_CFG_FILE="/tmp/capsules/sandbox_capsule_cfg.txt"
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index cec733942f..5d7f05eef8 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -42,64 +42,83 @@ def efi_capsule_data(request, u_boot_config):
check_call('cd %s; %s/tools/mkimage -f uboot_bin_env.its
uboot_bin_env.itb' %
(data_dir, u_boot_config.build_dir),
shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
09D7CF52-0720-4710-91D1-08469B7FE9C8 u-boot.bin.new Test01' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 2 --guid
5A7021F5-FEF2-48B4-AABA-832E777418C0 u-boot.env.new Test02' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
058B7D83-50D5-4C47-A195-60D86AD341C4 u-boot.bin.new Test03' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
3673B45D-6A7C-46F3-9E60-ADABB03F7937 uboot_bin_env.itb Test04' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
058B7D83-50D5-4C47-A195-60D86AD341C4 uboot_bin_env.itb Test05' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
capsule_auth_enabled = u_boot_config.buildconfig.get(
'config_efi_capsule_authenticate')
if capsule_auth_enabled:
capsules_path_dir = '/tmp/capsules/'
-check_call('mv %s/* %s ' %(capsules_path_dir, data_dir),
shell=True)
+check_call('mv %s* %s/ ' %(capsules_path_dir, data_dir),
shell=True)
check_call('cp %s/arch/sandbox/dts/test.dtb %s/test_sig.dtb' %
(u_boot_config.build_dir, data_dir), shell=True)
-# raw firmware signed with proper key
-check_call('cd %s; '
- '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
-'--private-key SIGNER.key --certificate SIGNER.crt
'
-'--guid 09D7CF52-0720-4710-91D1-08469B7FE9C8 '
-'u-boot.bin.new Test11'
- % (data_dir, u_boot_config.build_dir),
+cfg_file = u_boot_config.buildconfig.get(
+'config_efi_capsule_cfg_file')[1:-1]
+if cfg_file:
+capsules_path_dir = '/tmp/capsules/'
+check_call('mkdir -p %s ;'
+ 'cp -a %s/* %s/' % (capsules_path_dir, data_dir,
capsules_path_dir),
shell=True)
-# raw firmware signed with *mal* key
-check_call('cd %s; '
- '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
-'--private-key SIGNER2.key '
-'--certificate SIGNER2.crt '
-'--guid 09D7CF52-0720-4710-91D1-08469B7FE9C8 '
-'u-boot.bin.new Test12'
- % (data_dir, u_boot_config.build_dir),
+check_call(' cp
%s/test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt %s'
+ % (u_boot_config.source_dir, capsules_path_dir),
shell=True)
-# FIT firmware signed with proper key
check_call('cd %s; '
- '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
-'--private-key SIGNER.key --certificate SIGNER.crt
'
-'--gui
[PATCH v2 4/8] doc: capsule: Document the new mechanism to embed ESL file into dtb
Update the document to specify how the EFI Signature List(ESL) file
can be embedded into the platform's dtb as part of the u-boot build.
Signed-off-by: Sughosh Ganu
---
Changes since V1: None
doc/develop/uefi/uefi.rst | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index ffe25ca231..f96762af39 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -495,20 +495,11 @@ and used by the steps highlighted below.
...
}
-You can do step-4 manually with
-
-.. code-block:: console
-
-$ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
-$ fdtoverlay -i orig.dtb -o new.dtb -v signature.dtbo
-
-where signature.dts looks like::
-
-&{/} {
-signature {
-capsule-key = /incbin/("CRT.esl");
-};
-};
+You can perform step-4 by defining the Kconfig symbol
+CONFIG_EFI_CAPSULE_ESL_FILE. This symbol defines the path to the esl
+file generated in step-2. Once the symbol has been populated with the
+path to the esl file, the esl file will automatically get embedded
+into the platform's dtb as part of u-boot build.
Executing the boot manager
~~
--
2.34.1
[PATCH v2 0/8] Integrate EFI capsule tasks into u-boot's build flow
This patchset aims to bring two capsule related tasks under the u-boot build flow. One is the embedding of the public key into the platform's dtb. The public key is in the form of an EFI Signature List(ESL) file and is used for capsule authentication. This is being achieved through binman, with an entry type added for raw images, and properties added to the binman fit entry type to enable embedding the ESL into all the DTB's that get packaged into the FIT. The path to the ESL file is being provided through a Kconfig symbol(CONFIG_EFI_CAPSULE_ESL_FILE). Changes have also been made to the test flow so that the keys used for signing the capsule, and the ESL file, are generated prior to invoking the u-boot's build, which enables embedding the ESL file into the dtb as part of the u-boot build flow. The other task is to add a make target for generating capsules. This is being achieved by adding support for parsing a config file to get the capsule generation parameters. Multiple payloads can be specified, resulting in generation of multiple capsules with a single invocation of the command. The path to the config file is to be specified through a Kconfig symbol(CONFIG_EFI_CAPSULE_CFG_FILE). Changes have been made to the efi capsule test setup, whereby, with the above config symbol having been populated, the capsule files are generated through the make capsule command. The requisite config file has been placed under the test/py/tests/test_efi_capsule/ directory, which results in generation of the same set of capsule files. Currently, the capsule authentication feature is tested on the sandbox and sandbox_flattree variants. The capsule generation through config file is enabled for the sandbox variant, with the sandbox_flattree variant generating capsules through the command-line parameters. The document has been updated to reflect the above changes. Changes since V1: At a broad level, this version takes a stab at using binman for embedding the ESL file into the DTB's. This is being done for both raw images and FIT images. I had mentioned the issue of dependency when using binman for generating capsules[1], which is why I have stuck with using the make target for generating capsules. [1] - https://lists.denx.de/pipermail/u-boot/2023-June/520814.html * New patch * Use fdt_add_pubkey tool for adding the ESL into the dtb instead of using the shell script used in the earlier version. * Achieve the embedding of the ESL into the DTB through binman * Add an entry type fdt-esl-embed for embedding the ESL for raw images. * Add logic in binman's fit entry type for embedding the ESL into all the DTB's which are part of the FIT image. * Add corresponding documentation entries in binman for the above changes. * Add the logic to generate the keys in the yml files which get used in the CI setup. * Add a fdt-esl-embed node in sandbox's binman node with capsule authentication enabled. * Add a cfg-file parameter to pass the config file to the mkeficapsule tool. This results in generation of the same tool image irrespective of using command-line parameters or config file. * Call the mkeficapsule utility with the cfg-file parameter when building capsules via the config file. Sughosh Ganu (8): fdt_add_pubkey: Add support for adding ESL public key under signature node capsule: authenticate: Embed capsule public key in platform's dtb test: py: Change capsule authenticate test flow doc: capsule: Document the new mechanism to embed ESL file into dtb tools: mkeficapsule: Add support for parsing capsule params from config file Makefile: Add a target for building capsules test: efi_capsule: Test capsule generation from config file doc: Add documentation to describe capsule config file format .azure-pipelines.yml | 17 + .gitlab-ci.yml| 15 + Makefile | 9 + arch/sandbox/dts/sandbox.dts | 4 + arch/sandbox/dts/sandbox_capsule.dtsi | 12 + arch/sandbox/dts/test.dts | 4 + configs/sandbox_defconfig | 2 + configs/sandbox_flattree_defconfig| 1 + doc/develop/uefi/uefi.rst | 83 - lib/efi_loader/Kconfig| 11 + test/py/conftest.py | 64 test/py/tests/test_efi_capsule/conftest.py| 142 --- .../test_efi_capsule/sandbox_capsule_cfg.txt | 75 test/py/tests/test_efi_capsule/signature.dts | 10 - tools/Kconfig | 9 + tools/Makefile| 3 +- tools/binman/btool/fdt_add_pubkey.py | 73 tools/binman/entries.rst | 49 +++ tools/binman/etype/fdt_esl_embed.py | 80 tools/binman/etype/fit.py | 31 ++ tools/eficapsule.h| 110 ++ tools/fdt_add_pubkey.c
[PATCH v2 8/8] doc: Add documentation to describe capsule config file format
The UEFI capsule can be generated either through command-line
parameters, or, by specifying those in a config file. Add
documentation to describe the format of the config file.
Signed-off-by: Sughosh Ganu
---
Changes since V1: None
doc/develop/uefi/uefi.rst | 64 +++
1 file changed, 64 insertions(+)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index f96762af39..09b32c9921 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -442,6 +442,70 @@ following command can be issued
--guid c1b629f1-ce0e-4894-82bf-f0a38387e630 \
optee.bin optee.capsule
+Or alternatively, the capsule can be generated through a make target
+
+.. code-block:: bash
+
+$ make capsule
+
+Issuing the above make command requires specifying the capsule
+parameters through a config file instead. The Kconfig symbol
+CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the path to
+the config file.
+
+The config file describes the parameters that are used for generating
+one or more capsules. The parameters for a given capsule file are
+specified within curly braces, in the form of "key:value" pairs. All
+the parameters that are currently supported by the mkeficapsule tool
+can be specified through the config file.
+
+The following are some example payload parameters specified through
+the config file.
+
+.. code-block:: none
+
+ {
+ image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
+ hardware-instance: 0
+ monotonic-count: 1
+ payload: u-boot.bin
+ image-index: 1
+ private-key: /path/to/priv/key
+ pub-key-cert: /path/to/pub/key
+ capsule: u-boot.capsule
+ }
+ {
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ hardware-instance: 0
+ payload: u-boot.itb
+ image-index: 2
+ oemflags: 0x8000
+ capsule: fit.capsule
+ }
+ {
+ capsule-type: accept
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ capsule: accept.capsule
+ }
+ {
+ capsule-type: revert
+ capsule: revert.capsule
+ }
+
+The following are the keys that specify the capsule parameters
+
+..code-block:: none
+
+image-guid: Image GUID
+image-index: Image index value
+private-key: Path to the private key file used for capsule signing
+pub-key-cert: Path to the public key crt file used for capsule signing
+payload: Path to the capsule payload file
+capsule: Path to the output capsule file that is generated
+hardware-instance: Hardware Instance value
+monotonic-count: Monotonic count value
+capsule-type: Specifies capsule type. normal(default), accept or revert
+oemflags: 16bit Oemflags value to be used(populated in capsule header)
Enabling Capsule Authentication
***
--
2.34.1
Re: [PATCH 5/7] Makefile: Add a target for building capsules
hi Simon, On Mon, 19 Jun 2023 at 18:07, Simon Glass wrote: > > Hi Sughosh, > > On Thu, 15 Jun 2023 at 17:25, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Thu, 15 Jun 2023 at 14:44, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Tue, 13 Jun 2023 at 11:39, Sughosh Ganu > > > wrote: > > > > > > > > Add a target for building EFI capsules. The capsule parameters are > > > > specified through a config file, and the path to the config file is > > > > specified through CONFIG_EFI_CAPSULE_CFG_FILE. When the config file is > > > > not specified, the command only builds tools. > > > > > > > > Signed-off-by: Sughosh Ganu > > > > --- > > > > Makefile | 9 + > > > > 1 file changed, 9 insertions(+) > > > > > > > > diff --git a/Makefile b/Makefile > > > > index 10bfaa52ad..96db29aa77 100644 > > > > --- a/Makefile > > > > +++ b/Makefile > > > > @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb > > > > dts/dt.dtb: u-boot > > > > $(Q)$(MAKE) $(build)=dts dtbs > > > > > > > > +quiet_cmd_mkeficapsule = MKEFICAPSULE $@ > > > > +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule $@ > > > > + > > > > +PHONY += capsule > > > > +capsule: tools > > > > +ifneq ($(CONFIG_EFI_CAPSULE_CFG_FILE),"") > > > > + $(call cmd,mkeficapsule) > > > > +endif > > > > + > > > > quiet_cmd_copy = COPY$@ > > > >cmd_copy = cp $< $@ > > > > > > > > -- > > > > 2.34.1 > > > > > > > > > > We should be using binman to build images...you seem to be building > > > something in parallel with that. Can you please take a look at binman? > > > > Again, I had explored using binman for this task. The one issue where > > I find the above flow better is that I can simply build my payload > > image(s) followed by 'make capsule' to generate the capsules for > > earlier generated images. In it's current form, I don't see an easy > > way to enforce this dependency in binman when I want to build the > > payload followed by generation of capsules. I did see the mention of > > encapsulating an entry within another dependent entry, but I think > > that makes the implementation more complex than it ought to be. > > > > I think it is much easier to use the make flow to generate the images > > followed by capsules, instead of tweaking the binman node to first > > generate the payload images, followed by enabling the capsule node to > > build the capsules. If there is an easy way of enforcing this > > dependency, please let me know. Thanks > > Can you share your explorations? I think the capsule should be created > as part of the build, if enabled. Rather than changing the input > files, binman should produce new output files. This is an issue of handling dependencies in binman, and not changing input files. We do not have support for telling binman "build/generate this particular image first before you proceed to build the capsules using the earlier built images". I am not sure if this can be done in a generic manner in binman, so that irrespective of the image being generated, it can be specified to build capsules once the capsule input images have been generated. > > We are trying to remove most of the output logic in Makefile. It > should just be producing input files for binman. I understand. However, like I mentioned above, as of now, we don't have a way of handling dependencies in binman, at least in a generic manner. Once this support gets added, I know that it would be trivial to add support for building capsules in binman. -sughosh
Re: [PATCH 1/7] capsule: authenticate: Embed capsule public key in platform's dtb
hi Simon,
On Mon, 19 Jun 2023 at 18:07, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Thu, 15 Jun 2023 at 17:11, Sughosh Ganu wrote:
> >
> > hi Simon,
> >
> > On Thu, 15 Jun 2023 at 14:44, Simon Glass wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Tue, 13 Jun 2023 at 11:41, Sughosh Ganu
> > > wrote:
> > > >
> > > > The EFI capsule authentication logic in u-boot expects the public key
> > > > in the form of an EFI Signature List(ESL) to be provided as part of
> > > > the platform's dtb. Currently, the embedding of the ESL file into the
> > > > dtb needs to be done manually.
> > > >
> > > > Add a script for embedding the ESL used for capsule authentication in
> > > > the platform's dtb, and call this as part of building the dtb(s). This
> > > > brings the embedding of the ESL in the dtb into the u-boot build flow.
> > > >
> > > > The path to the ESL file is specified through the
> > > > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > lib/efi_loader/Kconfig | 11 +++
> > > > scripts/Makefile.lib | 8
> > > > scripts/embed_capsule_key.sh | 25 +
> > > > 3 files changed, 44 insertions(+)
> > > > create mode 100755 scripts/embed_capsule_key.sh
> > > >
> > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > index c5835e6ef6..1326a1d109 100644
> > > > --- a/lib/efi_loader/Kconfig
> > > > +++ b/lib/efi_loader/Kconfig
> > > > @@ -234,6 +234,17 @@ config EFI_CAPSULE_MAX
> > > > Select the max capsule index value used for capsule report
> > > > variables. This value is used to create CapsuleMax variable.
> > > >
> > > > +config EFI_CAPSULE_ESL_FILE
> > > > + string "Path to the EFI Signature List File"
> > > > + default ""
> > > > + depends on EFI_CAPSULE_AUTHENTICATE
> > > > + help
> > > > + Provides the absolute path to the EFI Signature List
> > > > + file which will be embedded in the platform's device
> > > > + tree and used for capsule authentication at the time
> > > > + of capsule update.
> > > > +
> > > > +
> > > > config EFI_DEVICE_PATH_TO_TEXT
> > > > bool "Device path to text protocol"
> > > > default y
> > > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > > > index 7b27224b5d..a4083d0a26 100644
> > > > --- a/scripts/Makefile.lib
> > > > +++ b/scripts/Makefile.lib
> > > > @@ -192,6 +192,8 @@ dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp
> > > > -nostdinc\
> > > > -D__ASSEMBLY__
> > > > \
> > > > -undef -D__DTS__
> > > >
> > > > +export dtc_cpp_flags
> > > > +
> > > > # Finds the multi-part object the current object will be linked into
> > > > modname-multi = $(sort $(foreach m,$(multi-used),\
> > > > $(if $(filter $(subst $(obj)/,,$*.o), $($(m:.o=-objs))
> > > > $($(m:.o=-y))),$(m:.o=
> > > > @@ -315,6 +317,9 @@ ifeq ($(CONFIG_OF_LIBFDT_OVERLAY),y)
> > > > DTC_FLAGS += -@
> > > > endif
> > > >
> > > > +quiet_cmd_embedcapsulekey = EMBEDCAPSULEKEY $@
> > > > +cmd_embedcapsulekey = $(srctree)/scripts/embed_capsule_key.sh $@
> > > > +
> > > > quiet_cmd_dtc = DTC $@
> > > > # Modified for U-Boot
> > > > # Bring in any U-Boot-specific include at the end of the file
> > > > @@ -333,6 +338,9 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> > > >
> > > > $(obj)/%.dtb: $(src)/%.dts FORCE
> > > > $(call if_changed_dep,dtc)
> > > > +ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
> > > > + $(call cmd,embedcapsulekey,$@)
> > > > +endif
> > > >
> > > > pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
> > > > dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
> > > > diff --git a/scripts/embed_capsule_key.sh b/scripts/embed_capsule_key.sh
> > > > new file mode 100755
> >
Re: [PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
hi Malte,
On Fri, 16 Jun 2023 at 18:42, Schmidt, Malte
wrote:
>
> Hi sughosh,
>
> Am 16.06.2023 um 08:35 schrieb Sughosh Ganu:
>
> On Fri, 16 Jun 2023 at 10:48, Takahiro Akashi
> wrote:
>
> On Fri, Jun 16, 2023 at 10:37:01AM +0530, Sughosh Ganu wrote:
>
> hi Takahiro,
>
> On Fri, 16 Jun 2023 at 10:16, Takahiro Akashi
> wrote:
>
> Hi Sughosh,
>
> On Fri, Jun 16, 2023 at 09:56:33AM +0530, Sughosh Ganu wrote:
>
> On Thu, 15 Jun 2023 at 11:19, Takahiro Akashi
> wrote:
>
> On Thu, Jun 15, 2023 at 10:09:06AM +0530, Sughosh Ganu wrote:
>
> On Wed, 14 Jun 2023 at 11:23, Takahiro Akashi
> wrote:
>
> On Wed, Jun 14, 2023 at 10:56:23AM +0530, Sughosh Ganu wrote:
>
> hi Takahiro,
>
> On Wed, 14 Jun 2023 at 09:09, Takahiro Akashi
> wrote:
>
> Hi Sughosh,
>
> I think this is a good extension to mkeficapsule, but
>
> On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote:
>
> Add support for specifying the parameters needed for capsule
> generation through a config file, instead of passing them through
> command-line. Parameters for more than a single capsule file can be
> specified, resulting in generation of multiple capsules through a
> single invocation of the command.
>
> This path is to be used for generating capsules through a make target,
> with the parameters being parsed from the config file.
>
> Signed-off-by: Sughosh Ganu
> ---
> tools/Kconfig | 9 +
> tools/Makefile | 1 +
> tools/eficapsule.h | 110
> tools/mkeficapsule.c | 106 +++-
> tools/mkeficapsule_parse.c | 345 +
> 5 files changed, 531 insertions(+), 40 deletions(-)
> create mode 100644 tools/mkeficapsule_parse.c
>
> diff --git a/tools/mkeficapsule_parse.c b/tools/mkeficapsule_parse.c
> new file mode 100644
> index 00..ef4f3f6705
> --- /dev/null
> +++ b/tools/mkeficapsule_parse.c
> @@ -0,0 +1,345 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2023 Linaro Limited
> + */
> +
> +/*
> + * The code in this file adds parsing ability to the mkeficapsule
> + * tool. This allows specifying parameters needed to build the capsule
> + * through the config file instead of specifying them on the command-line.
> + * Parameters can be specified for more than one payload, generating the
> + * corresponding capsule files.
> + *
> + * The parameters are specified in a "key:value" pair. All the parameters
> + * that are currently supported by the mkeficapsule tool can be specified
> + * in the config file.
> + *
> + * The example below shows four payloads. The first payload is an example
> + * of generating a signed capsule. The second payload is an example of
> + * generating an unsigned capsule. The third payload is an accept empty
> + * capsule, while the fourth payload is the revert empty capsule, used
> + * for the multi-bank firmware update feature.
> + *
> + * This functionality can be easily extended to generate a single capsule
> + * comprising multiple payloads.
> +
> + {
> + image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
> + hardware-instance: 0
> + monotonic-count: 1
> + payload: u-boot.bin
> + image-index: 1
> + private-key: /path/to/priv/key
> + pub-key-cert: /path/to/pub/key
> + capsule: u-boot.capsule
> + }
> + {
> + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
> + hardware-instance: 0
> + payload: u-boot.itb
> + image-index: 2
> + oemflags: 0x8000
> + capsule: fit.capsule
> + }
> + {
> + capsule-type: accept
> + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
> + capsule: accept.capsule
> + }
> + {
> + capsule-type: revert
> + capsule: revert.capsule
> + }
> +*/
> +
>
> If i understand it correctly the EDK2 GenerateCapsule tool allows for multiple
> payloads inside one capsule by specifying a list of payloads in the JSON-file.
> I think something similar should be done here to support multiple payloads
> inside one capsule. What about something like this:
>
> {
>
> content: [{
> image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
> hardware-instance: 0
> monotonic-count: 1
> payload: u-boot.bin
> image-index: 1
> },{
>
> image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
> hardware-instance: 1
> monotonic-count: 1
> payload: boot.bin
> image-index: 2
> }],
>
> private-key: /path/to/priv/key
> pub-key-cert: /path/to/pub/key
> capsule: u-boot
Re: [PATCH 2/5] mkeficapsule: add support for multiple payloads inside capsule
On Sat, 17 Jun 2023 at 06:26, AKASHI Takahiro
wrote:
>
> On Fri, Jun 16, 2023 at 06:02:52PM +0530, Sughosh Ganu wrote:
> > On Fri, 16 Jun 2023 at 17:56, Sughosh Ganu wrote:
> > >
> > > hi Stefan,
> > >
> > > On Fri, 16 Jun 2023 at 17:04, Stefan Herbrechtsmeier
> > > wrote:
> > > >
> > > > From: Malte Schmidt
> > > >
> > > > The UEFI [1] specification allows multiple payloads inside the capsule
> > > > body. Add support for this. The command line arguments are kept
> > > > backwards-compatible.
> > > >
> > > > [1] https://uefi.org/specs/UEFI/2.10/index.html
> > >
> > > I am trying to upstream support for specifying the capsule parameters
> > > for multiple payloads through a config file [1]. This is on similar
> > > lines to the support in the Edk2 GenerateCapule tool where multiple
> > > payloads can be specified through a json file. I think you can base
> > > your changes on my series.
> >
> > Btw, with the support being added for getting the capsule parameters
> > through a config file, I believe your changes would be pretty much
> > simplified. Instead of passing all those parameters through the
> > command line, they can instead be read from the config file and used
> > to generate a single capsule file consisting of multiple payloads.
> > That would be a much simpler implementation.
>
> As I said in my reply to the patch[0/5], I don't think we have a strong
> reason to support multiple images because there is already a FIT-based
> capsule support.
> That said, if there is a good reason to do so, Sughosh's suggestion
> makes much sense to me.
>
> BTW, sughosh's patch implements yet another key:value format for
> config files. I wondered if we could use a generic (standardized) format,
> like a device tree or yaml, or others.
I chose the key:value pairs primarily because I wanted to keep the
syntax of the config file as similar to the one in EDK2 as possible. I
believe keeping the format simple is better especially when we are not
dealing with multiple values, or an array of u32 cells like in device
tree.
-sughosh
>
> -Takahiro Akashi
>
>
>
> > -sughosh
> >
> > >
> > > -sughosh
> > >
> > > [1] -
> > > https://lore.kernel.org/u-boot/20230613103806.812065-1-sughosh.g...@linaro.org/T/#mc8c0500863bd3a1580c572679370a565f8d7f2c8
> > >
> > > >
> > > > Signed-off-by: Malte Schmidt
> > > > Signed-off-by: Stefan Herbrechtsmeier
> > > >
> > > > ---
> > > >
> > > > tools/eficapsule.h | 5 -
> > > > tools/mkeficapsule.c | 636 ---
> > > > 2 files changed, 475 insertions(+), 166 deletions(-)
> > > >
> > > > diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> > > > index 753fb73313..001af3217c 100644
> > > > --- a/tools/eficapsule.h
> > > > +++ b/tools/eficapsule.h
> > > > @@ -138,9 +138,4 @@ struct fmp_payload_header {
> > > > uint32_t lowest_supported_version;
> > > > };
> > > >
> > > > -struct fmp_payload_header_params {
> > > > - bool have_header;
> > > > - uint32_t fw_version;
> > > > -};
> > > > -
> > > > #endif /* _EFI_CAPSULE_H */
> > > > diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> > > > index b8db00b16b..1a4de0f092 100644
> > > > --- a/tools/mkeficapsule.c
> > > > +++ b/tools/mkeficapsule.c
> > > > @@ -29,7 +29,7 @@ static const char *tool_name = "mkeficapsule";
> > > > efi_guid_t efi_guid_fm_capsule =
> > > > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> > > > efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> > > >
> > > > -static const char *opts_short = "g:i:I:v:p:c:m:o:dhAR";
> > > > +static const char *opts_short = "g:i:b:I:v:p:c:m:o:dhAR";
> > > >
> > > > enum {
> > > > CAPSULE_NORMAL_BLOB = 0,
> > > > @@ -40,6 +40,7 @@ enum {
> > > > static struct option options[] = {
> > > > {"guid", required_argument, NULL, 'g'},
> > > > {"index", required_argument, NULL, 'i'},
> > > > + {"image_blob", required_argument, NULL, 'b'},
> > > > {"instance", required_argument, NULL, 'I'},
> > > > {"fw-ver
Re: [PATCH 2/5] mkeficapsule: add support for multiple payloads inside capsule
On Fri, 16 Jun 2023 at 17:56, Sughosh Ganu wrote:
>
> hi Stefan,
>
> On Fri, 16 Jun 2023 at 17:04, Stefan Herbrechtsmeier
> wrote:
> >
> > From: Malte Schmidt
> >
> > The UEFI [1] specification allows multiple payloads inside the capsule
> > body. Add support for this. The command line arguments are kept
> > backwards-compatible.
> >
> > [1] https://uefi.org/specs/UEFI/2.10/index.html
>
> I am trying to upstream support for specifying the capsule parameters
> for multiple payloads through a config file [1]. This is on similar
> lines to the support in the Edk2 GenerateCapule tool where multiple
> payloads can be specified through a json file. I think you can base
> your changes on my series.
Btw, with the support being added for getting the capsule parameters
through a config file, I believe your changes would be pretty much
simplified. Instead of passing all those parameters through the
command line, they can instead be read from the config file and used
to generate a single capsule file consisting of multiple payloads.
That would be a much simpler implementation.
-sughosh
>
> -sughosh
>
> [1] -
> https://lore.kernel.org/u-boot/20230613103806.812065-1-sughosh.g...@linaro.org/T/#mc8c0500863bd3a1580c572679370a565f8d7f2c8
>
> >
> > Signed-off-by: Malte Schmidt
> > Signed-off-by: Stefan Herbrechtsmeier
> >
> > ---
> >
> > tools/eficapsule.h | 5 -
> > tools/mkeficapsule.c | 636 ---
> > 2 files changed, 475 insertions(+), 166 deletions(-)
> >
> > diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> > index 753fb73313..001af3217c 100644
> > --- a/tools/eficapsule.h
> > +++ b/tools/eficapsule.h
> > @@ -138,9 +138,4 @@ struct fmp_payload_header {
> > uint32_t lowest_supported_version;
> > };
> >
> > -struct fmp_payload_header_params {
> > - bool have_header;
> > - uint32_t fw_version;
> > -};
> > -
> > #endif /* _EFI_CAPSULE_H */
> > diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> > index b8db00b16b..1a4de0f092 100644
> > --- a/tools/mkeficapsule.c
> > +++ b/tools/mkeficapsule.c
> > @@ -29,7 +29,7 @@ static const char *tool_name = "mkeficapsule";
> > efi_guid_t efi_guid_fm_capsule = EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> > efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> >
> > -static const char *opts_short = "g:i:I:v:p:c:m:o:dhAR";
> > +static const char *opts_short = "g:i:b:I:v:p:c:m:o:dhAR";
> >
> > enum {
> > CAPSULE_NORMAL_BLOB = 0,
> > @@ -40,6 +40,7 @@ enum {
> > static struct option options[] = {
> > {"guid", required_argument, NULL, 'g'},
> > {"index", required_argument, NULL, 'i'},
> > + {"image_blob", required_argument, NULL, 'b'},
> > {"instance", required_argument, NULL, 'I'},
> > {"fw-version", required_argument, NULL, 'v'},
> > {"private-key", required_argument, NULL, 'p'},
> > @@ -55,21 +56,22 @@ static struct option options[] = {
> >
> > static void print_usage(void)
> > {
> > - fprintf(stderr, "Usage: %s [options] \n"
> > + fprintf(stderr, "Usage: %s [options] [] \n"
> > "Options:\n"
> >
> > - "\t-g, --guid guid for image blob type\n"
> > - "\t-i, --index update image index\n"
> > - "\t-I, --instanceupdate hardware instance\n"
> > - "\t-v, --fw-version firmware version\n"
> > - "\t-p, --private-key private key file\n"
> > - "\t-c, --certificate signer's certificate
> > file\n"
> > - "\t-m, --monotonic-count monotonic count\n"
> > - "\t-d, --dump_sig dump signature (*.p7)\n"
> > - "\t-A, --fw-accept firmware accept capsule, requires GUID,
> > no image blob\n"
> > - "\t-R, --fw-revert firmware revert capsule, takes no GUID,
> > no image blob\n"
> > - "\t-o, --capoemflag Capsule OEM Flag, an integer between
> > 0x and 0x\n"
> > - "\t-h, --help print a help message\n",
> > + "\t-g, --guidcomma-separated list of
> > guids for image blob types\n"
> > +
Re: [PATCH 2/5] mkeficapsule: add support for multiple payloads inside capsule
hi Stefan,
On Fri, 16 Jun 2023 at 17:04, Stefan Herbrechtsmeier
wrote:
>
> From: Malte Schmidt
>
> The UEFI [1] specification allows multiple payloads inside the capsule
> body. Add support for this. The command line arguments are kept
> backwards-compatible.
>
> [1] https://uefi.org/specs/UEFI/2.10/index.html
I am trying to upstream support for specifying the capsule parameters
for multiple payloads through a config file [1]. This is on similar
lines to the support in the Edk2 GenerateCapule tool where multiple
payloads can be specified through a json file. I think you can base
your changes on my series.
-sughosh
[1] -
https://lore.kernel.org/u-boot/20230613103806.812065-1-sughosh.g...@linaro.org/T/#mc8c0500863bd3a1580c572679370a565f8d7f2c8
>
> Signed-off-by: Malte Schmidt
> Signed-off-by: Stefan Herbrechtsmeier
> ---
>
> tools/eficapsule.h | 5 -
> tools/mkeficapsule.c | 636 ---
> 2 files changed, 475 insertions(+), 166 deletions(-)
>
> diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> index 753fb73313..001af3217c 100644
> --- a/tools/eficapsule.h
> +++ b/tools/eficapsule.h
> @@ -138,9 +138,4 @@ struct fmp_payload_header {
> uint32_t lowest_supported_version;
> };
>
> -struct fmp_payload_header_params {
> - bool have_header;
> - uint32_t fw_version;
> -};
> -
> #endif /* _EFI_CAPSULE_H */
> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> index b8db00b16b..1a4de0f092 100644
> --- a/tools/mkeficapsule.c
> +++ b/tools/mkeficapsule.c
> @@ -29,7 +29,7 @@ static const char *tool_name = "mkeficapsule";
> efi_guid_t efi_guid_fm_capsule = EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
>
> -static const char *opts_short = "g:i:I:v:p:c:m:o:dhAR";
> +static const char *opts_short = "g:i:b:I:v:p:c:m:o:dhAR";
>
> enum {
> CAPSULE_NORMAL_BLOB = 0,
> @@ -40,6 +40,7 @@ enum {
> static struct option options[] = {
> {"guid", required_argument, NULL, 'g'},
> {"index", required_argument, NULL, 'i'},
> + {"image_blob", required_argument, NULL, 'b'},
> {"instance", required_argument, NULL, 'I'},
> {"fw-version", required_argument, NULL, 'v'},
> {"private-key", required_argument, NULL, 'p'},
> @@ -55,21 +56,22 @@ static struct option options[] = {
>
> static void print_usage(void)
> {
> - fprintf(stderr, "Usage: %s [options] \n"
> + fprintf(stderr, "Usage: %s [options] [] \n"
> "Options:\n"
>
> - "\t-g, --guid guid for image blob type\n"
> - "\t-i, --index update image index\n"
> - "\t-I, --instanceupdate hardware instance\n"
> - "\t-v, --fw-version firmware version\n"
> - "\t-p, --private-key private key file\n"
> - "\t-c, --certificate signer's certificate
> file\n"
> - "\t-m, --monotonic-count monotonic count\n"
> - "\t-d, --dump_sig dump signature (*.p7)\n"
> - "\t-A, --fw-accept firmware accept capsule, requires GUID,
> no image blob\n"
> - "\t-R, --fw-revert firmware revert capsule, takes no GUID,
> no image blob\n"
> - "\t-o, --capoemflag Capsule OEM Flag, an integer between
> 0x and 0x\n"
> - "\t-h, --help print a help message\n",
> + "\t-g, --guidcomma-separated list of
> guids for image blob types\n"
> + "\t-i, --index comma-separated list of
> update image indices\n"
> + "\t-b, --image_blob comma-separated list of
> image blobs\n"
> + "\t-I, --instancecomma-separated list of
> update hardware instances\n"
> + "\t-v, --fw-version comma-separated list of
> firmware versions\n"
> + "\t-p, --private-key private key
> file\n"
> + "\t-c, --certificate signer's
> certificate file\n"
> + "\t-m, --monotonic-count
> comma-separated list of monotonic counts\n"
> + "\t-d, --dump_sigdump
> signature (*.p7)\n"
> + "\t-A, --fw-accept firmware accept capsule, requires GUID,
> no image blob\n"
> + "\t-R, --fw-revert firmware revert capsule, takes no GUID,
> no image blob\n"
> + "\t-o, --capoemflag capsule OEM Flag, an integer between
> 0x and 0x\n"
> + "\t-h, --helpprint a help message\n",
> tool_name);
> }
>
> @@ -336,16 +338,18 @@ static int create_auth_data(struct auth_context *ctx)
> * @path: Path to a capsule file
> * @signature: Signature data
> * @sig_size: Size of signature data
> + * @index: The payload index the signature belongs to
> *
> * Signature data pointed to by @signature will be saved into
> - *
Re: [PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
On Fri, 16 Jun 2023 at 10:48, Takahiro Akashi wrote: > > On Fri, Jun 16, 2023 at 10:37:01AM +0530, Sughosh Ganu wrote: > > hi Takahiro, > > > > On Fri, 16 Jun 2023 at 10:16, Takahiro Akashi > > wrote: > > > > > > Hi Sughosh, > > > > > > On Fri, Jun 16, 2023 at 09:56:33AM +0530, Sughosh Ganu wrote: > > > > On Thu, 15 Jun 2023 at 11:19, Takahiro Akashi > > > > wrote: > > > > > > > > > > On Thu, Jun 15, 2023 at 10:09:06AM +0530, Sughosh Ganu wrote: > > > > > > On Wed, 14 Jun 2023 at 11:23, Takahiro Akashi > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Jun 14, 2023 at 10:56:23AM +0530, Sughosh Ganu wrote: > > > > > > > > hi Takahiro, > > > > > > > > > > > > > > > > On Wed, 14 Jun 2023 at 09:09, Takahiro Akashi > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > > > I think this is a good extension to mkeficapsule, but > > > > > > > > > > > > > > > > > > On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote: > > > > > > > > > > Add support for specifying the parameters needed for capsule > > > > > > > > > > generation through a config file, instead of passing them > > > > > > > > > > through > > > > > > > > > > command-line. Parameters for more than a single capsule > > > > > > > > > > file can be > > > > > > > > > > specified, resulting in generation of multiple capsules > > > > > > > > > > through a > > > > > > > > > > single invocation of the command. > > > > > > > > > > > > > > > > > > > > This path is to be used for generating capsules through a > > > > > > > > > > make target, > > > > > > > > > > with the parameters being parsed from the config file. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > > > --- > > > > > > > > > > tools/Kconfig | 9 + > > > > > > > > > > tools/Makefile | 1 + > > > > > > > > > > tools/eficapsule.h | 110 > > > > > > > > > > tools/mkeficapsule.c | 106 +++- > > > > > > > > > > tools/mkeficapsule_parse.c | 345 > > > > > > > > > > + > > > > > > > > > > 5 files changed, 531 insertions(+), 40 deletions(-) > > > > > > > > > > create mode 100644 tools/mkeficapsule_parse.c > > > > > > > > > > > > > > > > > > > > diff --git a/tools/Kconfig b/tools/Kconfig > > > > > > > > > > index 539708f277..95f27b7c45 100644 > > > > > > > > > > --- a/tools/Kconfig > > > > > > > > > > +++ b/tools/Kconfig > > > > > > > > > > @@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE > > > > > > > > > > optionally sign that file. If you want to enable > > > > > > > > > > UEFI capsule > > > > > > > > > > update feature on your target, you certainly need > > > > > > > > > > this. > > > > > > > > > > > > > > > > > > > > +config EFI_CAPSULE_CFG_FILE > > > > > > > > > > + string "Path to the EFI Capsule Config File" > > > > > > > > > > + default "" > > > > > > > > > > + help > > > > > > > > > > + Path to the EFI capsule config file which provides > > > > > > > > > > the > > > > > > > > > > + parameters needed to build capsule(s). Parameters > > > > > > > > > > can be > > >
Re: [PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
hi Takahiro, On Fri, 16 Jun 2023 at 10:16, Takahiro Akashi wrote: > > Hi Sughosh, > > On Fri, Jun 16, 2023 at 09:56:33AM +0530, Sughosh Ganu wrote: > > On Thu, 15 Jun 2023 at 11:19, Takahiro Akashi > > wrote: > > > > > > On Thu, Jun 15, 2023 at 10:09:06AM +0530, Sughosh Ganu wrote: > > > > On Wed, 14 Jun 2023 at 11:23, Takahiro Akashi > > > > wrote: > > > > > > > > > > On Wed, Jun 14, 2023 at 10:56:23AM +0530, Sughosh Ganu wrote: > > > > > > hi Takahiro, > > > > > > > > > > > > On Wed, 14 Jun 2023 at 09:09, Takahiro Akashi > > > > > > wrote: > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > I think this is a good extension to mkeficapsule, but > > > > > > > > > > > > > > On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote: > > > > > > > > Add support for specifying the parameters needed for capsule > > > > > > > > generation through a config file, instead of passing them > > > > > > > > through > > > > > > > > command-line. Parameters for more than a single capsule file > > > > > > > > can be > > > > > > > > specified, resulting in generation of multiple capsules through > > > > > > > > a > > > > > > > > single invocation of the command. > > > > > > > > > > > > > > > > This path is to be used for generating capsules through a make > > > > > > > > target, > > > > > > > > with the parameters being parsed from the config file. > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > --- > > > > > > > > tools/Kconfig | 9 + > > > > > > > > tools/Makefile | 1 + > > > > > > > > tools/eficapsule.h | 110 > > > > > > > > tools/mkeficapsule.c | 106 +++- > > > > > > > > tools/mkeficapsule_parse.c | 345 > > > > > > > > + > > > > > > > > 5 files changed, 531 insertions(+), 40 deletions(-) > > > > > > > > create mode 100644 tools/mkeficapsule_parse.c > > > > > > > > > > > > > > > > diff --git a/tools/Kconfig b/tools/Kconfig > > > > > > > > index 539708f277..95f27b7c45 100644 > > > > > > > > --- a/tools/Kconfig > > > > > > > > +++ b/tools/Kconfig > > > > > > > > @@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE > > > > > > > > optionally sign that file. If you want to enable UEFI > > > > > > > > capsule > > > > > > > > update feature on your target, you certainly need this. > > > > > > > > > > > > > > > > +config EFI_CAPSULE_CFG_FILE > > > > > > > > + string "Path to the EFI Capsule Config File" > > > > > > > > + default "" > > > > > > > > + help > > > > > > > > + Path to the EFI capsule config file which provides the > > > > > > > > + parameters needed to build capsule(s). Parameters can be > > > > > > > > + provided for multiple payloads resulting in > > > > > > > > corresponding > > > > > > > > + capsule images being generated. > > > > > > > > + > > > > > > > > menuconfig FSPI_CONF_HEADER > > > > > > > > bool "FlexSPI Header Configuration" > > > > > > > > help > > > > > > > > diff --git a/tools/Makefile b/tools/Makefile > > > > > > > > index d793cf3bec..ef366f3d61 100644 > > > > > > > > --- a/tools/Makefile > > > > > > > > +++ b/tools/Makefile > > > > > > > > @@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \ > > > > > > > > HOSTLDLIBS_mkeficapsule += \ > > > > > > > > $(shell pkg-config --libs uuid 2>
Re: [PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
On Thu, 15 Jun 2023 at 11:19, Takahiro Akashi
wrote:
>
> On Thu, Jun 15, 2023 at 10:09:06AM +0530, Sughosh Ganu wrote:
> > On Wed, 14 Jun 2023 at 11:23, Takahiro Akashi
> > wrote:
> > >
> > > On Wed, Jun 14, 2023 at 10:56:23AM +0530, Sughosh Ganu wrote:
> > > > hi Takahiro,
> > > >
> > > > On Wed, 14 Jun 2023 at 09:09, Takahiro Akashi
> > > > wrote:
> > > > >
> > > > > Hi Sughosh,
> > > > >
> > > > > I think this is a good extension to mkeficapsule, but
> > > > >
> > > > > On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote:
> > > > > > Add support for specifying the parameters needed for capsule
> > > > > > generation through a config file, instead of passing them through
> > > > > > command-line. Parameters for more than a single capsule file can be
> > > > > > specified, resulting in generation of multiple capsules through a
> > > > > > single invocation of the command.
> > > > > >
> > > > > > This path is to be used for generating capsules through a make
> > > > > > target,
> > > > > > with the parameters being parsed from the config file.
> > > > > >
> > > > > > Signed-off-by: Sughosh Ganu
> > > > > > ---
> > > > > > tools/Kconfig | 9 +
> > > > > > tools/Makefile | 1 +
> > > > > > tools/eficapsule.h | 110
> > > > > > tools/mkeficapsule.c | 106 +++-
> > > > > > tools/mkeficapsule_parse.c | 345
> > > > > > +
> > > > > > 5 files changed, 531 insertions(+), 40 deletions(-)
> > > > > > create mode 100644 tools/mkeficapsule_parse.c
> > > > > >
> > > > > > diff --git a/tools/Kconfig b/tools/Kconfig
> > > > > > index 539708f277..95f27b7c45 100644
> > > > > > --- a/tools/Kconfig
> > > > > > +++ b/tools/Kconfig
> > > > > > @@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
> > > > > > optionally sign that file. If you want to enable UEFI
> > > > > > capsule
> > > > > > update feature on your target, you certainly need this.
> > > > > >
> > > > > > +config EFI_CAPSULE_CFG_FILE
> > > > > > + string "Path to the EFI Capsule Config File"
> > > > > > + default ""
> > > > > > + help
> > > > > > + Path to the EFI capsule config file which provides the
> > > > > > + parameters needed to build capsule(s). Parameters can be
> > > > > > + provided for multiple payloads resulting in corresponding
> > > > > > + capsule images being generated.
> > > > > > +
> > > > > > menuconfig FSPI_CONF_HEADER
> > > > > > bool "FlexSPI Header Configuration"
> > > > > > help
> > > > > > diff --git a/tools/Makefile b/tools/Makefile
> > > > > > index d793cf3bec..ef366f3d61 100644
> > > > > > --- a/tools/Makefile
> > > > > > +++ b/tools/Makefile
> > > > > > @@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
> > > > > > HOSTLDLIBS_mkeficapsule += \
> > > > > > $(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
> > > > > > hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
> > > > > > +mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
> > > > > >
> > > > > > # We build some files with extra pedantic flags to try to minimize
> > > > > > things
> > > > > > # that won't build on some weird host compiler -- though there are
> > > > > > lots of
> > > > > > diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> > > > > > index 072a4b5598..42e66c6d6a 100644
> > > > > > --- a/tools/eficapsule.h
> > > > > > +++ b/tools/eficapsule.h
> > > > > > @@ -52,6 +52,38 @@ typedef struct {
> > > > > > /* flags */
> > > > > > #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
> > > > >
Re: [PATCH 5/7] Makefile: Add a target for building capsules
hi Simon, On Thu, 15 Jun 2023 at 14:44, Simon Glass wrote: > > Hi Sughosh, > > On Tue, 13 Jun 2023 at 11:39, Sughosh Ganu wrote: > > > > Add a target for building EFI capsules. The capsule parameters are > > specified through a config file, and the path to the config file is > > specified through CONFIG_EFI_CAPSULE_CFG_FILE. When the config file is > > not specified, the command only builds tools. > > > > Signed-off-by: Sughosh Ganu > > --- > > Makefile | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/Makefile b/Makefile > > index 10bfaa52ad..96db29aa77 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1151,6 +1151,15 @@ dtbs: dts/dt.dtb > > dts/dt.dtb: u-boot > > $(Q)$(MAKE) $(build)=dts dtbs > > > > +quiet_cmd_mkeficapsule = MKEFICAPSULE $@ > > +cmd_mkeficapsule = $(objtree)/tools/mkeficapsule $@ > > + > > +PHONY += capsule > > +capsule: tools > > +ifneq ($(CONFIG_EFI_CAPSULE_CFG_FILE),"") > > + $(call cmd,mkeficapsule) > > +endif > > + > > quiet_cmd_copy = COPY$@ > >cmd_copy = cp $< $@ > > > > -- > > 2.34.1 > > > > We should be using binman to build images...you seem to be building > something in parallel with that. Can you please take a look at binman? Again, I had explored using binman for this task. The one issue where I find the above flow better is that I can simply build my payload image(s) followed by 'make capsule' to generate the capsules for earlier generated images. In it's current form, I don't see an easy way to enforce this dependency in binman when I want to build the payload followed by generation of capsules. I did see the mention of encapsulating an entry within another dependent entry, but I think that makes the implementation more complex than it ought to be. I think it is much easier to use the make flow to generate the images followed by capsules, instead of tweaking the binman node to first generate the payload images, followed by enabling the capsule node to build the capsules. If there is an easy way of enforcing this dependency, please let me know. Thanks -sughosh
Re: [PATCH 1/7] capsule: authenticate: Embed capsule public key in platform's dtb
hi Simon,
On Thu, 15 Jun 2023 at 14:44, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Tue, 13 Jun 2023 at 11:41, Sughosh Ganu wrote:
> >
> > The EFI capsule authentication logic in u-boot expects the public key
> > in the form of an EFI Signature List(ESL) to be provided as part of
> > the platform's dtb. Currently, the embedding of the ESL file into the
> > dtb needs to be done manually.
> >
> > Add a script for embedding the ESL used for capsule authentication in
> > the platform's dtb, and call this as part of building the dtb(s). This
> > brings the embedding of the ESL in the dtb into the u-boot build flow.
> >
> > The path to the ESL file is specified through the
> > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > lib/efi_loader/Kconfig | 11 +++
> > scripts/Makefile.lib | 8
> > scripts/embed_capsule_key.sh | 25 +
> > 3 files changed, 44 insertions(+)
> > create mode 100755 scripts/embed_capsule_key.sh
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index c5835e6ef6..1326a1d109 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -234,6 +234,17 @@ config EFI_CAPSULE_MAX
> > Select the max capsule index value used for capsule report
> > variables. This value is used to create CapsuleMax variable.
> >
> > +config EFI_CAPSULE_ESL_FILE
> > + string "Path to the EFI Signature List File"
> > + default ""
> > + depends on EFI_CAPSULE_AUTHENTICATE
> > + help
> > + Provides the absolute path to the EFI Signature List
> > + file which will be embedded in the platform's device
> > + tree and used for capsule authentication at the time
> > + of capsule update.
> > +
> > +
> > config EFI_DEVICE_PATH_TO_TEXT
> > bool "Device path to text protocol"
> > default y
> > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > index 7b27224b5d..a4083d0a26 100644
> > --- a/scripts/Makefile.lib
> > +++ b/scripts/Makefile.lib
> > @@ -192,6 +192,8 @@ dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc
> > \
> > -D__ASSEMBLY__ \
> > -undef -D__DTS__
> >
> > +export dtc_cpp_flags
> > +
> > # Finds the multi-part object the current object will be linked into
> > modname-multi = $(sort $(foreach m,$(multi-used),\
> > $(if $(filter $(subst $(obj)/,,$*.o), $($(m:.o=-objs))
> > $($(m:.o=-y))),$(m:.o=
> > @@ -315,6 +317,9 @@ ifeq ($(CONFIG_OF_LIBFDT_OVERLAY),y)
> > DTC_FLAGS += -@
> > endif
> >
> > +quiet_cmd_embedcapsulekey = EMBEDCAPSULEKEY $@
> > +cmd_embedcapsulekey = $(srctree)/scripts/embed_capsule_key.sh $@
> > +
> > quiet_cmd_dtc = DTC $@
> > # Modified for U-Boot
> > # Bring in any U-Boot-specific include at the end of the file
> > @@ -333,6 +338,9 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> >
> > $(obj)/%.dtb: $(src)/%.dts FORCE
> > $(call if_changed_dep,dtc)
> > +ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
> > + $(call cmd,embedcapsulekey,$@)
> > +endif
> >
> > pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
> > dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
> > diff --git a/scripts/embed_capsule_key.sh b/scripts/embed_capsule_key.sh
> > new file mode 100755
> > index 00..1c2e45f758
> > --- /dev/null
> > +++ b/scripts/embed_capsule_key.sh
> > @@ -0,0 +1,25 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (C) 2023, Linaro Limited
> > +#
> > +
> > +gen_capsule_signature_file() {
> > +cat >> $1 << EOF
> > +/dts-v1/;
> > +/plugin/;
> > +
> > +&{/} {
> > + signature {
> > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > + };
> > +};
> > +EOF
> > +}
> > +
> > +gen_capsule_signature_file signature.$$.dts > /dev/null 2>&1
> > +$CPP $dtc_cpp_flags -x assembler-with-cpp -o signature.$$.tmp
> > signature.$$.dts > /dev/null 2>&1
> > +dtc -@ -O dtb -o signature.$$.dtbo signature.$$.tmp > /dev/null 2>&1
> > +fdtoverlay -i $1 -o temp.$$.dtb -v signature.$$.dtbo > /dev/null 2>&1
> > +mv temp.$$.dtb $1 > /dev/null 2&g
Re: [PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
On Wed, 14 Jun 2023 at 11:23, Takahiro Akashi
wrote:
>
> On Wed, Jun 14, 2023 at 10:56:23AM +0530, Sughosh Ganu wrote:
> > hi Takahiro,
> >
> > On Wed, 14 Jun 2023 at 09:09, Takahiro Akashi
> > wrote:
> > >
> > > Hi Sughosh,
> > >
> > > I think this is a good extension to mkeficapsule, but
> > >
> > > On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote:
> > > > Add support for specifying the parameters needed for capsule
> > > > generation through a config file, instead of passing them through
> > > > command-line. Parameters for more than a single capsule file can be
> > > > specified, resulting in generation of multiple capsules through a
> > > > single invocation of the command.
> > > >
> > > > This path is to be used for generating capsules through a make target,
> > > > with the parameters being parsed from the config file.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > tools/Kconfig | 9 +
> > > > tools/Makefile | 1 +
> > > > tools/eficapsule.h | 110
> > > > tools/mkeficapsule.c | 106 +++-
> > > > tools/mkeficapsule_parse.c | 345 +
> > > > 5 files changed, 531 insertions(+), 40 deletions(-)
> > > > create mode 100644 tools/mkeficapsule_parse.c
> > > >
> > > > diff --git a/tools/Kconfig b/tools/Kconfig
> > > > index 539708f277..95f27b7c45 100644
> > > > --- a/tools/Kconfig
> > > > +++ b/tools/Kconfig
> > > > @@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
> > > > optionally sign that file. If you want to enable UEFI capsule
> > > > update feature on your target, you certainly need this.
> > > >
> > > > +config EFI_CAPSULE_CFG_FILE
> > > > + string "Path to the EFI Capsule Config File"
> > > > + default ""
> > > > + help
> > > > + Path to the EFI capsule config file which provides the
> > > > + parameters needed to build capsule(s). Parameters can be
> > > > + provided for multiple payloads resulting in corresponding
> > > > + capsule images being generated.
> > > > +
> > > > menuconfig FSPI_CONF_HEADER
> > > > bool "FlexSPI Header Configuration"
> > > > help
> > > > diff --git a/tools/Makefile b/tools/Makefile
> > > > index d793cf3bec..ef366f3d61 100644
> > > > --- a/tools/Makefile
> > > > +++ b/tools/Makefile
> > > > @@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
> > > > HOSTLDLIBS_mkeficapsule += \
> > > > $(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
> > > > hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
> > > > +mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
> > > >
> > > > # We build some files with extra pedantic flags to try to minimize
> > > > things
> > > > # that won't build on some weird host compiler -- though there are
> > > > lots of
> > > > diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> > > > index 072a4b5598..42e66c6d6a 100644
> > > > --- a/tools/eficapsule.h
> > > > +++ b/tools/eficapsule.h
> > > > @@ -52,6 +52,38 @@ typedef struct {
> > > > /* flags */
> > > > #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
> > > >
> > > > +enum capsule_type {
> > > > + CAPSULE_NORMAL_BLOB = 0,
> > > > + CAPSULE_ACCEPT,
> > > > + CAPSULE_REVERT,
> > > > +};
> > > > +
> > > > +/**
> > > > + * struct efi_capsule_params - Capsule parameters
> > > > + * @image_guid: Guid value of the payload input image
> > > > + * @image_index: Image index value
> > > > + * @hardware_instance: Hardware instance to be used for the image
> > > > + * @monotonic_count: Monotonic count value to be used for signed
> > > > capsule
> > > > + * @privkey_file: Path to private key used in capsule signing
> > > > + * @cert_file: Path to public key certificate used in capsule signing
> > > > + * @input_file: Path to payload input image
> > > > + * @capsule_file: Path to the output capsule file
&g
Re: [PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
hi Takahiro,
On Wed, 14 Jun 2023 at 09:09, Takahiro Akashi
wrote:
>
> Hi Sughosh,
>
> I think this is a good extension to mkeficapsule, but
>
> On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote:
> > Add support for specifying the parameters needed for capsule
> > generation through a config file, instead of passing them through
> > command-line. Parameters for more than a single capsule file can be
> > specified, resulting in generation of multiple capsules through a
> > single invocation of the command.
> >
> > This path is to be used for generating capsules through a make target,
> > with the parameters being parsed from the config file.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > tools/Kconfig | 9 +
> > tools/Makefile | 1 +
> > tools/eficapsule.h | 110
> > tools/mkeficapsule.c | 106 +++-
> > tools/mkeficapsule_parse.c | 345 +
> > 5 files changed, 531 insertions(+), 40 deletions(-)
> > create mode 100644 tools/mkeficapsule_parse.c
> >
> > diff --git a/tools/Kconfig b/tools/Kconfig
> > index 539708f277..95f27b7c45 100644
> > --- a/tools/Kconfig
> > +++ b/tools/Kconfig
> > @@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
> > optionally sign that file. If you want to enable UEFI capsule
> > update feature on your target, you certainly need this.
> >
> > +config EFI_CAPSULE_CFG_FILE
> > + string "Path to the EFI Capsule Config File"
> > + default ""
> > + help
> > + Path to the EFI capsule config file which provides the
> > + parameters needed to build capsule(s). Parameters can be
> > + provided for multiple payloads resulting in corresponding
> > + capsule images being generated.
> > +
> > menuconfig FSPI_CONF_HEADER
> > bool "FlexSPI Header Configuration"
> > help
> > diff --git a/tools/Makefile b/tools/Makefile
> > index d793cf3bec..ef366f3d61 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
> > HOSTLDLIBS_mkeficapsule += \
> > $(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
> > hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
> > +mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
> >
> > # We build some files with extra pedantic flags to try to minimize things
> > # that won't build on some weird host compiler -- though there are lots of
> > diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> > index 072a4b5598..42e66c6d6a 100644
> > --- a/tools/eficapsule.h
> > +++ b/tools/eficapsule.h
> > @@ -52,6 +52,38 @@ typedef struct {
> > /* flags */
> > #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
> >
> > +enum capsule_type {
> > + CAPSULE_NORMAL_BLOB = 0,
> > + CAPSULE_ACCEPT,
> > + CAPSULE_REVERT,
> > +};
> > +
> > +/**
> > + * struct efi_capsule_params - Capsule parameters
> > + * @image_guid: Guid value of the payload input image
> > + * @image_index: Image index value
> > + * @hardware_instance: Hardware instance to be used for the image
> > + * @monotonic_count: Monotonic count value to be used for signed capsule
> > + * @privkey_file: Path to private key used in capsule signing
> > + * @cert_file: Path to public key certificate used in capsule signing
> > + * @input_file: Path to payload input image
> > + * @capsule_file: Path to the output capsule file
> > + * @oemflags: Oemflags to be populated in the capsule header
> > + * @capsule: Capsule Type, normal or accept or revert
> > + */
> > +struct efi_capsule_params {
> > + efi_guid_t *image_guid;
> > + unsigned long image_index;
> > + unsigned long hardware_instance;
> > + uint64_t monotonic_count;
> > + char *privkey_file;
> > + char *cert_file;
> > + char *input_file;
> > + char *capsule_file;
> > + unsigned long oemflags;
> > + enum capsule_type capsule;
> > +};
> > +
> > struct efi_capsule_header {
> > efi_guid_t capsule_guid;
> > uint32_t header_size;
> > @@ -113,4 +145,82 @@ struct efi_firmware_image_authentication {
> > struct win_certificate_uefi_guid auth_info;
> > } __packed;
> >
> > +/**
> > + * capsule_with_cfg_file() - Generate capsule from config file
> > + * @cfg_file: Path to the config file
> >
[PATCH 6/7] test: efi_capsule: Test capsule generation from config file
Support has been added to generate capsules through parameters
specified in the config file. To bring this under the testing ambit,
make changes in the EFI capsule test logic to generate the capsule
files by parsing the config file, when the path to the config file is
specified.
Signed-off-by: Sughosh Ganu
---
configs/sandbox_defconfig | 1 +
test/py/tests/test_efi_capsule/conftest.py| 106 +++---
.../test_efi_capsule/sandbox_capsule_cfg.txt | 75 +
3 files changed, 139 insertions(+), 43 deletions(-)
create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index d8a2386bb0..ba26816898 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -340,6 +340,7 @@ CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
+CONFIG_EFI_CAPSULE_CFG_FILE="/tmp/capsules/sandbox_capsule_cfg.txt"
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index 4269c41a74..4eb54c1a61 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -42,21 +42,6 @@ def efi_capsule_data(request, u_boot_config):
check_call('cd %s; %s/tools/mkimage -f uboot_bin_env.its
uboot_bin_env.itb' %
(data_dir, u_boot_config.build_dir),
shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
09D7CF52-0720-4710-91D1-08469B7FE9C8 u-boot.bin.new Test01' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 2 --guid
5A7021F5-FEF2-48B4-AABA-832E777418C0 u-boot.env.new Test02' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
058B7D83-50D5-4C47-A195-60D86AD341C4 u-boot.bin.new Test03' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
3673B45D-6A7C-46F3-9E60-ADABB03F7937 uboot_bin_env.itb Test04' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
058B7D83-50D5-4C47-A195-60D86AD341C4 uboot_bin_env.itb Test05' %
- (data_dir, u_boot_config.build_dir),
- shell=True)
capsule_auth_enabled = u_boot_config.buildconfig.get(
'config_efi_capsule_authenticate')
@@ -66,40 +51,75 @@ def efi_capsule_data(request, u_boot_config):
check_call('cp %s/arch/sandbox/dts/test.dtb %s/test_sig.dtb' %
(u_boot_config.build_dir, data_dir), shell=True)
-# raw firmware signed with proper key
-check_call('cd %s; '
- '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
-'--private-key SIGNER.key --certificate SIGNER.crt
'
-'--guid 09D7CF52-0720-4710-91D1-08469B7FE9C8 '
-'u-boot.bin.new Test11'
- % (data_dir, u_boot_config.build_dir),
+cfg_file = u_boot_config.buildconfig.get(
+'config_efi_capsule_cfg_file')[1:-1]
+if cfg_file:
+capsules_path_dir = '/tmp/capsules/'
+check_call('mkdir -p %s ;'
+ 'cp -a %s/* %s/' % (capsules_path_dir, data_dir,
capsules_path_dir),
shell=True)
-# raw firmware signed with *mal* key
-check_call('cd %s; '
- '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
-'--private-key SIGNER2.key '
-'--certificate SIGNER2.crt '
-'--guid 09D7CF52-0720-4710-91D1-08469B7FE9C8 '
-'u-boot.bin.new Test12'
- % (data_dir, u_boot_config.build_dir),
+check_call(' cp
%s/test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt %s'
+ % (u_boot_config.source_dir, capsules_path_dir),
shell=True)
-# FIT firmware signed with proper key
check_call('cd %s; '
- '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
-'--private-key SIGNER.key --certificate SIGNER.crt
'
-'--guid 3673B45D-6A7C-46F3-9E60-ADABB03F7937 '
-'uboot_bin_env.itb Test13'
- % (data_dir, u_boot_config.build_dir),
+
[PATCH 7/7] doc: Add documentation to describe capsule config file format
The UEFI capsule can be generated either through command-line
parameters, or, by specifying those in a config file. Add
documentation to describe the format of the config file.
Signed-off-by: Sughosh Ganu
---
doc/develop/uefi/uefi.rst | 64 +++
1 file changed, 64 insertions(+)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index f96762af39..09b32c9921 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -442,6 +442,70 @@ following command can be issued
--guid c1b629f1-ce0e-4894-82bf-f0a38387e630 \
optee.bin optee.capsule
+Or alternatively, the capsule can be generated through a make target
+
+.. code-block:: bash
+
+$ make capsule
+
+Issuing the above make command requires specifying the capsule
+parameters through a config file instead. The Kconfig symbol
+CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the path to
+the config file.
+
+The config file describes the parameters that are used for generating
+one or more capsules. The parameters for a given capsule file are
+specified within curly braces, in the form of "key:value" pairs. All
+the parameters that are currently supported by the mkeficapsule tool
+can be specified through the config file.
+
+The following are some example payload parameters specified through
+the config file.
+
+.. code-block:: none
+
+ {
+ image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
+ hardware-instance: 0
+ monotonic-count: 1
+ payload: u-boot.bin
+ image-index: 1
+ private-key: /path/to/priv/key
+ pub-key-cert: /path/to/pub/key
+ capsule: u-boot.capsule
+ }
+ {
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ hardware-instance: 0
+ payload: u-boot.itb
+ image-index: 2
+ oemflags: 0x8000
+ capsule: fit.capsule
+ }
+ {
+ capsule-type: accept
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ capsule: accept.capsule
+ }
+ {
+ capsule-type: revert
+ capsule: revert.capsule
+ }
+
+The following are the keys that specify the capsule parameters
+
+..code-block:: none
+
+image-guid: Image GUID
+image-index: Image index value
+private-key: Path to the private key file used for capsule signing
+pub-key-cert: Path to the public key crt file used for capsule signing
+payload: Path to the capsule payload file
+capsule: Path to the output capsule file that is generated
+hardware-instance: Hardware Instance value
+monotonic-count: Monotonic count value
+capsule-type: Specifies capsule type. normal(default), accept or revert
+oemflags: 16bit Oemflags value to be used(populated in capsule header)
Enabling Capsule Authentication
***
--
2.34.1
[PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
Add support for specifying the parameters needed for capsule
generation through a config file, instead of passing them through
command-line. Parameters for more than a single capsule file can be
specified, resulting in generation of multiple capsules through a
single invocation of the command.
This path is to be used for generating capsules through a make target,
with the parameters being parsed from the config file.
Signed-off-by: Sughosh Ganu
---
tools/Kconfig | 9 +
tools/Makefile | 1 +
tools/eficapsule.h | 110
tools/mkeficapsule.c | 106 +++-
tools/mkeficapsule_parse.c | 345 +
5 files changed, 531 insertions(+), 40 deletions(-)
create mode 100644 tools/mkeficapsule_parse.c
diff --git a/tools/Kconfig b/tools/Kconfig
index 539708f277..95f27b7c45 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
optionally sign that file. If you want to enable UEFI capsule
update feature on your target, you certainly need this.
+config EFI_CAPSULE_CFG_FILE
+ string "Path to the EFI Capsule Config File"
+ default ""
+ help
+ Path to the EFI capsule config file which provides the
+ parameters needed to build capsule(s). Parameters can be
+ provided for multiple payloads resulting in corresponding
+ capsule images being generated.
+
menuconfig FSPI_CONF_HEADER
bool "FlexSPI Header Configuration"
help
diff --git a/tools/Makefile b/tools/Makefile
index d793cf3bec..ef366f3d61 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
HOSTLDLIBS_mkeficapsule += \
$(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
+mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
# We build some files with extra pedantic flags to try to minimize things
# that won't build on some weird host compiler -- though there are lots of
diff --git a/tools/eficapsule.h b/tools/eficapsule.h
index 072a4b5598..42e66c6d6a 100644
--- a/tools/eficapsule.h
+++ b/tools/eficapsule.h
@@ -52,6 +52,38 @@ typedef struct {
/* flags */
#define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
+enum capsule_type {
+ CAPSULE_NORMAL_BLOB = 0,
+ CAPSULE_ACCEPT,
+ CAPSULE_REVERT,
+};
+
+/**
+ * struct efi_capsule_params - Capsule parameters
+ * @image_guid: Guid value of the payload input image
+ * @image_index: Image index value
+ * @hardware_instance: Hardware instance to be used for the image
+ * @monotonic_count: Monotonic count value to be used for signed capsule
+ * @privkey_file: Path to private key used in capsule signing
+ * @cert_file: Path to public key certificate used in capsule signing
+ * @input_file: Path to payload input image
+ * @capsule_file: Path to the output capsule file
+ * @oemflags: Oemflags to be populated in the capsule header
+ * @capsule: Capsule Type, normal or accept or revert
+ */
+struct efi_capsule_params {
+ efi_guid_t *image_guid;
+ unsigned long image_index;
+ unsigned long hardware_instance;
+ uint64_t monotonic_count;
+ char *privkey_file;
+ char *cert_file;
+ char *input_file;
+ char *capsule_file;
+ unsigned long oemflags;
+ enum capsule_type capsule;
+};
+
struct efi_capsule_header {
efi_guid_t capsule_guid;
uint32_t header_size;
@@ -113,4 +145,82 @@ struct efi_firmware_image_authentication {
struct win_certificate_uefi_guid auth_info;
} __packed;
+/**
+ * capsule_with_cfg_file() - Generate capsule from config file
+ * @cfg_file: Path to the config file
+ *
+ * Parse the capsule parameters from the config file and use the
+ * parameters for generating one or more capsules.
+ *
+ * Return: None
+ *
+ */
+void capsule_with_cfg_file(const char *cfg_file);
+
+/**
+ * convert_uuid_to_guid() - convert UUID to GUID
+ * @buf: UUID binary
+ *
+ * UUID and GUID have the same data structure, but their binary
+ * formats are different due to the endianness. See lib/uuid.c.
+ * Since uuid_parse() can handle only UUID, this function must
+ * be called to get correct data for GUID when parsing a string.
+ *
+ * The correct data will be returned in @buf.
+ */
+void convert_uuid_to_guid(unsigned char *buf);
+
+/**
+ * create_empty_capsule() - Generate an empty capsule
+ * @path: Path to the empty capsule file to be generated
+ * @guid: Guid value of the image for which empty capsule is generated
+ * @fw_accept: Flag to specify whether to generate accept or revert capsule
+ *
+ * Generate an empty capsule, either an accept or a revert capsule to be
+ * used to flag acceptance or rejection of an earlier executed firmware
+ * update operation. Being used in the FWU Multi Bank firmware update
+ * feature.
+ *
+ * Return: 0 if OK, -ve
