Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions

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

 



Alan Cox writes:

Its a feature of the hardware design. It was designed into the UEFI
secure boot set up from the start for the same reasons a web browser
needs to be able to revoke keys.

Yes, but for that, the firmware will either need support from the OS it secure-boots, to go out on the network, check for revocations, and upload them into firmware; or the firmware itself must implement a bare-bones network stack, initialize the onboard NIC, obtain a DHCP address, or load a static IP config, then check for CRLs.

Before it boots the OS.

With the former, since it would be loading malware that piggy backs on the signed free OS, the malware can take care of pacifying the firmware. I can't see the latter happening (at least not on consumer hardware, server hardware that can take ages to POST might be able to swing it), but, who knows, stranger things have happened.

> Can you point me to any OEM that indicated that they will make hardware that
> implements user-installed keys?

Hopefully there will be enough of an explosion that this changes but it
will probably depend upon competition regulators and lobbying from
supportive politicians in the EU.

I think that's going to be how it plays out. EU will require firmware to support user-installed keys. OEMs that sell to EU will have to support user- installed keys. EU hardware will then have to find its way back into the rest of the world. It remains to be seen if Microsoft will succeed in banning imports of EU hardware into other parts of the globe, as contraband.

If Red Hat have any sense they will take up the offers to get their key
into as many BIOSes as they can and sign with both. That way Microsoft
can't screw them over later even if they want to.

They certainly can screw them. Easily. Like I said, I fully expect a future Microsoft OS to require Microsoft-signed firmware. And, whether or not it's going to be an official requirement, a Microsoft-signed firmware cannot have the ability to install other keys. This may not certainly not be written or published anywhere. But that's simply what's going to happen.

Even if Red Hat gets their keys into some OEM firmware, as long as there is some non-trivial amount of OEMs who will agree to Microsoft's requirements, the rest of the OEM will then have to pick whether to support Microsoft or non-Microsoft OS on their hardware.

It's already been established that, in the past, Microsoft required PC OEMs to license their OS for all hardware they sold, whether it ran their OS or not. This is just the next logical step, and it takes the enforcement into the hardware layer. Even if the PC EOMs did not sold other OSes, you can still install them on their hardware, mostly. No such option will exist for hardware-enforced OS lockdowns.

> You really think that any OEM will fight this? Why should they?

If it hurts their business for one, and in order not to be considered
part of a cartel may be another (as whistle blowing a cartel usually
mostly exempts you from damages for it...)

They won't have a choice. Microsoft will require that all hardware an OEM makes must be signed by their key, or none at all. Hardware OEMs will have to choose whether their entire product line will only support a Microsoft OS, or all other OSes. No collusion between OEMs will be necessary. Each OEM can document how they arrived at their decision independently.

Attachment: pgp7Heuk_Y95s.pgp
Description: PGP signature

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux