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 1:56 PM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
>
> 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.
>

Frankly, I'm aggravated by the increased reliance on UEFI features
without fixing Linux's problems with UEFI features. If we stopped
relying on UEFI for the cert store, a lot of my issues would go away,
because then we can design better workflows for managing certificates.
It makes automation possible, it makes management possible, and it
opens the doors to experiment with how to do layered images for boot
(e.g. UKIs + system extension images) without bricking people's
computers.

That also has the side effect of us having half a chance of being able
to port this security capability to non-UEFI platforms where we use
fake UEFI implementations to bootstrap our boot process, because the
amount of coverage required for fake UEFI implementations is
considerably lower now.

More generally, relying on UEFI-specific security features when most
platforms are not being brought up with UEFI is foolish. ARM is almost
entirely non-UEFI (except the tiny proportion of servers that almost
no one has) and RISC-V is not a UEFI platform either. POWER uses
OpenFirmware instead of UEFI, and IBM Z does something else entirely
different.

You *need* to think about these problems when designing this stuff.
You can't take a myopic x86-only view to this. I have not heard of
anything about UKI security for non-x86 because it seems to all be
tied up in UEFI stuff.

Coming back to "my issue", I've had this problem for six years, and
for most of it "the Linux community" (specifically the Linux boot
community) has brushed me off saying my issue doesn't matter. Even if
it leads to bricked systems. Even if it makes it hard for people to
use their computers. Even if it leads to people turning off Secure
Boot. And finally, even if it means people don't use Linux at all
because they can't make it work.

> > > 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.
>

Maybe. It's not super intuitive from where I'm standing, and I know
how all this stuff works.

> > 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?)
>

I do not want to add more things to Fedora that *will* cause people to
potentially brick their systems because they have to screw around with
UEFI to be able to extend what they can use to boot their systems.

Just because today it's only about VMs doesn't mean I can't figure out
you want to do more with it down the road. I want to see some
demonstration of someone actually caring about the user experience for
once with the boot stuff.




--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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