Re: [PATCH v6 9/9] sandbox: capsule: Generate capsule related files through binman
Hi Sughosh, On Fri, 4 Aug 2023 at 01:03, Sughosh Ganu wrote: > > hi Simon, > > On Fri, 4 Aug 2023 at 08:32, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Thu, 3 Aug 2023 at 05:18, Sughosh Ganu wrote: > > > > > > hi Simon, > > > > > > On Wed, 2 Aug 2023 at 18:23, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Tue, 1 Aug 2023 at 11:41, 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 V5: > > > > > * 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. > > > > > > > > > > arch/sandbox/dts/u-boot.dtsi | 347 > > > > > ++ > > > > > test/py/tests/test_efi_capsule/conftest.py| 128 +-- > > > > > .../tests/test_efi_capsule/uboot_bin_env.its | 36 -- > > > > > 3 files changed, 348 insertions(+), 163 deletions(-) > > > > > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its > > > > > > > > > > > > > I want to get the binman stuff right before diving into this, but the > > > > binman stuff seems fairly close, so I'll just mention...do you really > > > > need all these combinations of tests? It seems to me that one test is > > > > enough. You know that the binman tests will protect the code there, so > > > > why test it all over again here? > > > > > > These are capsules that are needed for testing the EFI capsule update > > > functionality. Currently, the capsules used for testing the feature > > > are generated after u-boot has been built. Same for embedding the > > > public key in the dtb. I think it is better to have the same flow of > > > generating capsules and the associated logic(public key embedding) > > > that is being supported in u-boot rather than having two divergent > > > flows. This also serves as an example for potential users who would > > > want to generate capsules as part of the build flow. > > > > But my question was why you need more than one test here? Are you > > testing that U-Boot can decode a capsule file of various types? That > > should be done in unit tests. > > The tests are the same. They are not being changed. What is changed is > the stage at which the capsules are being generated. Currently, the > capsules get generated only when the tests are invoked, as part of the > test setup. Same for embedding of the public key cert EFI Signature > List(ESL) file. This patch results in the capsules getting generated > as part of the u-boot build. Same for embedding of the public key ESL. > If we don't follow this flow, we would have support for generating > capsules as part of the u-boot build, but that flow would not be used > at all. I understand that binman tests the generation of capsules, but > we would then have this divergence between the flow that is supported, > and what is actually used in the tests. OK let's discuss the tests later. > > One alternative, which I think is a middle ground for this would be to > add a Kconfig symbol and use that for generating capsules. We can then > use that symbol in CI. This is similar to how the trace testing > happens in CI on the sandbox platform. In that scenario, we would not > have the capsules getting generated during normal builds. Here's what I suggest: - rely on binman tests for capsule generation - once you have a dump_capsule tool you can use that to check that things look OK - rely on unit tests for testing decoding capsules in U-Boot - have a few functional tests as a sanity check for overall behaviour > > > > > Now I see the tests you are referring to in > > test_capsule_firmware_signed_raw.py (please shorten the name!) > > > > These tests all have the reboot problem we need to fix, but anyway, at > > least I understand it. > > > > It looks like you are writing the test files into the source tree? > > They should be written to the output tree. > > If we are to generate the capsules, and embed the key as part of the > u-boot build, these input files are needed. Btw, I do see a few places > which have input files in the source, including inside binman. What
Re: [PATCH v6 9/9] sandbox: capsule: Generate capsule related files through binman
hi Simon, On Fri, 4 Aug 2023 at 08:32, Simon Glass wrote: > > Hi Sughosh, > > On Thu, 3 Aug 2023 at 05:18, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Wed, 2 Aug 2023 at 18:23, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Tue, 1 Aug 2023 at 11:41, 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 V5: > > > > * 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. > > > > > > > > arch/sandbox/dts/u-boot.dtsi | 347 ++ > > > > test/py/tests/test_efi_capsule/conftest.py| 128 +-- > > > > .../tests/test_efi_capsule/uboot_bin_env.its | 36 -- > > > > 3 files changed, 348 insertions(+), 163 deletions(-) > > > > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its > > > > > > > > > > I want to get the binman stuff right before diving into this, but the > > > binman stuff seems fairly close, so I'll just mention...do you really > > > need all these combinations of tests? It seems to me that one test is > > > enough. You know that the binman tests will protect the code there, so > > > why test it all over again here? > > > > These are capsules that are needed for testing the EFI capsule update > > functionality. Currently, the capsules used for testing the feature > > are generated after u-boot has been built. Same for embedding the > > public key in the dtb. I think it is better to have the same flow of > > generating capsules and the associated logic(public key embedding) > > that is being supported in u-boot rather than having two divergent > > flows. This also serves as an example for potential users who would > > want to generate capsules as part of the build flow. > > But my question was why you need more than one test here? Are you > testing that U-Boot can decode a capsule file of various types? That > should be done in unit tests. The tests are the same. They are not being changed. What is changed is the stage at which the capsules are being generated. Currently, the capsules get generated only when the tests are invoked, as part of the test setup. Same for embedding of the public key cert EFI Signature List(ESL) file. This patch results in the capsules getting generated as part of the u-boot build. Same for embedding of the public key ESL. If we don't follow this flow, we would have support for generating capsules as part of the u-boot build, but that flow would not be used at all. I understand that binman tests the generation of capsules, but we would then have this divergence between the flow that is supported, and what is actually used in the tests. One alternative, which I think is a middle ground for this would be to add a Kconfig symbol and use that for generating capsules. We can then use that symbol in CI. This is similar to how the trace testing happens in CI on the sandbox platform. In that scenario, we would not have the capsules getting generated during normal builds. > > Now I see the tests you are referring to in > test_capsule_firmware_signed_raw.py (please shorten the name!) > > These tests all have the reboot problem we need to fix, but anyway, at > least I understand it. > > It looks like you are writing the test files into the source tree? > They should be written to the output tree. If we are to generate the capsules, and embed the key as part of the u-boot build, these input files are needed. Btw, I do see a few places which have input files in the source, including inside binman. What issue do you see having these in the source? I had discussed this with Tom over irc and he had suggested this location for the files. -sughosh
Re: [PATCH v6 9/9] sandbox: capsule: Generate capsule related files through binman
Hi Sughosh, On Thu, 3 Aug 2023 at 05:18, Sughosh Ganu wrote: > > hi Simon, > > On Wed, 2 Aug 2023 at 18:23, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Tue, 1 Aug 2023 at 11:41, 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 V5: > > > * 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. > > > > > > arch/sandbox/dts/u-boot.dtsi | 347 ++ > > > test/py/tests/test_efi_capsule/conftest.py| 128 +-- > > > .../tests/test_efi_capsule/uboot_bin_env.its | 36 -- > > > 3 files changed, 348 insertions(+), 163 deletions(-) > > > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its > > > > > > > I want to get the binman stuff right before diving into this, but the > > binman stuff seems fairly close, so I'll just mention...do you really > > need all these combinations of tests? It seems to me that one test is > > enough. You know that the binman tests will protect the code there, so > > why test it all over again here? > > These are capsules that are needed for testing the EFI capsule update > functionality. Currently, the capsules used for testing the feature > are generated after u-boot has been built. Same for embedding the > public key in the dtb. I think it is better to have the same flow of > generating capsules and the associated logic(public key embedding) > that is being supported in u-boot rather than having two divergent > flows. This also serves as an example for potential users who would > want to generate capsules as part of the build flow. But my question was why you need more than one test here? Are you testing that U-Boot can decode a capsule file of various types? That should be done in unit tests. Now I see the tests you are referring to in test_capsule_firmware_signed_raw.py (please shorten the name!) These tests all have the reboot problem we need to fix, but anyway, at least I understand it. It looks like you are writing the test files into the source tree? They should be written to the output tree. Regards, Simon
Re: [PATCH v6 9/9] sandbox: capsule: Generate capsule related files through binman
hi Simon, On Wed, 2 Aug 2023 at 18:23, Simon Glass wrote: > > Hi Sughosh, > > On Tue, 1 Aug 2023 at 11:41, 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 V5: > > * 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. > > > > arch/sandbox/dts/u-boot.dtsi | 347 ++ > > test/py/tests/test_efi_capsule/conftest.py| 128 +-- > > .../tests/test_efi_capsule/uboot_bin_env.its | 36 -- > > 3 files changed, 348 insertions(+), 163 deletions(-) > > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its > > > > I want to get the binman stuff right before diving into this, but the > binman stuff seems fairly close, so I'll just mention...do you really > need all these combinations of tests? It seems to me that one test is > enough. You know that the binman tests will protect the code there, so > why test it all over again here? These are capsules that are needed for testing the EFI capsule update functionality. Currently, the capsules used for testing the feature are generated after u-boot has been built. Same for embedding the public key in the dtb. I think it is better to have the same flow of generating capsules and the associated logic(public key embedding) that is being supported in u-boot rather than having two divergent flows. This also serves as an example for potential users who would want to generate capsules as part of the build flow. -sughosh > > Regards, > Simon
Re: [PATCH v6 9/9] sandbox: capsule: Generate capsule related files through binman
Hi Sughosh, On Tue, 1 Aug 2023 at 11:41, 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 V5: > * 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. > > arch/sandbox/dts/u-boot.dtsi | 347 ++ > test/py/tests/test_efi_capsule/conftest.py| 128 +-- > .../tests/test_efi_capsule/uboot_bin_env.its | 36 -- > 3 files changed, 348 insertions(+), 163 deletions(-) > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its > I want to get the binman stuff right before diving into this, but the binman stuff seems fairly close, so I'll just mention...do you really need all these combinations of tests? It seems to me that one test is enough. You know that the binman tests will protect the code there, so why test it all over again here? Regards, Simon
[PATCH v6 9/9] 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 V5:
* 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.
arch/sandbox/dts/u-boot.dtsi | 347 ++
test/py/tests/test_efi_capsule/conftest.py| 128 +--
.../tests/test_efi_capsule/uboot_bin_env.its | 36 --
3 files changed, 348 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..ae798660de 100644
--- a/arch/sandbox/dts/u-boot.dtsi
+++ b/arch/sandbox/dts/u-boot.dtsi
@@ -7,11 +7,358 @@
*/
#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"
+
+#define UBOOT_BIN_IMAGE
"test/py/tests/test_efi_capsule/test_files/u-boot.bin.new"
+#define UBOOT_ENV_IMAGE
"test/py/tests/test_efi_capsule/test_files/u-boot.env.new"
+#define UBOOT_FIT_IMAGE"u-boot_bin_env.itb"
+
+#define CAPSULE_PRIV_KEY
"test/py/tests/test_efi_capsule/test_files/SIGNER.key"
+#define CAPSULE_PUB_KEY
"test/py/tests/test_efi_capsule/test_files/SIGNER.crt"
+#define CAPSULE_INVAL_KEY
"test/py/tests/test_efi_capsule/test_files/SIGNER2.key"
+#define CAPSULE_INVAL_PUB_KEY
"test/py/tests/test_efi_capsule/test_files/SIGNER2.crt"
+
/ {
#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
signature {
capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
};
#endif
+
+ binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ itb {
+ filename = UBOOT_FIT_IMAGE;
+
+ 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 = UBOOT_BIN_IMAGE;
+ };
+
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ u-boot-env {
+ description = "U-Boot environment on
SPI Flash";
+ compression = "none";
+ type = "firmware";
+ arch = "sandbox";
+ load = <0>;
+ blob {
+ filename = UBOOT_ENV_IMAGE;
+ };
+
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ };
+ };
+ };
+
+ capsule1 {
+ filename = "Test01";
+ capsule {
+ type = "efi-capsule";
+ image-index = <0x1>;
+ image-type-id = SANDBOX_UBOOT_IMAGE_GUID;
+
+ blob-ext {
+ filename = UBOOT_BIN_IMAGE;
+ };
+ };
+ };
+
+ capsule2 {
+ filename = "Test02";
+ capsule {
+ type = "efi-capsule";
+ image-index = <0x2>;
+
