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

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

 



Neal Gompa wrote:
> 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.

Sorry, there is a misunderstanding there. I did not intend to blame 
Microsoft for the restrictions within the kernel Linux imposed by the 
security model. There are 2 separate issues here:

1. Any operating system (in practice, the initial bootloader, shim in our
   case, but that is shipped by the operating system) must be signed by
   Microsoft to boot at all. AND
2. The security model prevents basic Linux kernel functionality.

Both are ultimately failures of the UEFI spec and not of Microsoft. 
Microsoft is not a party to issue 2 at all.

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

The thing is, the engineers claim that this LOCKDOWN "feature" is necessary 
to comply with the Secure Boot spec. I know some other distributions have a 
different interpretation, which makes this security entirely moot, because 
if the non-locked-down kernels break the security model, it is enough to 
have one distribution offering a signature path to such a kernel and the 
security model is already broken. But despite that, Red Hat does not want to 
take the risk of being held responsible for breaking the security model.

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

I don't know what they do differently. All I know is that it is not allowed 
by the Fedora kernel under Secure Boot restrictions.

There are also other, more subtle restrictions, such as banning even root 
from accessing kernel memory.

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

It is actually an ASUS P8Z68-V motherboard, introduced in 2011. It is 
labeled as "Windows 7 ready". According to:
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot_criticism
the Secure Boot requirement was introduced with the Windows 8 certification 
in 2011, which my motherboard predates.

        Kevin Kofler
_______________________________________________
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