Re: New memory tester application potentially to replace memtest86+: PCMemTest

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

 



On Mon, Feb 8, 2021 at 9:13 PM Kevin Kofler via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Chris Murphy wrote:
> > If you want to take the risk of acquiring a rootkit that can
> > permanently take control of your firmware, that is up to you. It
> > should not be a distribution recommendation to subject users to such
> > bad advice.
>
> And the "good advice" would be to accept that your computer will only run
> operating systems approved by Microsoft and to accept a security model that
> prevents basic functionality such as hibernation, third-party kernel
> modules, etc.?
>

Don't blame Microsoft for our failings. The fact that we can't do
hibernation or offer an easy path for third-party kernel modules to
function in a Secure Boot environment is *entirely* our fault. After
shim->grub2, Microsoft's trust ends and ours begins. We use *our*
certificate from GRUB onward.

The fact that hibernation is broken in Secure Boot is entirely the
fault of the engineers that were in charge of developing the Fedora
kernel and bootloader security mechanism, because they created the
patch set that made it functionally impossible to make it work. That
is, it's the LOCKDOWN feature layered on Secure Boot, not Secure Boot
itself. It's obvious Secure Boot itself is no impediment to
hibernation, since both Windows and macOS (both users of Secure Boot)
can do hibernation just fine.

The fact that third-party kernel modules are nearly impossible to set
up in Secure Boot is entirely the fault of engineers who designed the
certificate trust mechanism to not offer a path for semi-interactive
or non-interactive trust scenarios like we have for package and
repository signatures. It is theoretically possible for third-party
stuff to work in a Secure Boot environment, but the path to get there
is so onerous because nobody who makes this stuff for Linux cares to
make this easy to work with. The trust mechanisms for Secure Boot are
not fundamentally any different from how trust works for GPG (they're
both rooted in PKI architectures). The difference is that expanding
trust at the Linux kernel level is deliberately under-documented and
considered unsupported. Additionally, creating signed kernel module
packages has been broken since the beginning, since nobody cared to
actually *fix* the kernel module packaging system to account for it.

I've been trying to untangle this mess for months because I'm
frustrated by how stupid the situation is and how we've never *tried*
to make having a secure system easier.

None of this had to be this way. It is so by our own inaction, not by
the action of Microsoft.

> And for the record, my computer's UEFI firmware is so old that "Secure Boot"
> cannot even be enabled at all, even if I wanted to.
>

Meh. That means your computer was made before Microsoft started having
vendors require UEFI firmware to include their keys for Windows
certification (which was in 2006/2007). I'm surprised it still works.
More power to you, I guess?



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




[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