On 10/26/22 10:08, Richard Purdie wrote:
> On Fri, 2022-10-21 at 19:37 -0400, Sean Anderson wrote:
>> The U-Boot signing code is a bit of a mess. The problem is that mkimage
>> determines the public keys to embed into a device tree based on an image
>> that it is signing. This results in all sorts of contortions: U-Boot has to
>> be available to the kernel recipe so that it can have the correct public
>> keys embedded. Then, the signed U-Boot has to be made available to U-Boot's
>> do_deploy. This same dance is then repeated for SPL. To complicate matters,
>> signing for U-Boot and U-Boot SPL is optional, so the whole process must be
>> seamlessly integrated with a non-signed build.
>>
>> The complexity and interdependency of this process makes it difficult to
>> extend. For example, it is not possible to install a signed U-Boot binary
>> into the root filesystem. This is first because u-boot:do_install must run
>> before linux:do_assemble_fitimage, which must run before u-boot:do_deploy.
>> But aside from infrastructure issues, installing a signed U-Boot also can't
>> happen, because the kernel image might have an embedded initramfs
>> (containing the signed U-Boot).
>>
>> However, all of this complexity is accidental. It is not necessary to embed
>> the public keys into U-Boot and sign the kernel in one fell swoop. Instead,
>> we can sign the kernel, stage it, and sign the staged kernel again to embed
>> the public keys into U-Boot [1]. This twice-signed kernel serves only to
>> provide the correct parameters to mkimage, and does not have to be
>> installed or deployed. By cutting the dependency of
>> linux:do_assemble_fitimage on u-boot:do_install, we can drastically
>> simplify the build process, making it much more extensible.
>>
>> The process of doing this conversion is a bit involved, since the U-Boot
>> and Linux recipes are so intertwined at the moment. The most major change
>> is that uboot-sign is no longer inherited by kernel-fitimage. Similarly,
>> all U-Boot-related tasks have been removed from kernel-fitimage. We add a
>> new step to the install task to stage the kernel in /sysroot-only. The
>> logic to disable assemble_fitimage has been removed. We always assemble it,
>> even if the final fitImage will use a bundled initramfs, because U-Boot
>> will need it.
>>
>> On the U-Boot side, much of the churn stems from multiple config support.
>> Previously, we took a fairly ad-hoc approach to UBOOT_CONFIG and
>> UBOOT_MACHINE, introducing for loops wherever we needed to deal with them.
>> However, I have chosen to use a much more structured approach. Each task
>> which needs to use the build directory uses the following pseudocode:
>>
>> do_mytask() {
>> if ${UBOOT_CONFIG}; then
>> for config, type in zip(${UBOOT_CONFIG}, ${UBOOT_MACHINE}); do
>> cd ${config}
>> mytask_helper ${type}
>> done
>> else
>> cd ${B}
>> mytask_helper ""
>> fi
>> }
>>
>> By explicitly placing the work in mytask_helper, we make it easier to
>> ensure that everything is covered, and we also allow bbappends files to
>> more easily extend the task (as otherwise they would need to reimplement
>> the loop themselves).
>>
>> [1] It doesn't particularly matter what we sign. Any FIT will do, but I
>> chose the kernel's because we already went to the trouble of setting it up
>> with the correct hashes and signatures. In the future, we could create a
>> "dummy" image and sign that instead, but it would probably have to happen
>> in the kernel recipe anyway (so we have access to the appropriate
>> variables).
>>
>> Signed-off-by: Sean Anderson <sean.ander...@seco.com>
>> ---
>>
>> meta/classes-recipe/kernel-fitimage.bbclass | 68 +---
>> meta/classes-recipe/uboot-config.bbclass | 3 +
>> meta/classes-recipe/uboot-sign.bbclass | 421 +++++++++-----------
>> meta/lib/oeqa/selftest/cases/fitimage.py | 29 +-
>> meta/recipes-bsp/u-boot/u-boot.inc | 3 -
>> 5 files changed, 226 insertions(+), 298 deletions(-)
>
> This looks like a pretty nice improvement, I've been worried about how
> entangled all this was becoming. Is there anything better we could do
> with testing of this code? We rely increasingly on the tests to spot
> regressions and I doubt the testcases we have cover the code
> complexity.
FWIW, I found the test suite to be fairly helpful when debugging this
whole process, if agonizingly slow. I found many bugs in my initial
implementation which were uncovered by the test suites,
The best way to extend the test suite would probably be to have QEMU try
to boot using the Linux and U-Boot. This would help cases where all the
artifacts are created correctly but e.g. the wrong U-Boot is packaged.
However, I am rather loathe to add more test cases like this, because it
already takes around 10 minutes (with sstate!) to run the tests. This
basically kills the speed of iterative development.
--Sean
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172163):
https://lists.openembedded.org/g/openembedded-core/message/172163
Mute This Topic: https://lists.openembedded.org/mt/94487631/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
