[SRU] backport mkeficapsule to jammy

[Aristo Chen]

[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

[Heinrich Schuchardt (xypron)]

The U-Boot v2022.01 source code already contains mkeficapsule. Do you plan to backport any patches from higher U-Boot versions or do you simply want to change the list of installed files in u-boot-tools?

[Aristo Chen (aristochen)]

Hi Heinrich,

Thanks for replying so fast! sorry that I haven't put all the required info in this bug yet. I am still building the debian package in PPA, but I would need to put the bug number in changelog, so I open the bug first without having all info ready

I am planning to backport some patches from higher U-Boot versions for mkeficapsule, will update the bug once everything is ready, thanks!

[Aristo Chen (aristochen)]

This is the test result for test case 2 mentioned in bug description

[Aristo Chen (aristochen)]

This(https://launchpad.net/~aristochen/+archive/ubuntu/dev-amd64/+packages) is the PPA that I used for building a test debian package, and the debian package was used for the test case 1 mentioned in bug description

[Heinrich Schuchardt (xypron)]

Hello Aristo,

in your mkeficapsule.log the following tests are skipped:

test/py/tests/test_efi_capsule/test_capsule_firmware.py
test/py/tests/test_efi_capsule/test_capsule_firmware_signed.py

I guess test_capsule_firmware.py is skipped due to missing local tools.

By adding -ra as pytest argument you should see the reason for skipping:
./test/py/test.py -ra --bd sandbox --build

See this line in test/py/tests/test_efi_capsule/conftest.py:
pytest.skip('Setup failed: %s' % exception.cmd)

When I run on my system
'make tests' passes test/py/tests/test_efi_capsule/test_capsule_firmware.py

With CONFIG_EFI_CAPSULE_AUTHENTICATE=y added to sandbox_defconfig the package also passes
test/py/tests/test_efi_capsule/test_capsule_firmware_signed.py.

I would suggest to add the following information to debian/changelog:

"mkeficapsule with the patches applied matches U-Boot v2022.04."

Best regards

Heinrich

[Aristo Chen (aristochen)]

Hi Heinrich,

thanks for the suggestions! I was not that familiar with testing U-Boot, it turns out that I need to install efitools and libguestfs-tools, and then run the test with sudo permission

I will update the test result later and try to build a new debian package in PPA, will update here once it's done

Best regards,
Aristo

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "jammy.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Aristo Chen (aristochen)]

This is the test result after installed required debian packages and run with sudo permission

[Aristo Chen (aristochen)]

This is the debdiff for Jammy, and I have deleted previous jammy.debdiff to prevent confusion

[Dave Jones (waveform)]

Trying to channel the SRU team, a couple of things I'd point out that may need some clarification in the bug description:

* Does this also need back-porting to lunar? We shouldn't have a situation where something is fixed in jammy but regresses for people upgrading to lunar (ignore this if these changes are already present in the lunar version)

* The Impact specifies what the bug is doing but not really what the "impact" actually is. What will it mean for users if this bug is *not* fixed? It may also be useful to describe precisely what firmware we're talking about (typically most firmware comes from the linux-firmware package but I'm guessing we're talking about early-boot related firmware here).

* In the Test Case is there enough information for people other than the reporter to test the fix?

* In the regression potential: as I understand it from the patches, there's *some* mkeficapsule code already in the jammy version but it's not built as part of u-boot-tools. Is that mkeficapsule code solely used by the mkeficapsule binary, or does patching it affect anything else in u-boot (i.e. does anything else pull in any parts of mkeficapsule)? If not, it's probably worth mentioning that mkeficapsule is "standalone" and these patches affect nothing other than a binary that isn't currently built in the jammy version.

[Aristo Chen (aristochen)]

Hi Dave,

Thanks for the reply, I have updated the bug description, hopefully it answers all your questions, thanks!

[Brian Murray (brian-murray)]

I've uploaded this to the SRU queue for Jammy. Thanks!

[Steve Langasek (vorlon)]

Hello Aristo, or anyone else affected,

Accepted u-boot into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/u-boot/2022.01+dfsg-2ubuntu2.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted u-boot (2022.01+dfsg-2ubuntu2.5) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

livecd-rootfs/2.765.26 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#u-boot

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Aristo Chen (aristochen)]

Hi,

I have done the verification, and prove it's working fine by following the test steps mentioned in bug description

attached the log of test result

[Chris Halse Rogers (raof)]

Marking as fixed in Ubuntu, as per comment that these changes are already in Lunar.

[Launchpad Janitor (janitor)]

This bug was fixed in the package u-boot - 2022.01+dfsg-2ubuntu2.5

---------------
u-boot (2022.01+dfsg-2ubuntu2.5) jammy; urgency=medium

  * Support mkeficapsule command to generate capsule file (LP: #2036406)
  * mkeficapsule with the patches applied matches U-Boot v2022.04.
  * Update test script related to efi_capsule

 -- Aristo Chen <email address hidden> Mon, 18 Sep 2023 11:02:43 +0800

[Chris Halse Rogers (raof)]

The verification of the Stable Release Update for u-boot has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.