[PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-25 Thread Sughosh Ganu
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



Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-25 Thread Simon Glass
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

> +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/
> +
>  # 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
>

Regards,
Simon


Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-25 Thread Tom Rini
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).

> > +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.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-26 Thread Tom Rini
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: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.

So lets just make use of the artifacts feature, generate 

Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-26 Thread Simon Glass
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.

Regards,
Simon


Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-26 Thread Simon Glass
Hi Sughosh,

On Wed, 26 Jul 2023 at 08:41, 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: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.

OK, so let's just create the files before they are need

Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-26 Thread Sughosh Ganu
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 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-26 Thread Sughosh Ganu
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 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-26 Thread Tom Rini
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?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-26 Thread Sughosh Ganu
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 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-26 Thread Sughosh Ganu
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: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 g

Re: [PATCH v5 06/12] Dockerfile: capsule: Setup the files needed for capsule update testing

2023-07-26 Thread Tom Rini
On Thu, Jul 27, 2023 at 01:30:04AM +0530, Sughosh Ganu wrote:
> 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: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