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. 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. It could be extended to start with an existing efi binary and e.g. a new initrd or a different commandline, but so far nobody has requested that. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
