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 Tue, Dec 20, 2022 at 9:10 PM Kevin Kofler via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Daniel P. Berrangé wrote:
> > That is not correct. There are a number of benefits of UKIs.
> >
> > The most critical is that the initrd content and cmdline is
> > covered by the SecureBoot signature.
>
> From an end user point of view, having more stuff covered by Restricted Boot
> is not a benefit.
>

I do believe Secure Boot can provide value, but we need to consider it
only as "bootstrap security" rather than "boot security". On its face,
it's pretty absurd to restrict operating system content to pre-boot
signatures. The original goal of secure boot support in Linux was to
support the de minimis effort to enable Free platforms to work on PCs
where it may not be easy or possible to turn off Secure Boot. There
was a very real fear that it would be a reality, which is why we sign
our boot code with the Microsoft certificate. But our design
deliberately uses the Microsoft certificate to chain into our own.

Where we fell apart compared to Windows and macOS is that we decided
that we wanted to have all kernel code locked down exclusively by
either firmware certificates or hardcoded certificates in shim. In
retrospect, this was a bad move because it crippled our ability to
enable driver integrity protection for the operating system using
similar techniques used by other operating systems. On the flip side,
because our own ability to enable and support operating system trust
was hamstrung by firmware certificates, we did finally get NVIDIA to
open up[1]. Was it the right decision anyway? I don't think so. The
way the UAPI group envisions system security clearly shows where this
falls apart: we increasingly rely on parts of the system that we have
no influence on to guide our system integrity protection.

Secure Boot would have been great if it was designed as a
user-friendly way to establish and control system content trust. But
that's not how it works in practice at all. And the sheer amount of
resistance around making it work that way demonstrates how much of a
failure it is for that purpose. And it bears repeating: Windows
doesn't use Secure Boot for system integrity protection. It has its
own in-OS mechanisms instead.

As someone whose day job involves working with teams who develop both
Windows and Linux drivers (and in the past, even macOS drivers!), I
can categorically say that Windows driver engineering processes are
way friendlier than Linux ones, precisely because Windows drivers are
deliberately not exposed to Secure Boot *at all*. Running development
versions of drivers just requires installing a development certificate
into the NT kernel certificate store. The equivalent process for Linux
is to load a custom secure boot certificate into firmware, which is
fraught with peril and potentially not even possible. I cannot tell
you how many times I've bricked a system by attempting to load another
cert only to find out there's not enough space and the firmware didn't
handle that well.

We've failed here, badly. And nobody cares.


[1]: https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/


-- 
真実はいつも一つ!/ 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