Stand up for your freedom to install free software

[srs5694]

Originally Posted by stevea

Wow that really missed the issue -

I was trying to correct some fundamental misconceptions in the original post (and others on this topic). Without an accurate understanding of the issue, a person will be led to incorrect conclusions and make sub-optimal decisions. I was not trying to address every aspect of the issue as a whole, just those areas where old or inaccurate information seems to be running amok.

MS confirmed that first concept, potentially disable by EOMs (not necessarily end users) only on a blog. Has there been an official statement ? The Win8 cert does not require 'enable'. That's not the same as requiring 'disable'.

As your subsequent post shows, the Windows 8 certification does require that end users have the ability to enable or disable Secure Boot. The blog post you mention is probably Matthew Garrett's first blog post on the subject, although it contains some key details that are now outdated. For instance, that post was made before Microsoft added the need for the user to be able to disable Secure Boot or add their own keys. Too many people are aware of the issue as originally publicized, but have failed to absorb subsequent revisions that make the issue much less troubling in the short term, albeit still something that could become a serious threat in the future.

So you might be able to dual-boot win8 and F18, but perhaps no other end-user Linux.

That's incorrect. You'll be able to add your own key and sign any boot loader you want to sign; or you can disable Secure Boot entirely; or you can pay $99 to Verisign and get any binary you want signed with Microsoft's key. Granted, these options all require at least a little effort, and disabling Secure Boot may have negative security implications, particularly if you run Windows a lot. Still, they are (or will be, since Secure Boot is still mostly theoretical) options, so suggesting they won't be possible is incorrect.

Also a disable-able secure boot is fundamentally insecure, which suggests this is not M$ final position.

True, and I've said so. I even pointed out that future developments could be more of a threat in the text you quoted and claimed was "missing the issue."

[stevea]

Originally Posted by srs5694

I was trying to correct some fundamental misconceptions in the original post (and others on this topic). Without an accurate understanding of the issue, a person will be led to incorrect conclusions and make sub-optimal decisions. I was not trying to address every aspect of the issue as a whole, just those areas where old or inaccurate information seems to be running amok.

Fair enough

As your subsequent post shows, the Windows 8 certification does require that end users have the ability to enable or disable Secure Boot.

I haven't seen the actual Wi8 cert, just 3rd hand reports - have you ? Who says that the lockdown policiy will in the future just involve ARM ? Seems VERY unlikely.

The blog post you mention is probably Matthew Garrett's first blog post on the subject, although it contains some key details that are now outdated. For instance, that post was made before Microsoft added the need for the user to be able to disable Secure Boot or add their own keys. Too many people are aware of the issue as originally publicized, but have failed to absorb subsequent revisions that make the issue much less troubling in the short term, albeit still something that could become a serious threat in the future.

No no no ! Garrett works for RedHat - I specifically mentioned the Microsoft blog, the one by Mangefeste
http://blogs.msdn.com/b/b8/archive/2...with-uefi.aspx

In that blog Mangefeste suggests that Microsoft, in it's magnificent goodness, will permit EOMs to disable secure boot to support old legacy OSes. That's NOT a satisfying level of access or assurance.

That's incorrect. You'll be able to add your own key and sign any boot loader you want to sign; or you can disable Secure Boot entirely; or you can pay $99 to Verisign and get any binary you want signed with Microsoft's key. Granted, these options all require at least a little effort, and disabling Secure Boot may have negative security implications, particularly if you run Windows a lot. Still, they are (or will be, since Secure Boot is still mostly theoretical) options, so suggesting they won't be possible is incorrect.

According the the Cannonical/Redhat whitepaper that is NOT TRUE !
http://ozlabs.org/docs/uefi-secure-b...t-on-linux.pdf

5.3. Ability to reconfigure keys
Some Linux users may wish to use secure boot functionality with custom images. In this case, they
will never be using the OEM-defined keys. The UEFI specification defines a “setup mode” where
keys can be configured.

For this use case, users will need to be able to reconfigure the platform’s firmware to include their
own keys, which will require an interface to do so. However, since this will be a relatively
infrequently-used feature, it does not seem likely that BIOS vendors will implement it for general-
purpose usage.

The OEMs *MAY* allow you to enter new keys. To be Win8 compliant they MUST allow you to disable (according to 3rd hand). That is not the same as entering your own keys and not a long term assurance.

I build & test 1 to 10 kernels a week for myself and for work. Do you think I'll be paying a $99/shot MicroSoft tax ? I really would like to generate my own KeK when I have something stable, but that's gonna be firmware dependent. Have you ever examined the firmware quality in modern systems - it's junk, minimalist, problematic.

True, and I've said so. I even pointed out that future developments could be more of a threat in the text you quoted and claimed was "missing the issue."

But the future is already here for ARM. The good news is that M$ is losing the ARM space at a satisfactory rate.

OK - I'll be generous and admit you've outlined some significant issues that many don't understand. I think it falls short an clear authoritative overview of the problems and status. (I'm not claiming I've done more than point to some glaring problems not discussed). What seems to be missing is an acknowledgment that the only temporary we have due to Win8 is a temporary access to disabling SB. There is no requirement that new keys be generable or administrable. After that some firmware may require you buy a $99 signature (or else use Fedora's) to boot.


I'd outline the broad issues as ,
1/ How did we get to a situation where the future of the PC, which clearly involves UEFI, includes a secure boot feature is tailored to be hijacked by proprietary vendors to anti-competitive ends that may exclude or make open software solutions impossible based on OEM discretion (OEM decisions greatly influenced by the same vendor). 'Software only comes from big vendors' is not a model I accept.
2/ Ditto for ARM except the software lockout is already under way.
3/ The whitepaper above outlines the issues and a more realistic approach to boot security with revocable keys. A first step would be to REQUIRE the ability to disable/enable and enter new keys on all implementations. This is not currently the case for PCs.
4/ The key generation mechanism should be published and public.

---------- Post added at 08:06 PM ---------- Previous post was at 07:43 PM ----------

Originally Posted by Magickman

The hell with them. Don't buy a commercial PC, buld your own, you get a much better computer for a lot less money. I think this could easily be worked around anyway by clearing the BIOS.
M$ wants to run the entire computer world, no big secret there.

So in two years if all the Asus/MSI/Gigabyte mobos are locked-down for Win9 - then what do you do ?
This isn't about hardware - it's about firmware and you don't have a lot of choices there.
No 'clearing' the BIOS which is now UEFI won't fix the issue unless it's an potion.

[angryfirelord]

Step 1: Go to UEFI and turn off secure boot.
Step 2: Install Linux.
Step 3: Profit?

Besides, that one-time-deal of $99 goes to Verisign, not Microsoft.

[srs5694]

Originally Posted by stevea

I haven't seen the actual Wi8 cert, just 3rd hand reports - have you ? Who says that the lockdown policiy will in the future just involve ARM ? Seems VERY unlikely.

It's available at this Microsoft site. (Note: click-through license agreement required.) Provisions 17 and 18 under "System.Fundamentals.Firmware.UEFISecureBoot" explicitly address the topics of users modifying the key database and completely disabling Secure Boot, respectively. These features are both required for x86-64 systems, and are forbidden for ARM systems. I admit I'm a little foggy on the technical details of entering your own keys, and getting your keys to coexist with Microsoft's could be tricky.

As I have said several times in this thread already, I do agree with you that in the future (Windows 9 or later) on x86-64 and soon (Windows 8) on Microsoft-certified ARM devices it could be (or is) much worse. IMHO, though, it's very important that we raise an appropriate level of concern. Crying "wolf" right now just makes the one doing the screaming look like an alarmist, since we'll all be able to install Fedora and other major Linux distributions on Windows 8 boxes with little or no trouble, and more obscure distributions without Microsoft-signed boot loaders with very little more effort. If Microsoft changes their certification requirements in another couple of years and we cry "wolf" again at that time, we may be ignored because of the lack of any wolves this time around.

No no no ! Garrett works for RedHat - I specifically mentioned the Microsoft blog, the one by Mangefeste
http://blogs.msdn.com/b/b8/archive/2...with-uefi.aspx

In that blog Mangefeste suggests that Microsoft, in it's magnificent goodness, will permit EOMs to disable secure boot to support old legacy OSes. That's NOT a satisfying level of access or assurance.

That's a very old post with outdated information. Both Garrett's first post on the topic and Mangefeste's response occurred before Microsoft added the requirement that users be able to disable Secure Boot or modify its settings to its certification requirements.

FWIW, those changes may have been in response to the uproar that occurred at that time. Please don't rehash outdated information as if it were current; the new situation, although troubling, is not nearly as bad as it looked several months back.

According the the Cannonical/Redhat whitepaper that is NOT TRUE !
http://ozlabs.org/docs/uefi-secure-b...t-on-linux.pdf

That's also a very old analysis. It dates to October of last year. Things have changed since then.

Your analysis is incorrect. Please read the current Microsoft requirements.

Per [url=http://mjg59.dreamwidth.org/#entry-12368]one of Garrett's blog posts

, the $99 fee is a one-time fee that enables the purchaser to sign (or more precisely, to have signed) an unlimited number of binaries. (This is elaborated upon elsewhere, but I don't have references handy.) If you wanted to go this route, you could pay your $99 and sign hundreds of binaries from that one $99 payment.

That said, from what I've read it sounds as if the binary signing isn't instantaneous. If you're futzing around with kernels like this, you'd probably be better off disabling Secure Boot entirely. You won't be any worse off than you are now in terms of security, and it'll be much easier than dealing with another step in kernel setup. Alternatively, you could sign a boot loader that you trust and that uses its own security system to authenticate kernels using whatever keys you create yourself. That's what Fedora's doing.

I really would like to generate my own KeK when I have something stable, but that's gonna be firmware dependent.

You're incorrect, as per Microsoft's documents. You will be able to do this. It might be a hassle, but it will be possible.

Have you ever examined the firmware quality in modern systems - it's junk, minimalist, problematic.

You'll get no arguments from me on that score.

I'd outline the broad issues as ,
1/ How did we get to a situation where the future of the PC, which clearly involves UEFI, includes a secure boot feature is tailored to be hijacked by proprietary vendors to anti-competitive ends that may exclude or make open software solutions impossible based on OEM discretion (OEM decisions greatly influenced by the same vendor). 'Software only comes from big vendors' is not a model I accept.

That is indeed an interesting question. If I were an investigative journalist in the computer field, I might be looking into that question. My suspicion is that it was a combination of the representatives of open source companies having "fallen asleep at the wheel" as the UEFI spec's Secure Boot features were being designed and Microsoft either being devious enough to take advantage of the problem or blundering into it. That's just my suspicion, though.

3/ The whitepaper above outlines the issues and a more realistic approach to boot security with revocable keys. A first step would be to REQUIRE the ability to disable/enable and enter new keys on all implementations. This is not currently the case for PCs.

Moving forward, yes, adding a requirement to the UEFI spec that users must be able to modify the keys and disable Secure Boot would be a good first step. I don't happen to be in control of the UEFI spec, though, nor do I know what's actually being discussed in that realm.

4/ The key generation mechanism should be published and public.

It is. All the UEFI specs are published and open. See this PDF file for the information on signing UEFI images. I haven't yet looked it over in detail.

FWIW, one further issue that I've seen mentioned but that doesn't get a lot of discussion is the international implications of all this. Especially in light of the ever-increasing confirmation that Stuxnet and Flame were the work of the US government, I find it hard to believe that non-US governments can be happy about giving signing rights to their computers' firmware to a US company. They might be willing to go along with the Secure Boot/Windows 8 requirements as planned, since they can get around it on computers whose security is important; but they'll want the same things we in the open source world want: control over the security settings on our computers. Thus, I expect there to be pressure from various governments to revise the standards in ways that are likely to be better from our point of view, too.

[deanej]

The problem with the crying wolf analogy is that we are not saying there's a wolf here right now. We're saying there will be one here a few years from now. Why people don't ever think long term with regards to technology is beyond me.

That said, we're safe for as long as Windows 7 is supported. The reason MS requires that secure boot can be disabled is due to older versions of Windows. But you can bet a million dollars that as soon as Windows 7 goes EOL, that it will no longer be possible to disable secure boot.

[RupertPupkin]

Originally Posted by deanej

The problem with the crying wolf analogy is that we are not saying there's a wolf here right now. We're saying there will be one here a few years from now.

Heh, in a way that's actually worse. In fact, it's what some Linux users have been doing for years. When their predictions invariably don't come true, instead of admitting they were wrong they just move on to the next doom-and-gloom prediction. The Chicken Little mentality is strong in a certain segment of the Linux community, unfortunately.

Originally Posted by deanej

But you can bet a million dollars that as soon as Windows 7 goes EOL, that it will no longer be possible to disable secure boot.

I'll gladly take that bet. Something tells me you won't pay up when it doesn't happen.

[srs5694]

Originally Posted by deanej

The problem with the crying wolf analogy is that we are not saying there's a wolf here right now. We're saying there will be one here a few years from now. Why people don't ever think long term with regards to technology is beyond me.

I don't know what you personally have written on the subject, but I've seen a lot of people claiming all sorts of doom and gloom about Secure Boot in the very near future (as in, as soon as Windows 8 PCs start shipping -- probably later this year). Those fears will prove to be overblown (short of last-minute changes to Microsoft's certification requirements).

As to the long term, who knows? It's out of your or my hands, but companies, organizations, and even governments with interests that align with yours and mine on this matter are certainly alerted and have time to plan and prepare. The very worst-case scenario I can see happening over the next decade or so is erosion of boot choices on dedicated hardware like cellphones and perhaps tablets. Unfortunately, that's already largely the case with them, so that will be a case of it going from bad to slightly worse. To the extent that these devices take over computing tasks from desktops and laptops, this damage will be amplified, but I just don't see the sky falling on this particular sub-issue. There are a lot of ways that the whole Secure Boot issue can be kept in check, such as:

• Changes to the UEFI spec to guarantee end-user configurability and/or to provide a more flexible signing mechanism that would minimize vendor lock-in risks.
• The emergence of a viable certification to compete with Microsoft's (even in a non-exclusive way), that would guarantee the possibility of signing by any interested party. (Something like Ubuntu's certification could be a springboard for this, but as it is Ubuntu's certification doesn't cut it because it doesn't provide for signed third-party binaries.)
• Demands from governments or other large organizations for the ability to sign binaries with their own keys. This could, at the very least, keep Microsoft from pushing further for fear of losing sales.
• Anti-trust lawsuits could keep it from going further.

There are other possible developments in the technical arena, too, like massive malware attacks or breakthroughs in cryptography rendering the current system completely non-viable. I wouldn't want to count on such things happening, though.

The bottom line, IMHO: Secure Boot is a danger in the long term, but it's in the category of things that we as ordinary members of the community need to watch, not freak out about. The next few moves in this game will be played out in the committees that write specifications, company policies, and the like. If things start moving in the wrong direction again, we'll hear about it from people like Matthew Garrett, and then it may be time to do something more, like contributing to CoreBoot or other projects that might stand a chance to compete, or at least be viable alternatives for interested parties.

[mmix]

https://en.wikipedia.org/wiki/Unifie...ware_Interface

Criticism

Numerous digital rights activitists have protested against UEFI. Ronald G. Minnich, a co-author of coreboot, and Cory Doctorow, a digital rights activist, have criticized EFI as an attempt to preserve “intellectual property” by removing the ability of the user to truly control his computer.[45][46] It does not solve any of the BIOS's long standing problems of requiring two different drivers — one for the firmware and one for the operating system — for most hardware.[47]

TianoCore,[48] an open-source project which provides the UEFI interfaces, lacks the specialized drivers that initialize chipset functions, which are instead provided by coreboot, of which TianoCore is one of many payload options. The development of Coreboot requires chipset manufactures to cooperate by providing specifications needed to develop initialization drivers.

UEFI reimplements a full networking stack, unlike many BIOSes, and therefore is a target for remote security exploits.[49]

---------- Post added at 07:11 AM ---------- Previous post was at 06:53 AM ----------

i see dead pc's. heh :)
http://mjg59.dreamwidth.org/12745.html

mass pc suicide, move people to android/iphone world..
microshaft,nokia, fedora, ubuntu is the next..

[mmix]

Free Software Foundation recommendations for free operating system distributions considering Secure Boot

https://www.fsf.org/campaigns/secure...whitepaper-web

https://www.gnu.org/distros/free-distros.html

We will continue to build public support around our statement against Restricted Boot. Over 31,000 people and 25 organizations have signed this statement, pledging not to buy any computer that they cannot install a free operating system on, and to advise others to do the same. We were pleased last week to add Debian GNU/Linux as an official organizational supporter of the statement. Subsequently, Trisquel and gNewSense have also added their signatures. When further actions need to be taken to stand up for this freedom as Secure Boot and Restricted Boot are rolled out, we will call upon this base of support. If you haven't yet signed, please do.

We will fight Microsoft's attempt at enforcing Restricted Boot on ARM devices like smartphones and tablets. Like any other computer, users must be able to install free software operating systems on these devices. We will monitor Microsoft's behavior to make sure they do not deceive the public again by expanding these restrictions to other kinds of systems.

We will work with (and when necessary, pressure) manufacturers and distributors to make the user instructions for working with Secure Boot on all systems extremely clear, so that users will be able to disable it and modify the approved keys with little difficulty and no bias. We will also work to make sure that users can change all of the software running on their machine, including the boot firmware itself.

We will offer our licensing and compliance resources to any free software developers to help them make sure they are complying with the GPL and other licenses as they implement Secure Boot. We will monitor distributions of signed GPLv3 software to ensure that they respect the necessary user freedoms, including providing installation instructions and materials.

We have already started exploring ways in which the FSF can work with manufacturers on behalf of the entire free software community to make free software operating systems installable with default Secure Boot hardware settings.

We will continue to work with companies like Lemote, Freedom Included, ZaReason, ThinkPenguin, Los Alamos Computers, Garlach44, and InaTux to make computers available that are preinstalled with fully free GNU/Linux distributions.

We will help provide information about which computers and components are most compatible with free software, including making people aware of which machines have Restricted Boot. Much of this information will be found at http://h-node.org.

[mmix]

IMHO, ubuntu just sucks, more than microshaft..
http://linux.slashdot.org/story/12/0...-boot-solution

Until Windows 9 requires that Secure Boot can't be turned off and you can't install new keys if you want to ship with a 'Windows compatible' sticker.

FSF may be fruitcakes at times, but on this they're correct. 'Secure Boot' should have been named 'Windows lockin'.

Some dogs like their leashes. :(

Some users prefer walled gardens. They don't know what they've lost.

It's rather stunning how close we are getting to some of the dystopias predicted by the FSF. They seemed silly at the time.

[mmix]

Red Hat & Ubuntu's UEFI Solutions Not Good For FOSS

http://www.linuxtoday.com/upload/red...705230003.html

http://fossforce.com/2012/07/red-hat...ons-good-foss/

Instead of cooperating with Microsoft’s bid to put a lock on the operating system market, we should be fighting them. For starters, it would appear there are some antitrust issues that could possibly be pursued. Maybe Google could put some pressure on companies making Android ARM devices to just say no to Secure Boot without an easy-to-use “off” button.

There are plenty of geniuses at Red Hat and Ubuntu. They can think of a better way to deal with this issue.

[mmix]

Die! new PC industry, Die!
homebrew cpu yeah!

Debian Developers Discuss UEFI SecureBoot Plans
http://www.phoronix.com/scan.php?pag...tem&px=MTEzNjU

While this work was discussed, nothing genuinely new was brought up during the 45-minute discussion. It's still not decided what approach Debian will ultimately support whether it's like Fedora using GRUB2 and singing the entire stack, Ubuntu using efilinux and only signing the low-level bits, or some entirely new approach for handling EFI/SecureBoot. However, something has to be decided for Debian 7.0 "Wheezy" seeing as when it ships early next year there will be a number of motherboards and PCs shipping with this headache-inducing technology.

[R3v0lut10nary]

This is just a stab in the dark here but....

Would this benefit companies like System76 and possibly decimate companies like Dell and others that are more affected by OEM's in tight with Microsoft?


EDIT: And system76 ships Ubuntu software. I'm confused about the relationships....?

[exiledangel420]

Freedom of choice is what it boils down to. Do I have the right to use my computer the way I want to? Opensource will never die. But how we use it will change mainly because of companies like microsoft and apple.
UFEI is dangerous, but at this point they are to many computers out their that are too old to use even windows 7. And moving forward their will be people who also will build their own computers to avoid it. My question is what will happen 30 years when most of these old computers are no more. Will their be a viable alternate option then? For companies like microsoft and apple who don't like supporting old systems till they die. Will they provide operating systems that support old computers of this time? Buy the new hot thing and suffer the consquences of these companies and others like thems' greed.

[stevea]

Originally Posted by srs5694

It's available at [url=http://msdn.microsoft.com/en-us/library/windows/hardware/hh748200.aspx][...] completely disabling Secure Boot, respectively. These features are both required for x86-64 systems, and are forbidden for ARM systems.[...] I admit I'm a little foggy on the technical details of [...]

B/C there are no details - it's up the the vendor, same jokers that design BIOS interfaces. The document doesn't address my main concerns...

17. 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:
a. 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.
b. 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.
c.
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.

Translation:
Non-Win OSes shall have no access to ARM hardware that intends to use Win8.
MS will allow booting non-Win signed OSes, however this method "deleting the PK" necessarily means that Win8 cannot be booted without manual reconfiguration.

Pure anticompetitive behavior.

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

Translation: MS will allow you to use open SW on Win8 ready systems by opening security holes.

[...]. Crying "wolf" right now just makes the one doing the screaming look like an alarmist, since we'll all be able to install Fedora and other major Linux distributions on Windows 8 boxes with little or no trouble, and more obscure distributions without Microsoft-signed boot loaders with very little more effort. If Microsoft changes their certification requirements in another couple of years and we cry "wolf" again at that time, we may be ignored because of the lack of any wolves this time around.

Nonsense. That wolf has already taken your left hand you are still confused, saying "what wolf ?".

MS has prohibited ARM hardware vendors from ever booting anything but Win software, and they've made it impractical to dual-boot Win8, thus making it very difficult for noobs to TRY another OS. There is a great deal of damage done already.

That's a very old post with outdated information. Both Garrett's first post on the topic and Mangefeste's response occurred before Microsoft added the requirement that users be able to disable Secure Boot or modify its settings to its certification requirements.

"Old" is not a valid rebuttal. AFAIK it is the only clear concise statement of policy from an MS employee. Yes one important exception ... disabling SB is a mandated feature for Win8 cert. So you believe that leaving MS in charge of whether HW can or can't boot with an unsigned kernel is reasonable and not major harm to OSS and even proprietary SW ?

, the $99 fee is a one-time fee that enables the purchaser to sign (or more precisely, to have signed) an unlimited number of binaries. (This is elaborated upon elsewhere, but I don't have references handy.) If you wanted to go this route, you could pay your $99 and sign hundreds of binaries from that one $99 payment.

Not quite, you have to be a Winqual member (requiring a license w/ MS) to get a signing key, you have to have a Verisign Class 3 Digital ID (Ka-Ching $$$). And the non-discount price isn't $99, it's $499 per year. http://www.symantec.com/verisign/code-signing/microsoft-authenticode/buy

To be certifiable (see the reqs) you likely need a Dun&Bradstreet listing. If you think that's a reasonable approach for someone developing a small distro - then you may as well put an MS collar and and leash on and call yourself "Gate's poodle". This crushes competition. A Young Linus could never dream of writing his own OS if this was mandated. It's awful.

That said, from what I've read it sounds as if the binary signing isn't instantaneous. If you're futzing around with kernels like this, you'd probably be better off disabling Secure Boot entirely.

No If the key creation method was public (maybe it will be but it's not defined in the EFI std) , then you could just create a your own unverifid keys ,install your key, and sign your own SW. Conceptually similar to self-signed certs.

Alternatively, you could sign a boot loader that you trust and that uses its own security system to authenticate kernels using whatever keys you create yourself. That's what Fedora's doing.

Here is Garrett's description of F18 secure boot "shim" plan, which he describes as the best among bad options ...
http://mjg59.dreamwidth.org/12368.html

This will do nothing other than load a real bootloader (grub 2), validate that it's signed with a Fedora signing key and then execute it. Using the Fedora signing key there means that we can build grub updates in our existing build infrastructure and sign them ourselves. The first stage bootloader should change very rarely, and we don't envisage updating it more than once per release cycle. It shouldn't be much of a burden on release management.

Great - so now you need to be able to sign grub2 with a Fedora key to rebuild and use it - how does this not violate GPLv3 ? The system is just as in accessible to software mods as any Tivo.

but also kernel reqs ...

Secure boot is built on the idea that all code that can touch the hardware directly is trusted, and any untrusted code must go through the trusted code. This can be circumvented if users can execute arbitrary code in the kernel. So, we'll be moving to requiring signed kernel modules and locking down certain aspects of kernel functionality. The most obvious example is that it won't be possible to access PCI regions directly from userspace, which means all graphics cards will need kernel drivers. Userspace modesetting will be a thing of the past. Again, disabling secure boot will disable these restrictions.

Yak, the kernel is signed and crippled. ! But they need to do that or else they'd lose their precious Winqual membership and get their cert pulled. In such ways slaves are made.

This fuster-cluck scheme has caused Fedora to create and distribute non-GPL(at least v3) binaries (hypocrisy much?) and cripple the kernel functionality, exclude 3rd party and non-kernel vid drivers. Brilliant ! But it's the only way to make the installation noob-friendly, and the only practical means of making for a dual boot system I think.

Ubuntu *seems* to have chosen a different approach of using SecureBoot with Ubuntu keys. So the user has to install a Ubuntu key beforehand. They don't use grub2 as they (rightly IMO) view the signature as violating GPLv3), so they'll have a non-FOSS bootloader, and a completely unrestricted ,unsigned kernel.
Their bootable CDs will use a Winqual signature, just like Fedora.

Fedora's approach is more noob friendly, but more user-restrictive than Ubuntu's. This all avoids the big question. Why are we allowing MS to hijack the PC boot ? That the Win8 cert currently gives us permission to disable certs is no more comfort than someone agreeing to not shoot you today.

Originally Posted by RupertPupkin

Heh, in a way that's actually worse. In fact, it's what some Linux users have been doing for years. When their predictions invariably don't come true, instead of admitting they were wrong they just move on to the next doom-and-gloom prediction. The Chicken Little mentality is strong in a certain segment of the Linux community, unfortunately.

What predictions ? I'm talking about MS taking advantage of their market-share and causing HW vendors to make things difficult for competition. That's TODAY- no prediction required. Guess you missed the point.