Secure Boot Linux distribution support

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?

About The Author

45 Comments

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

We ‘ve been through this before with libdvdcss. A working workaround exists and yet distros are not using it as to make a “statement”.

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.

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.

Or Linux distros can stop the “I am not including the workaround because I have moral objections” and get on with life.

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?

We ‘ve been through this before with libdvdcss. A working workaround exists and yet distros are not using it as to make a “statement”.

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.

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…

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?

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.

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

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?

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?

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.

Why is the US is more important than, say, China?

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.

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. One is about legality, the other is about ideology. You’re comparing apples and oranges.

BTW, the US authorities haven’t issued an arrest warrant for the Mint guys yet…

Are they based in the US? If not then that’s a wholly irrelevant comment.

The Mint guys have no problem shipping it.

Indeed. Neither have VLC, for example. You know why? Because they originate from France.

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.

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…

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.

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.

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

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…

Microsoft’s certification requirements eventually revealed that UEFI firmware on x86 systems must allow users to re-configure or turn off secure boot, but that this must not be possible on ARM-based systems (Windows RT). Microsoft faced further criticism for its decision to restrict Windows RT devices by using this functionality, despite it being consistent with other consumer electronics with similar protection measures. No mandate is made regarding the installation of third-party certificates that would enable running alternative software.

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.

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.

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.

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.

or cracking.

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.

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.

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

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.

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.

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.

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.

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.

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…

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.

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.

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.

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

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.

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.

The claimed reason? Security. The real reason and effects? Destroying the competition and controlling what their users can do with their own hardware.

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.