The crazy thing about this is that one proposed solution, that MS require OEMs to supply keys for Linux, could potentially be an antitrust violation, as MS makes money from Linux too (thereby using their Windows monopoly to strengthen their other business of patent licensing).
I don't think there's much of a case here. The UEFI hardening is clearly a good thing for consumers, and having it as a logo requirement just makes sense. And if MS is not using any influence to block other OSes, that seems like the best you can ask for. And recall, OEMs can always ship without Win8 logo and not use hardening (or even UEFI at all).
* From the Garrett post ( http://mjg59.livejournal.com/138973.html ): "Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled"
* From the IT World post linked up here: "And not just any old UEFI layer, either, but secure UEFI. Meaning a hardened boot process"
What am I mis-reading or missing? I'm not being testy, I just think you must have spotted something I missed. Thanks
Actually, I mistyped. I meant to type, "OEMs can always ship withOUT Win8 logo and not use ...". I've changed the post to now reflect that. Meaning that OEMs needn't ship certified Windows 8 boxes and can still use BIOS if they want.
I think the flip side to this discussion is that there are ALSO Linux logo programs (for at least RedHat) that will encourage the hardware manufacturers to allow major Linux providers to use their keys.
That said, while Ubuntu, RedHat, Suse and other larger Linuxes might be able to swing this for server equipment, someone trying to run a less popular Linux on commodity desktop equipment could be well and proper screwed.
It's definitely a sticky situation, and while I don't know that you can infer Microsoft's activities as anti-competitive because it should genuinely increase the security of their bootloading process, which is great for consumers using Microsoft operating systems.
That said, I am definitely terrified of the notion of not being able to purchase an affordable Linux-compatible laptop.
I'm even more so terrified at the idea that the vendor of my hardware may decide what operating system I should and should not boot on it.
Linux logo programs (for at least RedHat)
From mjg's posts I had the feeling that RedHat is afraid of what is going to happen if UEFI really takes of in the form it currently is intended to and that not a lot of manufacturers are keen of going through the trouble of using even more keys than absolutely required to sell. Do you have any sources to back that up?
I believe that it would be a bad step for one of the major Linux vendors to bow to the whole idea of signed booting for all the smaller distributions.
I would be very surprised if any of the major Linux vendors even attempted to get a 'universal' Linux key. From the perspective of the major Linux providers, getting logo certified is a competitive advantage against their peers, and it would take a significant amount of altruism to obtain those keys on behalf of others if it is even possible, which is anyone's guess.
As far as the OEM providers, no, I don't have any sources to back that up, but I don't know how you could logically argue against the idea that RH logo certification will increase sales to RH customers.
Possibly I'm overly optimistic in regard to the altruism of the Linux vendors. The old 'the whole ecosystem is going to suffer' argument is still pretty strong with the OSS community but you certainly could be right.
>The final irony? If the user has no control over the installed keys, the user has no way to indicate that they don't trust Microsoft products. They can prevent their system booting malware. They can prevent their system booting Red Hat, Ubuntu, FreeBSD, OS X or any other operating system. But they can't prevent their system from running Windows 8.
Err what? This boggles the mind. If you don't trust MS, DO NOT INSTALL WINDOWS. See, it's that easy.
>If Microsoft were serious about giving the end user control, they'd be mandating that systems ship without any keys installed. The user would then have the ability to make an informed and conscious decision to limit the flexibility of their system and install the keys. The user would be told what they'd be gaining and what they'd be giving up.
Huh what? You want my mom to make an informed and conscious decision about certificate chaining? I can see with going very well with 95% of PC users. This is typical behavior from geeks, putting the decision of about the choice of modules.conf vs. conf.modules which the user doesn't care about and just wants the software to work.
(Bemused aside: mjg is now just a "Red Hat guy"? Sigh...)
Apologies if your mind is boggled, but you're entirely missing the point. The point to a secure boot framework is to prevent the running of untrusted software under any circumstances. Simply choosing not to install something doesn't prevent malware from installing it without your approval.
The question is what "trusted" means. Right now, it means Microsoft only. If you don't trust MS, then you get no protection against MS-signed boot images, even if you choose not to install windows.
See the point? Maybe you trust Microsoft. Some people don't. But more to the point even trusted actors sometimes have their keys compromised (c.f. the current mess in the Netherlands).
Some mechanism for user control over key chains by the hardware owner (or your mother's trusted proxy, I guess) is a critical component to any truly "secure" product.
If Windows is the only thing that a computer will allow, then that really isn't an option. It's like saying that when owning an iPhone you have the option of not installing iOS.
You want my mom to make an informed and
conscious decision
Dude, "mom" arguments are really retarded, IMHO in the same category as "think of the children".
I agree with security-by-default arguments, but let the user have the choice of overriding those settings -- it doesn't have to be convenient for power-users, it just has to be doable.
Otherwise the hardware ain't yours anymore, you just payed for an overpriced license to use it as an appliance.
>This is typical behavior from geeks, putting the decision of about the choice of modules.conf vs. conf.modules which the user doesn't care about and just wants the software to work.
I want my software to work too, as a geek. This entire mess might prevent that. How is that justified? Hint: it isn't.
If they can't find a solution that's acceptable for both sides of the equation, then they should not be allowed to do this. To simply tell us geeks to "suck it up, consumers are more important" is an equally as fatal mistake as "fuck the consumers, the geeks demand something".
>If they can't find a solution that's acceptable for both sides of the equation, then they should not be allowed to do this.
Who is 'they' in the above line? MS or the OEM?
>To simply tell us geeks to "suck it up, consumers are more important" is an equally as fatal mistake as "fuck the consumers, the geeks demand something".
I see that this is working VERY well for Apple and Android OEMs.
"Microsoft will argue--in fact, has argued in a rebuttal on this matter on Sept. 22--that this is a security matter for Microsoft Windows deployments, and they are in no way influencing what the hardware vendors are doing with their keys"
That "no way" is the big legal question. I can see this go both ways. If most hardware manufacturers decide to only ship with MS keys, I think a judge could rule that Microsoft still has too much market power to let a free market optimize things for the good of the consumer. I do not see a judge decree that before there are any indications that it will become true, though.
(totally unrelated questions that I am curious about: how will this signing stuff work when running Windows in a VM? Would MS dare charge companies that want to include a MS key in their hardware? What if that company is called Apple?)
>I think a judge could rule that Microsoft still has too much market power to let a free market optimize things for the good of the consumer
How is the good of the consumer going to be served by allowing rootkits to load even before the antivirus can?
>(totally unrelated questions that I am curious about: how will this signing stuff work when running Windows in a VM? Would MS dare charge companies that want to include a MS key in their hardware? What if that company is called Apple?)
You have got it backwards. Windows 8 will boot on any machine or VM regardless of secure boot, UEFI, BIOS or what have you.
> How is the good of the consumer going to be served by
> allowing rootkits to load even before the antivirus can?
So that 'good of the consumer' is served by being presented with a choice of either Windows 8 or OSX? With the possibility that the barrier to competition is too high due to the difficulty of getting keys onto OEM UEFI systems?
1. One man's root kit is another man's Linux kernel.
2. Windows 8 may boot on untrusted hardware, but will it play rented movies, work with Office 365, run apps from Microsoft's store, etc? If Windows on untrusted hardware will not be a second-class citizen, why would Microsoft bother with secure boot?
>One man's root kit is another man's Linux kernel.
Not really. More like ninety nine men's root is one man's kernel based on marketshare of Linux.
> Windows 8 may boot on untrusted hardware, but will it play rented movies, work with Office 365, run apps from Microsoft's store, etc? If Windows on untrusted hardware will not be a second-class citizen, why would Microsoft bother with secure boot?
What has this got to do with anything? That will exclude Windows 7 PCs with no EFI and thus MS will lose customers who would otherwise rent movies, buy Office 365, buy apps from MS store.
Wouldn't this entire situation be solved by simply including an option in the UEFI firmware to disable secure boot by the user? That would allow a power user that wants to install an alternate OS to disable the feature and install anything they'd like.
I understand that this may affect dual-booting. In those cases, we already know that Windows 8 will boot in non-secure scenarios (like on existing computers, including those with UEFI firmware). So wouldn't it be possible to simply turn off the feature and still be able to dual-boot Windows 8 and another OS?
The Red Hat blogger mentions an unnamed OEM that he claims won't have this option. However, instead of naming that OEM so that we can shame and/or avoid them, he instead wants to shift the blame on to Microsoft. (And then in the same breath, will call Windows insecure coz of the rootkits that load before the anti-malware can).
The relevant quote is: "Garrett said that Windows 8 certification requires that hardware ship with UEFI secure boot enabled. A feature allowing secure boot to be disabled – necessary to run Linux and FreeBSD on certified systems – is not required for certification."
And further: '"We've already been informed by hardware vendors that some hardware will not have this option," Garrett writes in a flow-up blog post to his original critique of the technology.'
Huh, what? The ability of disable secure boot IS in the spec, and it is included in the Samsung tablets that Microsoft got Samsung to make for their developers. How was it implemented if it's not in the spec.
The ability to disable it is in the spec, but it's not required by the spec. Equally, the ability to override security decisions on a case by case basis is in the spec, but the Microsoft certification requirements forbid it.
Sorry, but I tend to agree. Microsoft could produce a secure (and optional) signed bootloader that could chain load Grub, but they won't. They could require an option for consumer-targeted devices to have the Microsoft sticker, but they won't. There is almost no downside to requiring this, except for the fact that it can only serve to hurt their business. I'm not sure I blame them from a business perspective, but it feels awful par-for-the-course-Microsofty.
(I don't mean to be rude or presumptuous, but your other comment seems to indicate that you're not fully understanding the technical workings or implications of a non-disable-able UEFI secure boot).
>There is almost no downside to requiring this, except for the fact that it can only serve to hurt their business. I'm not sure I blame them from a business perspective, but it feels awful par-for-the-course-Microsofty.
I think your energy will be better served railing against the alleged OEMs that won't include the option, instead of against MS. They're trying to clean up rootkits that load before antivirus to make their OS more secure.
>(I don't mean to be rude or presumptuous, but your other comment seems to indicate that you're not fully understanding the technical workings or implications of a non-disable-able UEFI secure boot).
>They're trying to clean up rootkits that load before antivirus to make their OS more secure.
And that in no way precludes the options that I outlined. To act as if the OEMs act independently or without significant guidance from MS is just misguided.
>Care to tell how?
You seemed to have missed the entire bit about it... preventing non-Windows OSes from being installed. You keep citing the developer tablets that have very obvious needs for having an unlockable UEFI implementation. It's just like Chromebooks (the CR-48 is unlockable, retail units not so much), or Android (fastboot on Nexus, locked on Moto/HTC). I just don't understand how you cite a developer tablet as proof, when it's obvious that Microsoft won't take the step to ensure that the choice is available for consumers. I mean, you even phrase it as "Microsoft got them to..." in reference to the developer tablets.
You are presuming physical access to the box in order to make the change in the firmware. If they have physical access, secure boot is meaningless. Secure Boot is to make it impossible for software to manipulate the boot process and install malware.
The point of UEFI is to prevent an attacker from getting at your bootloader by preventing you from getting at the bootloader. If I wanted to create my own bootloader, I would not be able to. This is the same argument for the iOS App Store model to prevent malware. Make sure that only a select few gatekeepers have the keys to the kingdom.
Nothing. Some do this. It's up to the OEM. That's Microsoft's point. MS isn't requiring that OEMs can't do this. If OEMs want to, they're completely within their right to do so. It's up to them.
Take it up with the individual OEMs who don't build machines the way you like them. Or better yet, buy those that build the ones you do like. This seems downright silly to sue about.
I'm not suing over it.. I'm just upset over the entire situation.
"buy those that build the ones you do like."
There are two very large problems with this:
1) Now I have to do yet another piece of needless research whenever I buy a piece of hardware. That is a pain in the ass, pure and simple.
2) Everyone else I know won't be doing that research. So when my dad says to me again, "Hey, your mother is getting viruses again, stick her back on Ubuntu", I have yet another thing to worry about.
Yeah yeah, I get it. They have a right to do it, the market will sort it out, blah blah blah. Fact is, I also have a right to bitch about it, regardless of their rights.
The Linux community should incentive it. RedHat should say to HP, Dell, and Acer -- "for each UEFI Win8 logo machine you ship, where you enable the ability to disable secure booting we give you five dollars". Or letting them keep a larger percentage of RH license revenue, or whatever.
While I do understand the security argument, surely the manufacturers of hardware wouldn't do this only to be allowed to use the Windows 8 logo? I have never heard of a person who cares if there's a Windows-logo on their laptop or not. In fact, the people I asked earlier today (both nerds and "normals") consider it an ugly annoyance.
Being part of the Windows logo program means getting access to some Microsoft marketing budget. The incentive is the financial benefit, not the sticker itself.
I see, thanks for explaining. I suppose, as a large computer manufacturer, actively/proudly refusing the Windows logo wouldn't please Microsoft either.
The article is a little breathy, but it's a serious problem. If we don't get some kind of industry consensus on this, we're looking at a future where those of us who want to use a Linux desktop[1] are going to have to do it on jailbroken hardware. While the enthusiast motherboard community might be OK with some extra firmware settings and UIs, laptop vendors are simply never going to install and test extra junk that someone doesn't force them to. This is very scary.
[1] You can tell us apart by the fact that we're taking this issue seriously. People who code on Macs and deploy to Linux servers (probably 70% of the user base on news.yc) obviously won't see a personal impact.
I agree that it should be fought. Running around panicking about how evil MS is will just waste time.
Talking to hardware vendors to ask them what is needed to get Linux to run on their systems is the most productive course of action at the moment, I believe.
No offense, but Linux people have been trying to engage hardware vendors for decades now. If the hardware happens to be a rack server or Android phone, they tend to have decent success. If it's a laptop, the answer (if one comes back) is generally "You want to run what now?"
No one cares. Margins are too thin to "engage the community" or any other such nonsense. Does it run Windows? Ship it.
No offense, but Linux people have been screaming at Microsoft for decades now. It hasn't made a single difference. However, at this point, nearly all hardware out there has some degree of Linux support, often with the help of the vendor directly.
There are two choices that might accomplish anything: Work with the vendors and try to work out a solution, or lawyer up.
What is interesting to me in terms of how this story is pitched is that Microsoft's approach to operating systems is shifting to be similar to Apple's, because one cannot run OSX on commodity hardware either.
Not really. This move is making commodity hardware only run Windows. So you'll end up with Windows on commodity hardware and OSX on Apple hardware. Sounds like a great free-market solution.
OSX isn't prevented from running on commodity hardware though a secure boot process though. Non-secure UEFI motherboards can boot and install retail OSX mediums (in fact, most hackintoshes are made possible through UEFI emulation boot discs). The biggest hurdle is driver support for peripheral devices: graphics, network, sound, wifi.
RMS made this prediction in 2003. Most people called him crazy and fringe at the time, but he was 100% right. Here's a quote:
"Some versions of treacherous computing would require the operating system to be specifically authorized by a particular company. Free operating systems could not be installed."
Apple proved him right long before this. But there was no outrage against Apple, since they make shiny things that everyone likes. And people actually liked the security that this gave them. The battle was lost then.
If those are the examples, can't we go further back and blame other cell phone manufacturers? Or get mad that Nintendo didn't make it easy for us to put our own OS on the NES?
Just to add to what you said: RMS and the FSF worked up the GPLv3 in response to this "Tivoization" of Software.
Linus and the kernel crowd at that time were on the other side of the debate.
Linus' quote:
"" [Stallman] calls it "tivoization", but that's a word he has made up, and a term I find offensive, so I don't choose to use it. It's offensive because Tivo never did anything wrong, and the FSF even acknowledged that. The fact that they do their hardware and have some DRM issues with the content producers and thus want to protect the integrity of that hardware.
The kernel license covers the kernel. It does not cover boot loaders and hardware, and as far as I'm concerned, people who make their own hardware can design them any which way they want. Whether that means "booting only a specific kernel" or "sharks with lasers", I don't care. ""
Back then Tivoization was about "consumer devices." Now that "Tivoization"
is threatening to breach the walls of hacking devices, it feels a lot more
personal.
57 comments
[ 2.1 ms ] story [ 139 ms ] threadI don't think there's much of a case here. The UEFI hardening is clearly a good thing for consumers, and having it as a logo requirement just makes sense. And if MS is not using any influence to block other OSes, that seems like the best you can ask for. And recall, OEMs can always ship without Win8 logo and not use hardening (or even UEFI at all).
Sorry? I'm confused on this one.
* From the MS slides ( http://video.ch9.ms/build/2011/slides/HW-457T_van_der_Hoeven... ): "UEFI and secure boot harden the boot process [...] Required for Windows 8 client"
* From the Garrett post ( http://mjg59.livejournal.com/138973.html ): "Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled"
* From the IT World post linked up here: "And not just any old UEFI layer, either, but secure UEFI. Meaning a hardened boot process"
What am I mis-reading or missing? I'm not being testy, I just think you must have spotted something I missed. Thanks
That said, while Ubuntu, RedHat, Suse and other larger Linuxes might be able to swing this for server equipment, someone trying to run a less popular Linux on commodity desktop equipment could be well and proper screwed.
It's definitely a sticky situation, and while I don't know that you can infer Microsoft's activities as anti-competitive because it should genuinely increase the security of their bootloading process, which is great for consumers using Microsoft operating systems.
That said, I am definitely terrified of the notion of not being able to purchase an affordable Linux-compatible laptop.
I believe that it would be a bad step for one of the major Linux vendors to bow to the whole idea of signed booting for all the smaller distributions.
As far as the OEM providers, no, I don't have any sources to back that up, but I don't know how you could logically argue against the idea that RH logo certification will increase sales to RH customers.
>The final irony? If the user has no control over the installed keys, the user has no way to indicate that they don't trust Microsoft products. They can prevent their system booting malware. They can prevent their system booting Red Hat, Ubuntu, FreeBSD, OS X or any other operating system. But they can't prevent their system from running Windows 8.
Err what? This boggles the mind. If you don't trust MS, DO NOT INSTALL WINDOWS. See, it's that easy.
>If Microsoft were serious about giving the end user control, they'd be mandating that systems ship without any keys installed. The user would then have the ability to make an informed and conscious decision to limit the flexibility of their system and install the keys. The user would be told what they'd be gaining and what they'd be giving up.
Huh what? You want my mom to make an informed and conscious decision about certificate chaining? I can see with going very well with 95% of PC users. This is typical behavior from geeks, putting the decision of about the choice of modules.conf vs. conf.modules which the user doesn't care about and just wants the software to work.
Apologies if your mind is boggled, but you're entirely missing the point. The point to a secure boot framework is to prevent the running of untrusted software under any circumstances. Simply choosing not to install something doesn't prevent malware from installing it without your approval.
The question is what "trusted" means. Right now, it means Microsoft only. If you don't trust MS, then you get no protection against MS-signed boot images, even if you choose not to install windows.
See the point? Maybe you trust Microsoft. Some people don't. But more to the point even trusted actors sometimes have their keys compromised (c.f. the current mess in the Netherlands).
Some mechanism for user control over key chains by the hardware owner (or your mother's trusted proxy, I guess) is a critical component to any truly "secure" product.
I agree with security-by-default arguments, but let the user have the choice of overriding those settings -- it doesn't have to be convenient for power-users, it just has to be doable.
Otherwise the hardware ain't yours anymore, you just payed for an overpriced license to use it as an appliance.
How is MS restricting that? They even let the user do it on their own tablets that they got Samsung to make for them!
I want my software to work too, as a geek. This entire mess might prevent that. How is that justified? Hint: it isn't.
If they can't find a solution that's acceptable for both sides of the equation, then they should not be allowed to do this. To simply tell us geeks to "suck it up, consumers are more important" is an equally as fatal mistake as "fuck the consumers, the geeks demand something".
Who is 'they' in the above line? MS or the OEM?
>To simply tell us geeks to "suck it up, consumers are more important" is an equally as fatal mistake as "fuck the consumers, the geeks demand something".
I see that this is working VERY well for Apple and Android OEMs.
The solution is simple, bu
That "no way" is the big legal question. I can see this go both ways. If most hardware manufacturers decide to only ship with MS keys, I think a judge could rule that Microsoft still has too much market power to let a free market optimize things for the good of the consumer. I do not see a judge decree that before there are any indications that it will become true, though.
(totally unrelated questions that I am curious about: how will this signing stuff work when running Windows in a VM? Would MS dare charge companies that want to include a MS key in their hardware? What if that company is called Apple?)
How is the good of the consumer going to be served by allowing rootkits to load even before the antivirus can?
>(totally unrelated questions that I am curious about: how will this signing stuff work when running Windows in a VM? Would MS dare charge companies that want to include a MS key in their hardware? What if that company is called Apple?)
You have got it backwards. Windows 8 will boot on any machine or VM regardless of secure boot, UEFI, BIOS or what have you.
2. Windows 8 may boot on untrusted hardware, but will it play rented movies, work with Office 365, run apps from Microsoft's store, etc? If Windows on untrusted hardware will not be a second-class citizen, why would Microsoft bother with secure boot?
Not really. More like ninety nine men's root is one man's kernel based on marketshare of Linux.
> Windows 8 may boot on untrusted hardware, but will it play rented movies, work with Office 365, run apps from Microsoft's store, etc? If Windows on untrusted hardware will not be a second-class citizen, why would Microsoft bother with secure boot?
What has this got to do with anything? That will exclude Windows 7 PCs with no EFI and thus MS will lose customers who would otherwise rent movies, buy Office 365, buy apps from MS store.
I understand that this may affect dual-booting. In those cases, we already know that Windows 8 will boot in non-secure scenarios (like on existing computers, including those with UEFI firmware). So wouldn't it be possible to simply turn off the feature and still be able to dual-boot Windows 8 and another OS?
The Red Hat blogger mentions an unnamed OEM that he claims won't have this option. However, instead of naming that OEM so that we can shame and/or avoid them, he instead wants to shift the blame on to Microsoft. (And then in the same breath, will call Windows insecure coz of the rootkits that load before the anti-malware can).
Edit: reply to comments on spec and disabling boot loading.
FYI, I haven't read the spec, and I based my statement from the other article on the home page: http://www.theregister.co.uk/2011/09/26/uefi_linux_lock_out_...
The relevant quote is: "Garrett said that Windows 8 certification requires that hardware ship with UEFI secure boot enabled. A feature allowing secure boot to be disabled – necessary to run Linux and FreeBSD on certified systems – is not required for certification."
And further: '"We've already been informed by hardware vendors that some hardware will not have this option," Garrett writes in a flow-up blog post to his original critique of the technology.'
(I don't mean to be rude or presumptuous, but your other comment seems to indicate that you're not fully understanding the technical workings or implications of a non-disable-able UEFI secure boot).
I think your energy will be better served railing against the alleged OEMs that won't include the option, instead of against MS. They're trying to clean up rootkits that load before antivirus to make their OS more secure.
>(I don't mean to be rude or presumptuous, but your other comment seems to indicate that you're not fully understanding the technical workings or implications of a non-disable-able UEFI secure boot).
Care to tell how?
And that in no way precludes the options that I outlined. To act as if the OEMs act independently or without significant guidance from MS is just misguided.
>Care to tell how?
You seemed to have missed the entire bit about it... preventing non-Windows OSes from being installed. You keep citing the developer tablets that have very obvious needs for having an unlockable UEFI implementation. It's just like Chromebooks (the CR-48 is unlockable, retail units not so much), or Android (fastboot on Nexus, locked on Moto/HTC). I just don't understand how you cite a developer tablet as proof, when it's obvious that Microsoft won't take the step to ensure that the choice is available for consumers. I mean, you even phrase it as "Microsoft got them to..." in reference to the developer tablets.
Well that is the problem isn't it?
"buy those that build the ones you do like."
There are two very large problems with this:
1) Now I have to do yet another piece of needless research whenever I buy a piece of hardware. That is a pain in the ass, pure and simple. 2) Everyone else I know won't be doing that research. So when my dad says to me again, "Hey, your mother is getting viruses again, stick her back on Ubuntu", I have yet another thing to worry about.
Yeah yeah, I get it. They have a right to do it, the market will sort it out, blah blah blah. Fact is, I also have a right to bitch about it, regardless of their rights.
http://mjg59.livejournal.com/138973.html
http://mjg59.livejournal.com/139232.html
http://mjg59.livejournal.com/139356.html
This article is overly hyping the situation.
[1] You can tell us apart by the fact that we're taking this issue seriously. People who code on Macs and deploy to Linux servers (probably 70% of the user base on news.yc) obviously won't see a personal impact.
Talking to hardware vendors to ask them what is needed to get Linux to run on their systems is the most productive course of action at the moment, I believe.
No one cares. Margins are too thin to "engage the community" or any other such nonsense. Does it run Windows? Ship it.
There are two choices that might accomplish anything: Work with the vendors and try to work out a solution, or lawyer up.
Windows 8 will run on any BIOS and UEFI, regardless of secure boot, there is nothing in secure boot preventing you from running it anywhere.
"Some versions of treacherous computing would require the operating system to be specifically authorized by a particular company. Free operating systems could not be installed."
Source URL: http://www.gnu.org/philosophy/can-you-trust.html
Linus and the kernel crowd at that time were on the other side of the debate.
Linus' quote: "" [Stallman] calls it "tivoization", but that's a word he has made up, and a term I find offensive, so I don't choose to use it. It's offensive because Tivo never did anything wrong, and the FSF even acknowledged that. The fact that they do their hardware and have some DRM issues with the content producers and thus want to protect the integrity of that hardware.
The kernel license covers the kernel. It does not cover boot loaders and hardware, and as far as I'm concerned, people who make their own hardware can design them any which way they want. Whether that means "booting only a specific kernel" or "sharks with lasers", I don't care. ""
Back then Tivoization was about "consumer devices." Now that "Tivoization" is threatening to breach the walls of hacking devices, it feels a lot more personal.