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 Di, 20.12.22 17:11, Neal Gompa (ngompa13@xxxxxxxxx) wrote:

> > SecureBoot may not be to your liking but is what is installed on 99% of
> > modern hardware sold, so it is a good idea to first show you can
> > support it. Then if you have interested you can propose "something
> > better".
>
> We have supported Secure Boot for over a decade now. In that timeframe,
> literally nobody did anything to make all the workflows you talk about
> easier and friendlier.
>
> In fact, everyone I talk to seems to think it's basically impossible
> because of how it works at the firmware level.
>
> It's telling that neither Windows nor macOS use Secure Boot like Linux
> does. And they don't precisely for the reasons I outlined.

Yes, Linux never solved the initrd hole so far, but that's not really
the fault of SecureBoot, it's the fault of Linux if you so
will. And this proposal is an attempt to finally do something about
this, and get things in order to actually deliver what the other OSes
all are delivering.

I understand the big issue you have is that the certificate store for
Linux (i.e. the mokutil db) is limited in size because EFI variable
NVRAM is limited in size? If that's the big issue you are having then
that's absolutely something the Linux community can fix, and can
address. Specifically, shim could allow storing the cert store on
disk, and authenticate it at boot via the TPM. Not trivial, but
doable. And certainly not the firmware's fault...

I mean, UEFI has its warts, but I don't see that it's UEFI's fault if
the way Linux/shim/mokutil implement the cert db is done the way it is
currently done.

> > Finally, unless this proposal harms Fedora I do not see why oppose it.
> > If, as you fear, it won't work ... then it won't and we'll try
> > something else. However, having some knowledge of the (security side of
> > the) matter I do not see why it wouldn't work, once all the pieces fall
> > in place.
>
> This adds significant complexity to the Fedora kernel package and it
> effectively increases what we need to test for virtualized Fedora Linux
> environments.

Nah. UKIs + sysext are ultimately something that is simpler and much
better to test than the current mess. Yeah, for a while we'll have to
add complexity because to mechanisms will have to be supported, but
eventually things are going to be simple and easier to test.

> I assert that the proposal has not yet met the bar to overcome those
> issues.

If the "those issues" is supposed to be that you hit the size of the
mokutil cert store once, then I fail to see the relationship to
UKI/sysext. After all, the fedora signing keys for sysexts would be
built into the kernel and hence not be charged against NVRAM. And the
fedora UKI is signed with the same key as our current kernels, which
are also not charged against NVRAM but are built into fedora shim. And
the shim signature key is the msft key.

Yeah, if you want to build your own UKIs + sysext, then you have to
use mokutil to enroll a cert, but it would be entirely sufficient to
enroll one for that, and sign UKIS, kmods, sysext with them.

(or, maybe you actually hit the NVRAM size limits because you enrolled
hashes, not certs? if so, then maybe address that?)

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
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