| |||||||||||||
Concur with other comments re: restricted bootConcur with other comments re: restricted bootPosted Jan 1, 2013 1:52 UTC (Tue) by dskoll (subscriber, #1630)In reply to: Concur with other comments re: restricted boot by gregkh Parent article: The H Year: 2012's Wins, Fails and Mehs
Microsoft's UEFI rules may currently require this, but Microsoft should not be in a position to make the rules in the first place. Secure Boot rules need to be maintained by an impartial, not-for-profit standards body that has no vested interest in any particular operating system... maybe something like the IEEE. But definitely not in the hands of Microsoft.
(Log in to post comments)
Concur with other comments re: restricted boot Posted Jan 1, 2013 2:25 UTC (Tue) by Trelane (subscriber, #56877) [Link]
And also other keys are worthless since the device firmware (e.g vid card) is signed with only the msft key. So you lose the opportunity to detect hacked firmware.
Concur with other comments re: restricted boot Posted Jan 1, 2013 18:28 UTC (Tue) by gregkh (subscriber, #8) [Link]
Microsoft can make whatever "rules" it wants, it's up to the OEMs if they wish to follow them or not.
It's been this way for over 15 years, this is nothing new at all, Linux has been handling this type of thing (remember the PC99 rules?) and will continue to do so just fine.
The UEFI group has specified what the Secure Boot rules are, and Microsoft, as the signing authority, can do what it wants to do on top of that if it wants to. If you don't like Microsoft's signing authority rules, then work with the OEMs to get your key into the BIOS so that you will not have to worry about anything. But be prepared to work with the OEMs and abide by their requirements, which are very strict.
Concur with other comments re: restricted boot Posted Jan 1, 2013 22:44 UTC (Tue) by dskoll (subscriber, #1630) [Link] Microsoft can make whatever "rules" it wants, it's up to the OEMs if they wish to follow them or not. Translation: Microsoft can make whatever "rules" it wants, it's up to the OEMs to decide whether or not they wish to remain in business. If you don't like Microsoft's signing authority rules, then work with the OEMs to get your key into the BIOS so that you will not have to worry about anything. That's the wrong approach. The right approach is for the UEFI standard to specify a standard way for a computer owner to load keys of his/her choice into the BIOS and indicate that software signed by those keys should be trusted.
Concur with other comments re: restricted boot Posted Jan 1, 2013 22:56 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
UEFI doesn't specify UI.
Concur with other comments re: restricted boot Posted Jan 2, 2013 0:16 UTC (Wed) by dskoll (subscriber, #1630) [Link] I don't understand what you mean by that. Surely someone can write a spec that says something like: "Where a UEFI-enabled motherboard supports optical disk drives or USB mass-storage devices, a certified UEFI BIOS shall provide and document a way to install user-supplied keys in the following standard format from a USB key or optical disk (...)" As long as the key format is documented and the keystrokes / mouse clicks / whatever to get the BIOS to load them are documented, then that should make everyone happy.
Concur with other comments re: restricted boot Posted Jan 2, 2013 0:28 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
How can a firmware spec define the documentation that a system vendor includes?
Concur with other comments re: restricted boot Posted Jan 2, 2013 1:57 UTC (Wed) by dskoll (subscriber, #1630) [Link] How can a firmware spec define the documentation that a system vendor includes? It could work something like this: A disinterested third party owns the trademark to "UEFI" or "Secure Boot" or whatever, and the spec can say that a system vendor cannot claim compliance unless it provides some documented way (that doesn't require permission from a particular vendor) to load user-supplied keys in a standard format. Plenty of specs leave the details up to the specific implementation but still say that there must be some documented way to do something to claim compliance.
Concur with other comments re: restricted boot Posted Jan 2, 2013 2:03 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
UEFI isn't a trademark. The consortium's bylaws do permit the creation and ownership of trademarks, but requires that they be licensed to all members provided that they implement the full set of features or functions. Documentation isn't part of that. Even then, manufacturers would be unlikely to use the trademark and so still wouldn't be bound.
Concur with other comments re: restricted boot Posted Jan 2, 2013 16:25 UTC (Wed) by dskoll (subscriber, #1630) [Link] You are describing what is. I am describing what should be. The only question is how we get from "is" to "should be". Maybe it will take a lawsuit to wrest control away from Microsoft or at least rule that a Windows 8 PC must allow non-secure booting or the ability to install additional signing keys. But something needs to be done to prevent Microsoft from being able to change the Windows 8 PC rules whenever it wants.
Concur with other comments re: restricted boot Posted Jan 2, 2013 16:29 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
That would involve them having actually broken a law. It's not obvious that they have.
Concur with other comments re: restricted boot Posted Jan 2, 2013 16:41 UTC (Wed) by dskoll (subscriber, #1630) [Link] Microsoft probably has not broken any law with their Windows 8 rules. But monopolies can be and are regulated before they break any laws. It just takes political will.
Concur with other comments re: restricted boot Posted Jan 3, 2013 8:43 UTC (Thu) by ebirdie (subscriber, #512) [Link]
Affecting to the political will is very very unpractical mission in this context IMHO. Although I do agree it is a good mission for already established free software organizations to get people and companies aware that monopolies are bad, really bad, for their economy and wellbeing, exception where the monopoly directly feeds them, and make cases, how this particular monopoly affects in various ways. Still it is a long shot and will get heavy countermeasures, which may hold the organizations from the mission in the first place.
Concur with other comments re: restricted boot Posted Jan 3, 2013 9:23 UTC (Thu) by dskoll (subscriber, #1630) [Link] I'm more optimistic than you. This fight only has to be won in one largish jurisdiction. Imagine if a government of a medium-sized country mandated that all systems it purchases (or better, all systems sold in that country) must permit end-users to disable secure boot and/or install their own keys. We'd win everywhere because motherboard manufacturers are not going to make special-case systems for one jurisdiction, nor would they be willing to cede that market to competitors. Yeah, there's no political will in the US, whose government is utterly dysfunctional anyway, but we should press this issue everywhere.
Concur with other comments re: restricted boot Posted Jan 3, 2013 15:42 UTC (Thu) by andrel (subscriber, #5166) [Link]
The US federal legislature is dysfunctional. Many other branches of government within the country are not. In particular, Sacramento probably became a lot more functional after the last election.
As you say, no mobo manufacturer is going to cede the California market.
Concur with other comments re: restricted boot Posted Jan 3, 2013 15:55 UTC (Thu) by gregkh (subscriber, #8) [Link]
Again, all x86 UEFI systems today that ship, already have the ability for a user to disable secure boot and add their own keys to the system to allow them to use secure boot with their own control.
So "mandating" this isn't really going to change anything.
Unless you really care about ARM UEFI systems, and if so, why?
Concur with other comments re: restricted boot Posted Jan 3, 2013 16:44 UTC (Thu) by dskoll (subscriber, #1630) [Link] So "mandating" this isn't really going to change anything. It certainly will:
Microsoft currently sets the rules, but please tell me what the penalty is for "accidentally" selling a system that only boots Windows?
Concur with other comments re: restricted boot Posted Jan 3, 2013 17:04 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Supposedly, their membership in the certification program is terminated. If you find any examples, let me know and we'll find out.
Concur with other comments re: restricted boot Posted Jan 4, 2013 15:19 UTC (Fri) by dskoll (subscriber, #1630) [Link] Well, did Lenovo fix this bug or have they just not cared?
Concur with other comments re: restricted boot Posted Jan 4, 2013 15:29 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
That's got nothing to do with the shim approach, so it doesn't seem like what Jon's talking about.
Concur with other comments re: restricted boot Posted Jan 4, 2013 14:34 UTC (Fri) by wookey (subscriber, #5501) [Link]
I care about ARM UEFI systems because there are going to be lots of them. Just as many as x86 one day (very probably). It's vital that people have the same rights to install the OS of their choice as on x86.
At the moment OEMs cannot let people install their own keys _and_ enable Windows to run on their hardware (right?). They shouldn't have to make that choice. OEMs and purchasers will have to choose whether they want to make/sell/buy 'ARM hardware for Windows' or 'ARM hardware for everything else'. ARM servers are general-purpose in just the same way x86 ones are (and will look almost identical from the software perspective once both are booted with UEFI). Dominent-vendor rules like these are at best very unhelpful.
Hopefully it will keep both OEMs and pruchasers away from Microsoft until they are forced to change the rules, but it could turn out to just be a massive pain for everyone.
Anyone who says 'It's OK because I can install my keys on x86 - ARM is just for devices where no-one changes the OS' is being very shortsighted.
Concur with other comments re: restricted boot Posted Jan 4, 2013 15:41 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
Microsoft doesn't currently support anything but Windows RT on ARM, so from the server side there's no problem for at least a couple of years yet.
|
|||||||||||||