On Thu, Dec 22, 2022 at 10:58:11AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Dec 21, 2022 at 06:56:05PM +0100, Björn Persson wrote: > > Gerd Hoffmann wrote: > > > On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote: > > > > And if you chose your HW carefully you may even be able to register > > > > your own public keys, generate and sign your own built UKIs and re- > > > > enable SecureBoot after that... your choice! > > > > > > And when your hardware doesn't allow that you can still add your own > > > keys with mokutil so shim.efi will accept your self-signed UKIs. > > > > I'll see when I can take the time for a research project to figure out > > how customized UKIs can be produced, and develop a tool to do that. > > Probably never, because I have way too much to do already. > > > > Apparently there is no such tool and no plan to provide one, because > > surely that would have been mentioned under "User Experience". > > The tools are already there. Essentially, any tool used in koji by the > official > builds is also available to you on your machine. > > There are at three ways that are used: 'dracut --uefi', systemd's ukify, and a > manual objcopy invocation. The first two are wrappers around objcopy. I'm > biased > because I wrote 'ukify', but I think that's the way to go. What dracut does is > somewhat primitive and doesn't get the offsets right. Obviously it could be > improved, but putting the code to generate UKIs inside of an initrd generator > is > a historical accident, and bash is not the nicest language to do offset > calculations. Thus I hope we can standarize on ukify instead.
When you say it dooesn't get the offsets right, can you elaborate ? We've been using dracut --uefi to build the UKIs in koji and they appear to work as expected. Are the offsets only incorrect in certain circumstances. We're pretty ambivalent about choice of tool though. We just picked dracut as it was the first we came across and appeared to work. Any other tool is viable as then should all (generally) end up doing the same thing, whichever is most maintainable sounds good. I can't argue with Python being better than shell, so ukify certain wins on that score :-) > In particular, if some functionality is missing from ukify, feel free to > submit > a PR or an issue. It's in Python, so fairly nice to modify. So far it's been > written to take a kernel and an initrd and the stub, and produce an efi > binary. Currently we just ask dracut to create the UKI and it creates the intird as part of that process. If using ukify, we would ask dracut to create the initrd, and then ask ukify to build that into a UKI. Its more work, but if ukify does a better job at the UKI bits that's fine, especially if we'd be suggesting use of ukify for users in general. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
