Could that be considered somewhat misinformation?
As I understand it, this is only if Secure Boot is enabled and if disabled the distro can boot the machine. As for Linux Distros that want to use signing, MS almost freely ($99 for as many distros that you want signed) offer the signing service, there are just some non difficult steps to go through to prove they are official, that it is bug free. If no one likes using MS then they can always fork out the money and time to become a signing authority, Canonical also provide a dual signed shim that can be run using hardware certs from Canonical CA, and finally you can enroll your own key and use a self signed shim instead of the MS one.
From SecureBoot - Debian Wiki
"
What is UEFI Secure Boot NOT?
UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.
SB is also not meant to lock users out of controlling their own systems. Users can enrol extra keys into the system, allowing them to sign programs for their own systems. Many SB-enabled systems also allow users to remove the platform-provided keys altogether, forcing the firmware to only trust user-signed binaries."
"
Shim
shim is a simple software package that is designed to work as a first-stage bootloader on UEFI systems.
It was developed by a group of Linux developers from various distros, working together to make SB work using Free Software. It is a common piece of code that is safe, well-understood and audited so that it can be trusted and signed using platform keys. This means that Microsoft (or other potential firmware CA providers) only have to worry about signing shim, and not all of the other programs that distro vendors might want to support.
Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for as a trust root for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.
For extra trust and safety, from version 15 onwards the shim binary build is 100% reproducible - you can rebuild the Debian shim binary yourself to verify that no unexpected changes have been embedded in this key piece of security software.
MOK - Machine Owner Key
Generalities
A key part of the shim design is to allow users to control their own systems. The distro CA key is built in to the shim binary itself, but there is also an extra database of keys that can be managed by the user, the so-called Machine Owner Key (MOK for short).
Keys can be added and removed in the MOK list by the user, entirely separate from the distro CA key. The mokutil utility can be used to help manage the keys here from Linux userland, but changes to the MOK keys may only be confirmed directly from the console at boot time. This removes the risk of userland malware potentially enrolling new keys and therefore bypassing the entire point of SB."
From a Fedora thread and written by a mod there AdamW
"From reading some posts elsewhere, there was commentary that Microsoft is putting constraints on what software Linux can install with Secure Boot active. Is there anyone who can comment on the restrictions.
You can already expect that Secure Boot support for Linux will not take place until after Christmas, as it is not in Microsoft’s interest to move more quickly.
I for one can’t understand the delay, apart from having to accomodate Linux as a competitive product. If MS is concerned about security, the W7 and W8 systems should have been installed with encrypted file systems.
Please… Comments… Thank you.
Summary: no, not really. All PCs bought before Windows 8 was preloaded don’t have to worry about SB at all. All SB-enabled PCs (Windows 8 preloads) should run Fedora 18 and other soon-to-be-released distros out of the box, and should have an option to disable Secure Boot in the firmware config if you want to install F17 (or other older distros) or not have the Secure Boot restrictions in place.
Long explanation:
So Secure Boot is a single optional feature of recent versions of the UEFI firmware specification.
UEFI - UEFI - Wikipedia
UEFI is an industry standard replacement for the BIOS firmware specification which has been under development for several years (maybe a decade at this point, I forget). Fedora has supported UEFI (to a degree, support for specific systems is often bugged) since Fedora 12. Many UEFI-capable systems have been released into the market with no Secure Boot feature, including all Intel Apple systems and many others. I am typing this on one - if you have an Asus P8P67 motherboard, you have one too. Please, please, please do not confuse UEFI with Secure Boot.
Secure Boot is a feature of the UEFI spec since version 2.2. I believe it’s not required by the UEFI spec; the UEFI spec really just describes all the various standardized elements, it doesn’t prescribe which must be implemented (I’m willing to be corrected on this), and you can implement a viable UEFI firmware without it.
What the Secure Boot section of the UEFI spec does is define a mechanism by which the firmware can maintain a store of cryptographic keys for code signing and verification purposes. It defines how code to be executed from the firmware environment - and code executed from the running system with the capability to affect the firmware - can be signed and how a firmware implementation can check that signature against the list of keys it maintains, and refuse to run the code if it is not signed by a key in the list. It defines the ways in which the key database can be changed, and describes a mechanism for enabling or disabling the function.
This is all it does. It does not prescribe any particular way in which this function might be used. It does not prescribe any particular keys which must or must not be on the list, or any system for anyone to determine what keys to put in their list. It just describes a code signing mechanism for the firmware environment.
Secure Boot is not just a Microsoft Evil Plot. Microsoft is one of the industry bodies that supported it, but it has much wider support. There is general agreement among those who spend a lot of time thinking about firmware that signing and verification of the firmware executed boot chain is a Good Thing to have in various circumstances, and that’s really all SB implements. SB does genuinely improve security against certain types of attacks - those that target the boot chain. Such attacks do exist in the wild and though there are not a lot of them, they’re a very dangerous class of attacks, because the booted OS is essentially at the mercy of the boot chain, it has no way to defend against attacks from that vector or verify its integrity. (As mentioned below, one use of this attack vector is actually to bypass some of Windows 7’s anti-piracy mechanisms…)
Now let’s switch focus to Microsoft. Microsoft considers secure boot a valuable mechanism and wishes to ensure it is used on Windows systems. They say this is for the purpose of securing deployments against malware. There are various conspiracy theories to the effect that that’s just a smokescreen and they’re really pushing Secure Boot as a way to inconvenience competing operating systems. My personal opinion is that the conspiracy theories are a load of bullcrap and the real reason is exactly what Microsoft says it is, plus a little anti-piracy (the most common techniques for pirating Windows 7 would be blocked by mandatory Secure Boot, though no doubt others would emerge). Microsoft has been making a genuine and enthusiastic effort to get less terrible at defending against malware in the last decade or so, they’ve done a not-bad job, and their interest in SB is a natural extension of that. They could have pushed SB in a way which would be much more inconvenient for other OSes, but - at least after some negotiation - they are not doing so.
So anyway. What is it that Microsoft is doing exactly? First off, Microsoft is acting as an SB signing authority. That’s nothing unusual - anyone can up and start signing code. mjg59 is working on utilities to let you self-sign your bootchain code with a key you self-enrol in your firmware, if you like to twiddle. Moving on.
Microsoft has these things called ‘hardware certification requirements’. They’re a long laundry list of requirements that, if you are a hardware manufacturer / distributor, you have to meet in order to slap those shiny Windows stickers on your machines and qualify for discount OEM pricing for your Windows preloads. If you don’t meet the requirements, no Microsoft certification, no OEM pricing. Microsoft can’t stop you buying truckloads of copies at retail and preloading those, but you won’t be officially certified, and that will of course be far more expensive. And you won’t get access to Microsoft’s testing programs, which are pretty useful for integrators. So, in practice, virtually everyone who builds and sells PC hardware - consumer or enterprise - follows the certification requirements for the machines they sell with Windows preloaded, which as we all know is ‘most of them’.
In the hardware certification requirements for Windows 8 and Windows RT (the correct name for ‘the ARM version of Windows 8’), Microsoft has included requirements relating to Secure Boot.
For Windows 8 - that’s x86(64) platforms, remember, the requirements can be stated thus:
- Secure Boot must be enabled by default
- The Microsoft key must be enrolled by default
- It must be possible for the user to disable Secure Boot
For Windows RT - that’s only ARM, remember - the requirements can be stated thus:
- Secure Boot must be enabled by default
- The Microsoft key must be enrolled by default
- It must not be possible for the user to disable Secure Boot or enrol their own keys
The Windows 8 requirements contain an obvious concession to non-Windows OSes: the mandated ability to disable SB. I believe this was added as a result of negotiations with other OS vendors, but I’m not a party to those so I can’t tell you for sure. Note also that it does not mandate, for instance, that no other keys be enrolled by default. A theoretical system with Microsoft’s key, a Red Hat key, a Novell key, and a Slackware key all enrolled in the default key list could happily pass Microsoft’s requirements. The way the requirements are worded intentionally left the door open for other SB signing authorities to be created, and for their keys to be enrolled on machines pre-installed with Windows.
The Windows RT requirements are significantly tighter and, in practice, boil down to ‘if you buy a Windows RT certified device, you’re probably only going to be able to run Windows RT on it, unless the hackers figure out how to break the locks’. Bear this in mind if you’re thinking of buying a Windows RT device. I know I’m not going to. It is worth pointing out that Microsoft is no kind of monopolist in the ARM device market - tablets, etc - and that competing devices tend to be similarly locked down (iDevices and most Android tablets come with locked bootloaders). You can certainly buy non-Windows RT ARM devices if that’s what you want.
So, back to our SB-on-Intel story. The ultimately agreed-upon arrangement for SB, as I noted above, intentionally left the door open for parties other than Microsoft to act as public signing authorities for Secure Boot. It’d be perfectly possible in theory for Red Hat or any other Linux vendor, or for a non-profit like the Linux Foundation, to step up and say they’ll be a public SB signing authority, that you can send your code to them for verification and signing, and ask (or try to require) hardware manufacturers to include their key in their firmware implementations - just what Microsoft has done.
In practice this has not happened. Basically, it’s a difficult job for no reward and no-one really wants to do it. By signing other people’s code you are taking on risk you don’t actually need to take on - you’re effectively staking your reputation on an assertion that that code is good code, you’re asserting to others that they can trust the code. Doing this kind of thing is a difficult and rather thankless job that no-one particularly wanted. When you’re doing it for, say, websites, you at least have volume on your side - companies that issue SSL certs for websites (which is a similar kind of job) make money by charging for each cert, and they need volumes in the hundreds of thousands, I guess, to make that worthwhile. There are, oh, let’s say, maybe 100? 500? entities in the world which might possibly be interested in getting the boot chain of their operating system signed by an SB signing authority, and only maybe 5-10 of them could afford to pay a realistic ‘market rate’ for that service. All the others can’t. What I’m saying, in a longwinded way, is there’s no money in being an SB signing authority, but it involves taking on an element of risk. It would have to be done essentially as a public service.
So what happened? Well, guess - no-one actually wants to be a public SB signing authority. Red Hat doesn’t - we really don’t need the organizational overhead, plus it would open us up to charges that we were trying to dominate the Linux world (even more than we already get accused of that anyway) by being the SB gatekeeper for all of Linux. The Linux Foundation thought about it, but demurred. No-one else wants to do it either.
So in reality, the only public SB signing authority is Microsoft. This isn’t something Microsoft cleverly engineered or maneuvered everyone else into, it’s just an upshot of the basic economics of the whole deal. Microsoft didn’t put any roadblocks in the way of RH or the Linux Foundation or anyone else being an SB signing authority. They would’ve let it happen. It just didn’t happen.
Microsoft (in partnership with Verisign, which is actually doing most of the heavy lifting) is acting as a public SB signing service. It’s not going to make any money on this, it will actually lose money, quite a lot of it. It’s charging some nominal fee - like $100, I think - to have your code vetted and signed with the Microsoft key; it’ll cost Microsoft/Verisign far more than $100 per applicant to actually do the work. Microsoft is doing this because it recognizes it kinda has to, for publicity and possible legal reasons. It’s at least arguable that if it doesn’t sign other people’s code, Microsoft is effectively abusing its monopoly position in the OS market - I’m sure Microsoft would disagree and would fight any such allegation, but I’m equally sure it would be much happier for it never to come to that. Even if there wasn’t a legal case, the publicity result of not acting as a signing authority would be pretty terrible - there would be far more and far worse publicity even than there is with the current situation. So Microsoft is taking a nominal fee to sign other vendors’ code with its key, to try and defuse allegations of unfair competition, monopoly abuse etc. It hasn’t actually been legally compelled to do so or anything, it just chose to do so, which was obviously a sensible decision.
Ultimately what is going to happen with Linux and SB is that the next generation of distros - Fedora 18 and so on - will be signed with the Microsoft key so they will run out of the box on Windows 8-certified machines. That’s the bottom line. The exact mechanism that will be used here is somewhat clever - mjg59 came up with most of the design, and SUSE contributed a rather neat refinement, though the Linux Foundation now appears to be rather loudly attempting to claim the credit - but it’s a technical detail, really. That’s all you need to know in a nutshell. Right now, RH, Microsoft, SUSE and Canonical are enriching a bunch of lawyers to hammer out the exact agreement by which Microsoft will sign all of our boot chains, and that ought to be in place for the final release of Fedora 18 (and the next releases of the other distros). We were rather hoping it would be done for Beta, but it isn’t.
If your system doesn’t support Secure Boot - if it’s not a box you bought very recently with Windows 8 on it, it almost certainly doesn’t - you don’t need to worry about any of this at all. If you buy a Windows 8 preloaded system in the near future, you won’t be able to install Fedora 17 or other contemporary distros on it unless you manually disable Secure Boot (which you should be able to do from the firmware config interface), but you ought to be able to install Fedora 18 Final OOTB when it’s released (and similar contemporary distros). You can also simply disable SB from the firmware config if you don’t want to bother with all this stuff at all, as mentioned above, the Microsoft certification requirements mandate that you be allowed to do this (if you buy a Win8 machine and find you can’t disable SB, complain loudly to Microsoft and the vendor, as this is a breach of the requirements). If you boot with SB enabled, certain operations from user space which could affect the boot chain will be restricted - kernel modules have to be signed in order to be loaded, for instance. To remove these restrictions you will have to boot with SB disabled.
Sorry for the essay, but I really hope that finally clears this up, for some people at least."
Pros: a lot of Windows apps come in Mac versions as well, and for paid ones the Mac version might have been included in the price, so there might be fewer app compromises needed than with Linux. Cons: Cost again! You have to buy an Apple device; the user interface is quite different from Windows, so could be a steep learning curve; existing accessories might not slot into the Apple environment.