It’s sad that we need this, but alas – Matthew Garret has made a list of Linux distributions that boot on Windows 8 PCs with Secure Boot enabled. Tellingly enough, the list is short. Very short. Can someone hack this nonsense into oblivion please?
It’s sad that we need this, but alas – Matthew Garret has made a list of Linux distributions that boot on Windows 8 PCs with Secure Boot enabled. Tellingly enough, the list is short. Very short. Can someone hack this nonsense into oblivion please?
Or Linux distros can stop the “I am not including the workaround because I have moral objections” and get on with life.
Does secure boot suck? Of course. Does Microsoft and the 99% of the population who use whatever operating system ships with the machine, care? Of course not. Should distros adapt to the current situation? Well, rational thinking sez yes.
We ‘ve been through this before with libdvdcss. A working workaround exists and yet distros are not using it as to make a “statement”. Did it made any difference? Not, it just made the lifes of newbie Ubuntu users harder, because they had to find codecs and libdvdcss. At least ubuntu has wisen-ed up
Edited 2012-12-29 17:01 UTC
You do realize that libdvdcss is illegal in many parts of the world? That is one of the reasons for not including it, no sane Linux-distro maintainer wants to be found guilty of illegalities. There are workarounds, but alas, there’s always this or that hoop to jump through.
When you say ‘many’ you really mean ‘a few’, right?.
It’s funny how the region code of the DVDs only help the piracy. I live in region 4… most of the DVD where never release for this region, and if you try to get a version from other region most of the sellers won’t sell it (for legal reasons). So the only way to get a lot of movies/series is getting a copy because there is NO original version.
Region codes are not relevant here. Libdvdcss is the library that handles breaking the DRM on DVDs, which is illegal in the US and some other countries.
Distributing libdvdcss or libdecss as it’s also called would mean the Linux Distributions would be illegal to distribute in the US, which is a huge marked to loose.
Yeah, just roll over and get on with it. Don’t complain. Microsoft surely know what they’re doing and it’s all for our own good. Why make a fuss?
Distributions do not omit libdvdcss (and codecs) to make a “statement”, they omit it because it is illegal in several countries including the USA and the maintainers don’t like the idea of possibly being arrested and charged should they go on a nice holiday to the USA one day in the future.
This is another “statement” that is particularly annoying. Not including something because it’s illegal under the US and UK laws. See, most Linux distro maintainers are from the US or the UK, and seem to think the world must get shafted the same way they are, as to raise “awareness” for the problems their country has. Seriously, if some country like China bans cryptography (has happened before in more ‘democratic’ countries), what are the distro maintainers going to do? Remove all cryptography code from Linux, just so they don’t get arrested if they ever visit China? Why is the US is more important than, say, China?
No fine folks, the omission of libdvdcss is either the result of a US-centric view of the world, or an effort by the maintainers to raise “awareness”. In both cases, a “statement”. There is no reason why there shouldn’t be an “international” version of Ubuntu with full codecs and libdvdcss. Same for secure boot in most distros. It’s all about “awareness”. No legal hurdles this time. It’s a “statement” again from stuborn maintainers.
BTW, the US authorities haven’t issued an arrest warrant for the Mint guys yet…
And libdvdcss might not be exactly illegal in the US… http://www.courthousenews.com/2010/07/23/29099.htm
US, UK, maybe Germany, end-of-list. The Mint guys have no problem shipping it.
I complained, read my first post again about how secure boot sucks. The DRM in DVDs sucks even more. But what are you going to do? You can’t “isolate” yourself from the problem by not supporting PCs with secure boot anymore, or by not having DVD playback. This is silly 70s thinking that has been passed by the FSF to many distro developers: See a problem? Isolate yourself from the problem by boycotting stuff. Don’t try to workaround the problem. Unfortunately, most people don’t think that way, so you are basically isolating yourself (and your distro) from the real world.
Edited 2012-12-29 20:38 UTC
IIRC, Mint is a French distro, and things like libdvdcss and mp3 codecs are not yet illegal here. But I’m not sure about either.
Mint is based out of Irland.
Wait, what? You’re saying they should just ignore the laws of the countries they live in and possible face severe consequences just to please you?
Maybe. Or maybe they’d stop maintaining the distro. Or maybe something else. Whatever they chose as their course of action, however, is none of your business. If they face legal consequences then you have absolutely no right whatsoever to complain if they choose to protect themselves.
Because, obviously, Ubuntu, Mint, Fedora et.al. are all aimed at the western civilizations. There are separate distros for the Chinese and for them China is more important.
No. One is about legality, the other is about ideology. You’re comparing apples and oranges.
Are they based in the US? If not then that’s a wholly irrelevant comment.
Indeed. Neither have VLC, for example. You know why? Because they originate from France.
Heh, when Linux will stop being idealistic, it might get actually good.
Scarry, I know.
What about the list of distros that boot on Windows 8 PCs with secure boot disabled, because, you know, Microsoft acquiesced to pressure and makes the ability to disable secure boot a requirement for the Windows 8 logos…
Oh, this list is just as long as every other PC?
Then what is the problem? There are multiple valid ways to use secure boot with Linux, one of which is getting your kernel signed for $99 (Verasign will do this, if you go through Microsoft). Or, you can install your own keys and sign kernels yourself on many systems.
Or, do what Red Hat does, and have a signed loader load a kernel with it’s own keys.
Or, disable Secure Boot, and it operates as it always has, because, you know, any computer with a Windows 8 logo will have this capability. Let me say this again, because apparently, a lot of people have problems understanding this:
The ability to disable secure boot is a requirement for the Windows 8 logo program. You may not ship a system with the Windows 8 logo unless the user can disable secure boot.
I really don’t see the problem.
Edited 2012-12-29 19:01 UTC
Well, the thing is, they do not mandate how one must be able to disable secure boot — OEMs are free to use whatever means they want. This could include a physical switch on the motherboard or having to call up the OEM for an unlocking – key or whatever they feel like.
It all makes it quite a bit more difficult for novice users to try Linux, and it makes development of custom OSes even harder.
Any of those solutions requires added complexity that an OEM will likely not add. A physical switch? That’s an extraordinarily expensive solution (It would be useful in specific situations, and if an OEM does implement this, would likely be as a value-add option). A phone call to retrieve an unlock code? Again, that’s extra complexity in the support side. OEMs have no reason make this more difficult; They don’t benefit when users DON’T install Linux.
No, the simplest way to implement this is just an on/off in the firmware setup, right next to all the other options that are usually available. There are few reasons NOT to implement it this way.
This is true for x86, but on ARM systems the opposite is true: a Windows 8 logo means that secure boot can’t be disabled and no new certificates can be added.
From what I can tell, the article was about x86 distributions, and in this case you have a good point, but I thought it worth highlighting that there are exceptions (unless something changed and I missed it).
http://mjg59.dreamwidth.org/21189.html
This is a real problem. ARM devices are often sold with locked bootloaders, and the ones that ship unlocked don’t have open-spec hardware which makes writing drivers difficult.
Where are you getting this load of claptrap from?
From Wikipedia:
http://en.wikipedia.org/wiki/Windows_8#Secure_boot
It was in a few news articles when the whole kerfuffle came out, and this has been known for a while. Wikipedia links to those articles.
Has any one here actually disabled secure boot on a Windows 8 system? If so, they have can they describe their experiences and tell us what hoops they had to jump through.
The only solution is to refuse to buy a machine on which you can not disable secure boot. If enough people do this there will always be a decent pool of machines to pick from to run Linux etc.
Of course Microsoft’s real aim is to destroy the aftermarket for used machines — thereby forcing folks to buy new computers instead of re-using those that have Win 8 installed. Thus I hope this list grows considerably.
Every Windows 8-logo non-ARM device has to be able to disable secure boot feature, but enabled by default.
However every Windows 8-logo ARM-device has this enabled by default and does not have an off switch.
So basically you are saying: do not buy a Windows RT device.
We’ll have to see how long that policy remains the way it is.
Edited 2012-12-30 11:39 UTC
Seems life is more complicated than that:
http://mjg59.dreamwidth.org/21189.html
🙁
The list isn’t really relevant since, on my machine at least, Secure Boot must be disabled before the user can install a new operating system (ie boot from any media except the hard drive). To boot one of these distros that support Secure Boot I’d have to first disable Secure Boot, then install the distro and then re-enable Secure Boot. Having a distro support Secure Boot doesn’t help at all since I can’t boot from the distribution’s installation media while Secure Boot is enabled.
Why do you think that ? I think you misunderstand.
These Linux distributions have a small piece signed by the Microsoft key specifically so that users do not have to do any technical things to install the Linux disitribution.
A device with secure boot means:
– A system to prevent bootvirusses (mostly Windows)
– usually a pre-installed Microsoft key so it can boot/install Windows
– for manufacturers to get their device part of the Windows-logo program (which gets them a PR budget from Microsoft, that is why they do this!) they need to do 1 of 2 things:
1. on x86/amd64 enable secure boot with the Microsoft key, but make it possible to disable it or load your own keys from the BIOS/firmware
2. on ARM enable secure boot and have no way to install keys or to turn it off
Secure boot isn’t very secure, it just exists to try and prevent modification of the boot process from a program running on the operating system.
I apologise in advance if this is stupid a lot of people here know more about this than me but …
My guess is that MS’s secure boot key will become available to the maleware cracker community either by leakage or cracking. This will then make it possible to create a rootkit, bootsector virus etc which will run on a secure / restricted boot system.
If this maleware then randomly changes some part of the Windows kernel and an AV removes the the virus this will leave a secure / restricted boot system unbootable. If we combine this with the fact, that many computers now do not come with installation disks but recovery partitions, which return the PC back to factory specs. You get a virus, if you remove it you loose your data. This doesn’t seem to be what MS intended, if they intended to make the system more secure, rather than just be anti competitive.
This system seems to have the potential to make the security of data on an MS system worse not better (most people do not have backups) and open new venues for extortion, and problem creating by the cracker community.
Uhh….Viagra, Fleshlight, blow-up dolls and the likes come to mind, not computer software.
Oops, brain fart, Freudian slip working Sunday.
Edited 2012-12-30 01:10 UTC
As far as I know, the keys used for singing Microsoft’s own DLLs and validated drivers haven’t been leaked yet. I doubt this is something that will change with secure boot.
Possible, though highly unlikely. If MS actually operate their signing infrastructure in any sensible way (e.g. the way a public CA is operated), then the root key is only held on an HSM (Hardware Security Module) – a separate tamper-proof purpose-built machine which will never, ever give the secret key out and only execute signing for you. The recent compromises of CAs (Comodo, Diginotar) you heard about were all done by having the attackers trick the CA into signing certificates for other domains. At no point did the attackers actually get to the secret key of the root CA.
As far as I understand it, UEFI is built on asymmetrical cryptography. Unless it was designed by idiots, the shipped machines only contain the public key portion, so it’s impossible to retrieve the secret key.
Seeing the exploit landscape of late, and please feel free to correct me, boot viruses and worms are pretty much a thing of the past. Nowadays everybody focuses on phishing and browser exploits, since that’s where the real money can be made (credit card fraud, on-line banking connection hijacking, etc.). UEFI is a solution in search of a problem (that is, if you believe the official story, that it’s about protecting the customer’s machine from viruses, rather than protecting the machine from the customer).
Edited 2012-12-30 01:49 UTC
I see that the distros with a clue about OEM support and enterprise adoption are moving ahead with support for UEFI Secure Boot.
The geek has been dependent on cheap commodity hardware built for the Windows eco-system for something like 20 years now.
Projects like the AEM based Raspberry PI have something new to offer the technical hobbyist.
But the hoo-rah over Secure Boot suggests that the Linux user is becoming more mainstream than the geek is willing to admit.
That he won’t install Linux if the price is evading or disabling hardware-level security.
Just like Red Hat did, any distro can get a cert from VeriSign for 99USD. They can sign binaries with that cert until the cows come home and they will work with SecurerBoot PC’s.
This is not some Microsoft conspiracy as the tin-foil hat brigade would have you believe. This is a great move to allow a trusted chain of execution on consumer PC’s, used correctly it will drastically reduce the risk we face from malware.
Stop whinging, if somehow your distro cant afford $99, make a donation.
Secure Boot is one of the best things to happen to desktop security in years, we should thank Microsoft for forcing the hand of vendors who otherwise would continue to have it optional and turned off by default.
Oh, really? How will Secure Boot affect any of the most wide-spread malware packages at all? I mean, those do not modify the kernel or MBR in any way, so Secure Boot doesn’t stop them or limit them in the least. And if Secure Boot doesn’t affect the things that pose the greatest threat to end-users then what good is it for?
Just because it doesn’t stop all malware doesn’t mean it isn’t a good thing. Despite what a lot of people seem to think, rootkits still exist in the wild. I mean, look at Stuxnet for a high-profile one in recent news.
They exist for Windows 7 64-bit even. I just recently came across one while cleaning somebody else’s computer. SecureBoot would prevent these.
Wow, really? Will it prevent malware running as my user from harvesting my data? Will it prevent malware running as my user from participate in a botnet? Will it prevent social engineering?
No? Fat lot of good it does, then.
But it says “secure” on the box! So it’s secure! You don’t want to disable it, or you’ll catch a virus! 🙂
No, honestly: “Secure Boot” emphasizes security during the boot process only. If it would protect against common malware, virus infections, social engineering and human stupidity, it would require a different name, and as repeated in the article several times, “signed by Microsoft”. 🙂
Of course it adds some protection that may even be useful in MICROS~1 land, but remember that not everyone is using “Windows” or wants to use it, or even wants to deal with it (even if it’s just for the purpose of getting rid of the restrictions it implies). The best way would of course be to have an option to revert the UEFI “back to normal” as “Secure Boot” isn’t needed to perform an OS boot in the first place. Deals between MICROS~1 (with their idea of how “security” should work) and OEMs will probably prevent such a simple solution…
So there is something I would like to know.
As “Secure boot” uses x509 certificates (SSL cerficates like for HTTPS) what is the validity period of these keys ?
Is it 5 years, 10 years ? 15 years ?
Because sounds to me like when you start up your Windows 8 ARM device (no disabled button for Secure Boot) in 15 years it might not boot anymore ?
Turns out, it is 15 to 20 years:
http://blog.fpmurphy.com/2012/11/list-secure-boot-certificates.html
Will the BIOS/firmware check this ?
So will your PC stop booting in the future ?
Edited 2012-12-30 12:04 UTC
Wow, this is a major fuckup and cause for serious concern. 15 year old working machines aren’t all that rare – having this kind of time-bomb in them might very well prove to be a serious issue for businesses relying on UEFI secured systems.
This is gonna be an other annoyance for the computer museum I’m sure.
(not to mention that the cloud services probably are all offline by then too ?)
It’s unlikely the UEFI BIOS will enforce the expiration date simply because it does not have any way of validating the date in the settings unless it has Internet-connectivity and can make an encrypted connection to a manufacturer-mandated clock source. If the BIOS just assumed that whatever the date is in the settings is correct then it would be terribly simple for malware to render the device unbootable: just set the date to something past 2040 and reboot. Similarly, block access to the manufacturer-mandated clock source and adjust the date manually every now and then to bypass the expiration date — the expiration method would be totally, completely ineffective.
I can’t check what it does, I have no intention of buying such a device.
But the OS by default at least, would use the Internet to update the time every time it boots and even update the key database every so often.
If the manufacturer of an ARM device wants to be really sure that the time is correct it would use the onboard GPS device to update the time every so often.
So everytime the time gets updated it stops booting again.
Vote with your money… don’t buy Windows 8-based ARM PCs.
If they want to lock you out of the hardware you just bought, then lock them out of your possibilities for possible computer purchases.
The more Linux distributions that support this catastrophe, the more this shit will catch on, and then we’ll *all* be fucked.
Hi,
Please don’t call them “Windows 8-based ARM PCs” – they aren’t.
Part of what makes a PC a personal computer is that the hardware is a completely different product to the software. The people designing the hardware don’t care what software any specific consumer might decide to use, and consumers are able to install whatever software (including OS) that they feel like on it.
Almost all ARM systems are sold as a single (“hardware plus software”) product , and they are not 2 separate products. For example, you might have a smart TV with software and an ARM CPU intended for one specific purpose, or have a telephone with an ARM CPU and software intended for one specific purpose, or have a tablet with an ARM CPU and software intended for one specific purpose. None of these things are intended to be generic and none of these things are “PCs”.
What I can’t understand is why secure boot is used for ARM systems at all. It’s much easier to skip UEFI completely and have a locked down system by burning (at least part of) the OS into flash/ROM; which is what almost all ARM systems have done in the past.
– Brendan
I get the point, I know the difference, and I purposely used the term to jab at Microsoft due to the fact that they are trying to move away the term “PC” for all the computers their OS runs on. You know, “device” seems to be the new overused buzzword. In that case, I’d argue that “device” is misleading most of the time it’s used. After all, since when did computers and devices (you knew, those internal computer peripherals you install device drivers for) get mixed up? Someone’s bastardizing the definition of “device” over at Microsoft and several other corporations, and I don’t see anyone complaining.
Also a PC is simply a “personal computer,” so by that definition ANY computer that is intended to be used as, well, a personal computer can theoretically be labeled as such. Who cares if traditionally those were originally marketed as the IBM PC and clones with an x86 processor and a Microsoft operating system… I really don’t, unless it is important within context to make a distinction to. In which case… simply specifying the architecture as I did should be enough.
Also–ARM computers with Win8 could easily be just as open as x86 computers. The only reason they’re not is because Microsoft says so. Last I checked, Microsoft was not a major producer of ARM hardware. And don’t try to claim that their Surface RT (one product) automatically makes them a a major producer. They don’t even “own” ARM.
The claimed reason? Security. The real reason and effects? Destroying the competition and controlling what their users can do with their own hardware.
Too late.
Secure Boot dates from UEFI spec 2.2. [2008.]
It didn’t come out of the blue and it is not Microsoft only – and it is not going away.
http://en.wikipedia.org/wiki/Unified_EFI_Forum
I think you might be mixing UEFI, a modern BIOS replacement, with SecureBoot–Microsoft’s purposely crippling UEFI-based technology that just happens to use UEFI as its vehicle and method of execution.
SecureBoot is not a required part of UEFI; it’s just another feature that, theoretically, is supposed to be possible to be switched on and off at will (see: probably every single UEFI x86-based machine). It is a required part for OEMs to implement in order to pass the Windows Logo test and obtain official certification from Microsoft. Microsoft is the one requiring that it be enabled on all ARM systems with no way to disable, and therefore it is more of a Microsoft/Windows restriction than anything.
In the way it’s being used, I would say that it does in fact have absolutely nothing to do with anything other than Windows, Microsoft’s bottom line, and their desire to thwart competition without any real merits.
It’s almost 2013 now, and apparently EULAs are no longer enough for these companies; they will stop at nothing to strictly enforce their plans it seems. First an agreement… now technical restrictions built into the hardware.
Edited 2012-12-31 00:04 UTC