On Tue, Dec 20, 2022, 4:27 PM Simo Sorce <s...@redhat.com> wrote: > On Tue, 2022-12-20 at 14:29 -0500, Neal Gompa wrote: > > Yeah, I seriously doubt this. Linux's model for supporting > > confidential computing is not user-friendly, so I expect low adoption > > and resistance once the flaws become apparent to would-be users. > > > > Neal, you are being unnecessarily negative. And user-friendliness is > directly related to the fact we do not have good support for it. This > proposal would make SecureBoot fundamentally transparent, and if you > don't see it and it works, I see no resistance happening. > > 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. 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. I assert that the proposal has not yet met the bar to overcome those issues. In fact I would love to be able to test this, every time I run updates > I dread the many minutes wasted regenerating initrd when I have a > pretty standard configuration that requires really no special > drivers... the only issue probably being the use of LVM for the root > filesystem, which I hope we'll have a way to deal with (but I can do > without on the laptop). > UKIs need more work to be generally useful, but that would be nice to eliminate if the issues could be fixed. >
_______________________________________________ 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
