On Thu, Dec 22, 2022 at 5:58 AM Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> 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. > > 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. >
It would definitely make sense to add some documentation about preferred tools, since other distributions will eventually reference our Change document to do UKIs on their own too. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
