[Bug 2036406] Re: [SRU] backport mkeficapsule to jammy

[Heinrich Schuchardt]

** Description changed:

  [Impact]
  
- * mkeficapsule is a standalone command used to generate capsule file for updating firmware in u-boot
- * mkeficapsule code exists in Jammy already, but not shipped in u-boot-tools debian package, so users are not able to generate capsule file in Jammy environment, and since the mkeficapsule command is not available in Jammy, ideally no one should be impacted.
+ * mkeficapsule is a standalone command used to generate a capsule file for updating specially configured U-Boot (not only on SD card but also on SPI flash and other media) and possibly other firmware like TF-A.
+ * mkeficapsule code exists in Jammy already, but is not shipped in the u-boot-tools Debian package, so users are not able to generate capsule file in Jammy environment, and since the mkeficapsule command is not available in Jammy, ideally no one should be impacted.
  
  [Test case]
  
  Test case 1:
  Users can use mkeficapsule to generate capsule file which contains firmware, or anything they want, such as dtb or fip.bin, we use mkeficapsule to create a capsule file that contains U-Boot in this test case
  prerequisite:
  1. Please prepare a device that is capable to use capsule file to update firmware
  2. Prepare your own key by this command
-    $ 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 SIGNER.key -out SIGNER.crt -nodes -days 365
  steps:
  1. use mkeficapsule command to generate test_new.cap and test_old.cap, both contain U-Boot built at different time
-    $ mkeficapsule --private-key SIGNER.key --certificate SIGNER.crt --monotonic-count 1 --instance 0 --index 2 --guid "12345678-abcd-1234-5678-12345678abcd" test.bin test_new.cap
+    $ mkeficapsule --private-key SIGNER.key --certificate SIGNER.crt --monotonic-count 1 --instance 0 --index 2 --guid "12345678-abcd-1234-5678-12345678abcd" test.bin test_new.cap
  2. Put the capsule file to required path(both test_new.cap and test_old.cap)
  3. Reboot device and stop at u-boot prompt, then type the command. Note the actual location of test_new.cap may bedifferent in your case
-    => efidebug boot add -b 0 0 mmc 0:8 test_new.cap
+    => efidebug boot add -b 0 0 mmc 0:8 test_new.cap
  4. The device should reset and check if the U-Boot build stamp is different from previous
  
  Test case 2:
  1. sudo apt install efitools libguestfs-tools
  2. Add CONFIG_EFI_CAPSULE_AUTHENTICATE=y to configs/sandbox_defconfig
  3. Follow the command here(https://u-boot.readthedocs.io/en/latest/develop/testing.html#pytest-suite) to test with U-Boot sandbox, the command needs to be run as sudo, otherwise the test_efi_capsule related test cases will be skipped, the test result can be found in comment #9
  
  [Where problems could occur]
  
  * There is no mkeficapsule command in Jammy yet, and mkeficapsule is a
  standalone tool, so the regression risk should be low
  
  [Other Info]
  * These patches are already in Lunar, so we only need to backport to Jammy

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to u-boot in Ubuntu.
https://bugs.launchpad.net/bugs/2036406

Title:
  [SRU] backport mkeficapsule to jammy

Status in OEM Priority Project:
  Confirmed
Status in u-boot package in Ubuntu:
  New

Bug description:
  [Impact]

  * mkeficapsule is a standalone command used to generate a capsule file for updating specially configured U-Boot (not only on SD card but also on SPI flash and other media) and possibly other firmware like TF-A.
  * mkeficapsule code exists in Jammy already, but is not shipped in the u-boot-tools Debian package, so users are not able to generate capsule file in Jammy environment, and since the mkeficapsule command is not available in Jammy, ideally no one should be impacted.

  [Test case]

  Test case 1:
  Users can use mkeficapsule to generate capsule file which contains firmware, or anything they want, such as dtb or fip.bin, we use mkeficapsule to create a capsule file that contains U-Boot in this test case
  prerequisite:
  1. Please prepare a device that is capable to use capsule file to update firmware
  2. Prepare your own key by this command
     $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/ -keyout SIGNER.key -out SIGNER.crt -nodes -days 365
  steps:
  1. use mkeficapsule command to generate test_new.cap and test_old.cap, both contain U-Boot built at different time
     $ mkeficapsule --private-key SIGNER.key --certificate SIGNER.crt --monotonic-count 1 --instance 0 --index 2 --guid "12345678-abcd-1234-5678-12345678abcd" test.bin test_new.cap
  2. Put the capsule file to required path(both test_new.cap and test_old.cap)
  3. Reboot device and stop at u-boot prompt, then type the command. Note the actual location of test_new.cap may bedifferent in your case
     => efidebug boot add -b 0 0 mmc 0:8 test_new.cap
  4. The device should reset and check if the U-Boot build stamp is different from previous

  Test case 2:
  1. sudo apt install efitools libguestfs-tools
  2. Add CONFIG_EFI_CAPSULE_AUTHENTICATE=y to configs/sandbox_defconfig
  3. Follow the command here(https://u-boot.readthedocs.io/en/latest/develop/testing.html#pytest-suite) to test with U-Boot sandbox, the command needs to be run as sudo, otherwise the test_efi_capsule related test cases will be skipped, the test result can be found in comment #9

  [Where problems could occur]

  * There is no mkeficapsule command in Jammy yet, and mkeficapsule is a
  standalone tool, so the regression risk should be low

  [Other Info]
  * These patches are already in Lunar, so we only need to backport to Jammy

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/2036406/+subscriptions