Debian Developers Discuss UEFI SecureBoot Plans

Quote:

---

Originally Posted by TobiSGD

So do Apple and many Android vendors. Why is nobody complaining about them?
So why do you think that no antitrust shit will be raining when Windows 9 is released?
The only way would be if Microsoft suddenly wouldn't be a monopoly anymore. But If Microsoft will not rule the market anymore, why should the manufacturers close their products to the other players on the market.
Microsoft won the browser wars in the beginning, but look at the browsers now, in the long run there was competition. I think that the same will be with the OSes, they won the OS wars in the beginning, but we will see diversion again.

---

I've seen the argument that nobody care when android vendors use locked boot loaders in most secure boot discussions. Have you all forgot the outrage over those last year and the year before? Complains to the point that some vendors even changed their ways somewhat, enabling flashing and booting of unsigned stuff. Search for bootloader on ars technica for a sample of the fuss about the lockedness of android phone bootloaders. Granted, the issue is somewhat bigger there ("rooting", flashing etc, on top of signatures), but the end-issue is the same, loading stuff of your choice on your device. As for apple, It's been a constant complains about their general lockinness, the whole thing about the us dmca exception for circumventing some of their restrictions for example. The fight with apple and android vendors for the right to your own device have been raging for years with a few victories and some half-victories along the way and at least the situation on android is better as a result of that fight.


On the actual topic:
I don't see how anyone responsible for keys (like using a key from ms) would allow anyone to sign a bootloader with their key that does not check the signature of kernel (and initrd?) or that would not require that that kernel checks signatures on modules. Having a bootloader that does not check signatures should invalidate most of the purpose?

Shipping a distribution with signed chain of bootloader-kernel-initrd-modules feels like a big step towards "tivolization". It would be a sad day indeed if the we (we the "foss-comunity") would end up tivolizate our selves.

They could boot directly to a signed kernel from UEFI, which shouldn't be that hard. If they don't like that option, there's always Gummiboot.

There are ways to make rooted, open bootloader computers, not just for devs, but computers that reach the mainstream and make it so Debian doesn't have to compromise at the core. We've been working at OEM level for a few years and are hoping to keep traction through upcoming years. It's actually not that hard to do runs of computers at OEM level, but it is a pain to do the distribution chain part of the equation (shipping, admin types of things).

Read Cory Doctorow's input on it: http://boingboing.net/2012/07/06/zar...company-w.html

The tools are available. We just need to find a way to make it work. On our end, we need to find a way to motivate Debian devs to help us out. We're on a ridiculously tight budget and already run on the fuel of volunteers in our core team (some, not all). We'll keep doing the best we can and if Debian wants to keep it open, we're here to support on the hardware end.

Personally, I'd love to see Debian thrive. There's a really nice Debian community guy that talks to us at nearly every conference, encouraging us to do more work to support Debian on our machines. We need a bit more dev support & it would be a Go.

There's no reason to sell out when there are options.

--Cathy Malmrose, CEO ZaReason
zareason.com North America
zareason.co.nz Australasia

Quote:

---

Originally Posted by TobiSGD

I can only say it again, on x86 hardware Microsoft is actively forcing the hardware manufacturers to not lock out other systems, if they want to get the Windows 8 logo for their hardware. Why is everyone bitching about Microsoft but no one actually reading their documentation?

---

Can you point to some source? For all I know, Microsoft officially will certify your UEFI-enabled PC hardware regardless of whether it is locked or not, but in practice those manufacturers who do not lock their hardware happen to have to jump through a lot more hoops, and some are hinted by MS reps about this.

Quote:

---

Originally Posted by TobiSGD

So do Apple and many Android vendors. Why is nobody complaining about them?
So why do you think that no antitrust shit will be raining when Windows 9 is released?
The only way would be if Microsoft suddenly wouldn't be a monopoly anymore. But If Microsoft will not rule the market anymore, why should the manufacturers close their products to the other players on the market.
Microsoft won the browser wars in the beginning, but look at the browsers now, in the long run there was competition. I think that the same will be with the OSes, they won the OS wars in the beginning, but we will see diversion again.

---

We see browser competition because after winning the war there MS let IE rot to the degree it was next to unusable. Do you seriously believe they will repeat that mistake again? Judging by the ARM lock-in requirement, I don't.

Quote:

---

Originally Posted by grigor

Can you point to some source? For all I know, Microsoft officially will certify your UEFI-enabled PC hardware regardless of whether it is locked or not, but in practice those manufacturers who do not lock their hardware happen to have to jump through a lot more hoops, and some are hinted by MS reps about this.

---

http://msdn.microsoft.com/en-us/libr...dware/hh748200

Quote:

---

Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems.

---

Quote:

---

Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:

It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.

If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.

The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.

---

Quote:

---

Originally Posted by garegin

debian always chooses ideology over common sense. so it is no wonder that they'll have the most awkward solution for secureboot.

---

That's why they make the richest and arguably most stable distro. And, despite being an informal organization with next to no funding, and competing with billion-dollar corporations, they create the base for about 70% of all deployed distros. (Hat off to RedHat for its contributions, it is indispensable in the GNU/Linux community, but Debian also is, in a different way.)

I believe that the best solution will be for the Linux Foundation to create their own key and make available a signed shim micro-bootloader to every distro that wants it. As this bootloader will only load the real one, it won't matter too much if it is under a permissive license. Distros that want to present a corporate-convincing model will be able to sign also grub2, kernel, modules, programs and the kitchen sink. And distros that want to be user-convenient will be able to sign nothing, or as little as needed.

The same solution can be used to circumvent the MS ARM lock-in. If every distro can freely have a signed micro-bootloader, then the platform is unlocked.

Initially the "signed bootloader for everyone" will appear highly insecure. However, time will pass and people will see that Windows 8+ is still plagued by viruses despite the signing model will all of its inconveniences and GNU/Linux is still virus-free. And this will be a key victory for the freedom in the user mentality - a very visible demonstration that it is not the thickness of the wall around the garden, but the openness and friendliness that eventually make a system secure.

I think Debian must weigh in the Linux Foundation for this solution. If the Foundation refuses (some of its participants may see others as competitors, and may try to get their private solution and jeopardize attempts to produce a solution for everybody), I think Debian's best move will be to try and implement this itself. Even for the Foundation it will be an effort to court most hardware manufacturers to accept their key. For Debian this will be even harder, but still, with the help of partners and some other distros it might be possible. Yes, not all manufacturers will jump on board, but no aspect of UEFI will have all of them on board either - technical problems are unavoidable. And circumventing of the ARM lock-in is worth the effort.

Quote:

---

Originally Posted by TobiSGD

http://msdn.microsoft.com/en-us/libr...dware/hh748200

---

Quote:

---

Originally Posted by TobiSGD

Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:

It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.

If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.

The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled

---

This is a source about MS being forced to require manufacturers to allow unlocking on non-ARM, not to require manufacturers to not lock it.

In fact, MS strive to get manufacturers to ship systems locked by default - exactly the opposite of what you claim. (Which is against the interest of the manufacturers, but otherwise they risk to lose good prices for OEM Windows and to have a lot of problems certifying their drivers.) Most users are not technical enough to easily unlock the UEFI, so shipping PCs locked by default makes locked mode all most users will know.

(Don't tell me users are given the opportunity, and the rest does not depend on MS. Even if PCs are completely locked, users have the opportunity to design and manufacture their own computer, or start a company and outcompete MS, right? Yes, most will not be able to. Most will also not be able to unlock an UEFI; it is you that can do the second, but not the first. Yes, it is natural to have self-centric viewpoint, but is communicating it only good for finding a common solution?)

I am assuming signing means certificate. With that as an assumption and yes I'll need to read more. My thoughts are with all the cert vendors getting hacked I don't believe this is for security. M$ does not work and play well with others, I'm a windows admin as a primary role, however over the years I do not agree with M$ "business" practices. I did not like "activation" and I certainly do not like what they have done with their latest versions of their OS. 2008 R2, 7 and now 8 they are taking more control away from the end user end of story. I also see them snooping into what you have on your machine I.E. go look at any task in the task scheduler, now go and disable it. It will not disable UNTIL you have the trigger turned off or you delete the task outright.

So with all that said and yes I have a long list of WTFOs that I could list, but I'm not going to. These reasons are why I moved over to Linux. I have control over what the machine will do, I also have control over being able to develop things to do what I want. Freedom was what I was looking for and M$ has chipped away at those freedoms over the course of my career.

So back on topic. I do not see this UEFI/Secureboot thing as a needed thing to implement. OEMs should outright say no to this and who cares if they don't get a "sticker" (I'm reminded of star belly sneeches here.) I see two possible issues:
1. Lock out of the HW for other OSes. (It will happen)
2. A great way to render a windows PC useless by messing with the key or hacking it and placing another key there.

So this is an opportunity for those that have the money to start building their own hardware that is open and not influenced by M$. I think Ubuntu would have that kind of money, but I would hope others would as well. Furthermore I think if the OEMs had any sort of clue they would build out systems or work with their component vendors to provide open hardware where this "feature" is not even on the board. A vendor fork if you will.

I only have one windows machine in the house and 7 is the last M$ OS that will be on it. It's only purpose is to run windows apps that will have trouble on the dated HW that Linux now runs on. If the end user base had any inkling of how difficult M$ has made things they'd be switching to somthing else.

@CathyMalmrose

I don't get whats your problem. If your hardware is _really_ so open then you most likely already use coreboot. And you could use seabios or tianocore payloads or whatever you want. The sample secure boot implemention is completely opensource. What has debian to do with your problem? If you want a feature thats not in debian create a personal repository and put your packages in there. If you want to use shim to chainload a signed grub then just do so, nobody holds you back. Basically a thrusted chain would require that you restrict access to the firmware as well, like let it flash only when the new firmware is signed, that seems to be more problematic i guess with your hardware as most likely flashrom has got full access already.