Hi Jan, > > Changes in v3: > > - address/suppress cppcheck findings > > - add required build dependency on version.h > > - address pycodestyle findings > > - add documentation > > > > Changes in v2: > > - fix script for more picky UEFI firmware than U-Boot (now tested also > > against OVMF on x86) > > - move/rename script to tools/bg_gen_unified_linux and install it > > - build fixes under Debian 10 > > - avoid dtb-related output of stub under x86 > > > > Add a stub and generator script to build inified Linux images that > > contain kernel, command line, initrd and device trees into a single UEFI > > executable. This is an important building block for secure boot under > > UEFI. > > > > In contrast to the existing solution by systemd, this one comes with > > support for multiple device trees that permits running the same image > > on similar but not identical hardware platforms. Although the trend goes > > towards firmware provided device tree, replacements in lock-step with > > kernel updates will remains important in the foreseeable future, and > > this stub accounts for it. > > > > Furthermore, this approach here has a more user-friendly python-based > > generator script which does not depend on too-new binutils or LLVM > > versions and allows to simplify the Linux stub by arranging data in the > > required way already during generation. > > Just realized that the corresponding generator script for systemd is > dracut --uefi. But that one has the same binutils dependency as it > simply wraps the objcopy call. > > > > > These patches have been moderately tested only, primarily on ARM64. The > > next planned step is a test integration with isar-cip-core. Still, > > reviews would already be welcome. > > I should have dropped that paragraph: The code is not pretty well > tested, specifically using [1]. > > One thing I'm not yet sure about is a naming. I used "unified Linux > image" fairly consistently here while systemd talks about "unified > kernel image". I wanted to make the Linux focus clearer and the fact > that it's at least internally not the same (different interface between > generator and stub). OTOH, "unified kernel image" might already be an > established term for the result you get and boot. Thoughts?
Hm, the term "Unified Kernel Image" is already properly coined and documented in systemd (e.g., [1]) and distributions, so deviation from it should have good arguments. >From my perspective it's very abstractly speaking the general concept of packing it all up into one fat EFI binary so that it can be properly Secure Booted ― which is a technical limitation as EFI can only check PE/COFF executable files. So, in this sense, we're doing "Unified Kernel Image" although with some technical differences, don't we? Now, does this justify putting a different label on it as it's not *technically* the very same thing although conceptually it is? I would go along with the "Unified Kernel Image" label and point out/explain the technical differences somewhere in the docs/README. YMMV though.... Kind regards, Christian [1] https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images -- Dr. Christian Storm Siemens AG, Technology, T CED SES-DE Otto-Hahn-Ring 6, 81739 München, Germany -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/20220427145841.bthanghj47423rdi%40cosmos.fritz.box.
