Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux