Gummiboot restructured to allow Linux to work on SecureBoot systems

[Edvard]

Dammit... now I have to deal with yet another bootloader.  Hadn't even heard of Gummiboot until I saw this.  Damn UEFI, damn it all to hell!

The Linux Foundation is waiting for Microsoft to sign the newly submitted bootloader version and will offer the new version to users for free once released.
...
According to Bottomley's presentation slides, it takes a week or two for Microsoft to respond to bootloader submissions and provide a signature that is considered trustworthy by Secure Boot PCs.

http://www.efytimes.com/e1/fullnews.asp?edid=99636
http://www.h-online.com/open/news/item/Linux-Foundation-s-Secure-Boot-bootloader-restructured-1796276.html

As a side note, Microsoft being the de facto keymaster to UEFI/Secureboot implementations is just mind-fecking boggling.

from an email

[40hz]

Microsoft to sign the newly submitted bootloader version and will offer the new version to users for free once released.
...
According to Bottomley's presentation slides, it takes a week or two for Microsoft to respond to bootloader submissions and provide a signature that is considered trustworthy by Secure Boot PCs.
...

As a side note, Microsoft being the de facto keymaster to UEFI/Secureboot implementations is just mind-fecking boggling.

Oh, it gets better. This from Heise Online's H-Open webpage: (full article here)

Booting Linux using UEFI can brick Samsung laptops

Linux and Bricks Booting Linux using UEFI just once on various Samsung laptops is enough to permanently stop them working. Several reports have been posted on the Ubuntu bug tracker, but the problem is likely to also be present in other Linux distributions, as it appears to be caused by a kernel driver for Samsung laptops. Kernel developers are currently discussing a change which would disable the driver when booting via UEFI.

Ubuntu developers were informed of the problem by one user last year, after he had tried to UEFI boot Ubuntu 12.04 or 12.04.1 on a Samsung 530U3C live from a USB flash drive. He had prepared the drive with Ubuntu's Startup Disk Creator, which sets everything up for booting via BIOS or EFI. Ubuntu froze shortly after loading the kernel and the user then powered down by holding down the power button. Thereafter the laptop refused to boot and the firmware would not even show basic startup information. Samsung repaired the laptop, which was under warranty, by replacing the motherboard. When the same thing occurred with the repaired machine, the user alerted the Ubuntu development team.

Since then, many more users have reported having bricked their laptops by trying to boot Linux. The problem also appears to affect Ubuntu 12.10 and other Samsung models. The Ubuntu bug report includes posts from users reporting that the problem also affects 300E5C, NP700Z5C, NP700Z7C and NP900X4C series laptops. It does, however, only occur when Linux is booted using UEFI. It does not appear to matter whether Secure Boot is on or off. The problem can be circumvented by booting Linux using the Compatibility Support Module (CSM). UEFI firmware on many recent systems includes a CSM to enable operating systems to be booted in the same way as on computers with conventional BIOS firmware. Installing Linux alongside a Windows installation installed using UEFI mode is, however, not straightforward when booting using CSM.

The Ubuntu development team has held talks with Samsung staff, who have identified the kernel's samsung-laptop driver as the prime suspect...

Um...weren't we previously assured by Microsoft that a situation like this couldn't possibly happen with a UEFI/SecureBoot-capable machine?

[Renegade]

+1 for all the comments above. Sigh... 

[Tinman57]

  And they had to replace the whole motherboard just because of this!!!!  Holy Mother Mary!!!  Now if MS is the one that's in charge of the boot loader, well......we can already see what's happening.
  But this is just yet another reason why I'm dumping Windows for Linux and keeping XP as my secondary boot.....  And if I can't replace this MB in the future, there are other ways around installing XP WITHOUT MS's permission.  Yeah, you read that right.... 

[40hz]

From the Dude! Read the Handwriting on the Wall Dept:

Intel will get out of the traditional desktop motherboard business, as it focuses its resources on mobile products.

"We disclosed internally today that Intel's Desktop Motherboard Business will begin slowly ramping down over the course of the next three years," Intel said in a note to journalists today.

What does that mean exactly? Think of the PC tower systems that used to populate the Best Buys of the world. That's what Intel is winding down as it devotes more resources to ultrabooks, tablets, and phones.

"The internal talent and experience of twenty years in the boards business...is being redistributed to address emerging new form factors," Intel said.

Those designs will be mostly mobile, though Intel will also address "emerging" desktop designs. But even those -- like the tiny Intel NUC board and the all-in-one -- have their roots in the mobile world.

The end of development will come with Intel's upcoming "Haswell" chip generation, due to launch in the summer. "Intel will stop developing new Desktop boards once Haswell launch is completed," the company said.

Full article here.

While this certainly won't "kill off" the desktop/tower PC overnight, the simple fact that behemouth Intel (provider of the de facto reference boards for all its new CPUs and chipsets) intends to quit the field sends a pretty clear indication of where the PC platform is being driven.

As time goes on, expect to see more closed and non-modifiable "appliance type" computers and mainboards, while the traditional "open PC hardware architecture" becomes increasingly marginalized.

Yes, the times they are a-changin'

[Edvard]

@40Hz: RE: bricking Samsung laptops: read deeper:

The Ubuntu development team has held talks with Samsung staff, who have identified the kernel's samsung-laptop driver as the prime suspect...

That said, it still wouldn't have happened without the UEFI silliness.  I mean really, if UEFI actually offered a quantum step forward in functionality, I could live with the glitches until support matured, but I haven't seen anything really groundbreaking except giving Microsoft keys to the door they've always wanted.  
Another thing to consider is this really only affects dual-boot environments, because if you can simply shop around for a UEFI chip that allows turning off SecureBoot, my Linux-only box is going to be just fine.  But I have a few questions:
1- If SecureBoot is simply an option that needs to be turned on for OEM's that want to build systems that are Windows 8 certified, that doesn't mean installing Windows 8 will require SecureBoot to be turned on in order to boot, right?
2- How will Hypervisor+VM setups be affected?  That's how pretty much any big web/cloud service is running right now, and it would not make any financial sense to lock them out, whether it is Xen, VMware ESXi, or MS Hyper-V.
Also, I wonder how hard it would be to replace UEFI/SecureBoot with TianoCore/Coreboot.  That would be sweet.

[Carol Haynes]

Intel will get out of the traditional desktop motherboard business

If AMD have any sense they will clean up.

Actually if Intel and AMD (and other major manufacturers) simply refused to produce UEFI motherboards that give MS the key to the lock, or even go back to standard BIOS board production only,  it would force MS to respond, especially now Windows 8 is in the wild and can't be installed on SecureBoot systems without a valid key. If MS play hardball it will be sales of Win 8 that will suffer.

Seriously where are the class action law suits in all this? The EU caused problems for MS because IE and WMP were included in Windows, this is far worse as it effectively removes competitors from selling product at all!

[40hz]

Intel will get out of the traditional desktop motherboard business

If AMD have any sense they will clean up.

AMD is experiencing its own financial problems lately. Sales are off 25%. Don't expect them to rock the boat.

Actually if Intel and AMD (and other major manufacturers) simply refused to produce UEFI motherboards that give MS the key to the lock, or even go back to standard BIOS board production only,  it would force MS to respond, especially now Windows 8 is in the wild and can't be installed on SecureBoot systems without a valid key. If MS play hardball it will be sales of Win 8 that will suffer.

True - but "so not gonna happen" as my niece would say. Both Intel and AMD are hoping Windows 8 will be a big win and spark a buying spree. Neither can hurt Microsoft without hurting themselves. Expect no backbone from those two.

Seriously where are the class action law suits in all this? The EU caused problems for MS because IE and WMP were included in Windows, this is far worse as it effectively removes competitors from selling product at all!

Microsoft has a loophole in that incorporating UEFI is (technically) left up to the hardware manufacturers. Exactly how "voluntary" it is in practice is another matter - and one that will need a court ruling to finally decide. But thats something that can (and likely will) be dragged out for decades if it ever comes to that.

But even more to the point, most governments and industry regulatory bodies have now become aware of just how powerful an open hardware platform is. And how potentially threatening it can be to the powers that be - as Anonymous, Pirate Bay, and Wikileaks have repeatedly demonstrated.

Wanting more control over the hardware (and lacking the constitutional authority to get it) I see a trend by most governments to look the other way at anything that tries to rein in computer users.

Lack of safeguards to privacy, warrantless 'fishing expeditions' courtesy of bullied ISPs and database owners, kiddie-porn hysteria campaigns, allowing ridiculous IP lawsuits, granting equally ludicrous patents, allowing ongoing abuse of copyright laws and DMCA takedown notices...

No...I don't expect to see much relief from government on this score.

Back in the Regan Error Era, political and business interests discovered you could much more easily advance your agenda by the selective enforcement of laws. Ronald Regan was a master at pressuring the U.S. Justice Department not to enforce any laws his administration disagreed with.

And I worked out quite well for him and his cronies.

I think you'll see the same thing happen here. And I don't think the EU will be above it.

[Carol Haynes]

Microsoft has a loophole in that incorporating UEFI is (technically) left up to the hardware manufacturers. Exactly how "voluntary" it is in practice is another matter - and one that will need a court ruling to finally decide. But thats something that can (and likely will) be dragged out for decades if it ever comes to that.

Not strictly true - anyone OEM wanting to ship Windows 8 has to use a system with SecureBoot enabled. It is part of the OEM agreement - unless it has changed recently?

[40hz]

^Gets tricky. They need (last I heard) to have it enabled. But it's supposedly up to the manufacturer how (or if) it can be turned off.

Windows 8 doesn't require it. At least not yet. I have copies of Win 8 running in non-UEFI PCs. So it's not like it won't run if it doesn't see UEFI.

The big question is what Win8  will do if it does. Because if that means having to go into the hardware settings and turn SB off in order to boot Linux - and then back in to turn it on in order to boot Win 8 - then that extra annoyance will effectively eliminate the incentive to dual-boot for most people.

And if the big manufacturers decide not to allow you to disable SecureBoot (as a condition of purchase) then it's pretty much over for Linux unless it dances to Microsofts's tune - as Redhat and some other sellout distros have indicated they're all to willing to do.

Slippery slope...

[40hz]

That said, it still wouldn't have happened without the UEFI silliness.

Not to disregard your other points (which are valid), but I still think the above really says all that has to be said.

It isn't going to do what it intends to do. It will be quickly circumvented for nefarious purposes by malware.

So why bother other than to inconvenience users and obstruct legitimate alternatives?

The problem with things like this is that they only hurt those who genuinely do play by the rules. Much like locked doors mostly only stop honest people.

[f0dder]

40hz: wrt. the bricking, shouldn't you blame Samsung? Or blame the linux kernel driver developer? I can fry my BIOS/UEFI by flashing it with garbage, who should I blame for that? :-). Also, considering Microsoft already signed the Shim that will allow you to boot anything, could we cut down the paranoia level to "on the watch, and not liking things"?

Tinman57: you don't need any "permission" to install XP, you simply disable Secure Boot... which you kinda have to, anyway, since XP doesn't support UEFI boots.

Edvard: there's no such thing as an "UEFI chip" - it's a software implementation (possibly using a TPM chip, but that's a different matter). As things currently are, x86 vendors are required to allow the user to disable Secure Boot to get Win8 logo certification... and motherboards (as opposed to prebuilt systems) tend to come with full-blown key management facilities.

Carol: is AMD still in the motherboard game? I thought they quit both motherboards and chipsets several years ago?

EDIT: turns out it's almost guaranteed to be an UEFI bug, so strikeout'ed the Linux kernel devs part

[Carol Haynes]

Carol[/b]: is AMD still in the motherboard game? I thought they quit both motherboards and chipsets several years ago?

My system (less than a year old) has a 990 chipset from AMD ?? OK it isn't an AMD mobo but the CPU and chipset are both by AMD.

[40hz]

40hz: wrt. the bricking, shouldn't you blame Samsung?

I do. Their device = their responsibility. If they supposedly understood how to implement UEFI, it shouldn't have happened. If UEFI weren't there...it wouldn't have happened.

Or blame the linux kernel driver developer?

Nope. Cardinal rule of the kernal team is: you do not ever break userland. The changes that resulted in the bricking were not made by them. I put the responsibility squarely on the manufacturer's shoulders.

Microsoft already signed the Shim that will allow you to boot anything

News to me. Hadn't seen that they had. If so, I'm a much happier camper. Could you post a link?

Also, thanks for the jab about paranoia levels. Much appreciated. Especially since I'm not. And I think most of us here are savvy enough not to indulge in that sort of nonsense.

But by the same token, Microsoft has a long and documented track record of breaking agreements and engaging in exceedingly aggressive and willfully deceptive business practices. Whenever they think they can get away with something, more often than not, they'll try to do so.

Is knowing that about them being paranoid, cynical - or simply realistic?

[f0dder]

Or blame the linux kernel driver developer?

Nope. Cardinal rule of the kernal team is: you do not ever break userland. The changes that resulted in the bricking were not made by them. I put the responsibility squarely on the manufacturer's shoulders.

Well, I haven't dug into the issue, but the H-Online article says "[...]it appears to be caused by a kernel driver for Samsung laptops." - I take it that "kernel" means "Linux kernel", otherwise it should've been "firmware driver" or "UEFI driver". Also, firmware isn't exactly userland

So it could be Samsung that implemented something screwy, or it could be the kernel drivers that misundestood the UEFI specs (or simply had bugs in their code), or it could be a combination of the two. Stuff like that reaaaaaally shouldn't happen, but when you're writing ring0 code, bugs can have pretty fatal consequences.

Microsoft already signed the Shim that will allow you to boot anything

News to me. Hadn't seen that they had. If so, I'm a much happier camper. Could you post a link?

Sure, here you go

Also, while I haven't looked at Secure Boot enabled laptops, my impression is that the motherboards you can get for building your own boxen tend not only to allow you to disable Secure Boot, but allow full key management. It's understandable that Linux distros don't want to depend on this, since it signigicantly raises the difficulty of installing, and it might not be available everywhere - hence the signing pact with the devil.

But by the same token, Microsoft has a long and documented track record of breaking agreements and engaging in exceedingly aggressive and willfully deceptive business practices. Whenever they think they can get away with something, more often than not, they'll try to do so.

Is knowing that about them being paranoid, cynical - or simply realistic?

A mix of all three, I'd say - hence why I think we should be on the watch, and remain skeptic. But it helps noone to spread FUD, which some people are doing (not pointing fingers here at DoCo, but there's craploads of incorrect (dis)information out there on the interwebs).

[40hz]

@f0dder -thx for the link. I knew about that one. But AFAIK Microsoft nothing to do with it. And it is a very inelegant hack at best.

What most of us were hoping was that any computer owner could elect to permanently disable UEFI/SecureBoot and still have Windows 8 function the same way it does on a non-UEFI machine. That would allow users who wish to dual-boot (or simply not use WIndows at all) to sidestep this entire issue and continue working as they did before.

Since Microsoft insists UEFI is not a requirement of Windows per se, but rather a whole separate initiative, I still don't see why any of this should be so difficult or require so much discussion.

Why can't they make it a simple setup option to use - or not use - and let it go at that?

It shouldn't take to much by way of logical deduction to come up with the reason why UEFI is being made an issue - or who is mostly responsible for it becoming one.

I can turn off and manipulate and a host of other powerful features (including overclocked settings which could easily destroy my CPU) in my current BIOS - and still not have an issue with any operating system installing or loading.

Why do I have to have that problem now if I prefer not to?

[attachthumb=#]

[f0dder]

@f0dder -thx for the link. I knew about that one. But AFAIK Microsoft nothing to do with it. And it is a very inelegant hack at best.

It's signed by Microsoft. The $99 mentioned in that reply doesn't go to Microsoft (it's for the code signing certificate, and it's my understanding that cash goes to Verisign, not MS).

I also don't see how the shim is an inelegant hack. I haven't tested it, so I might have misunderstood how it works, but it's my understand that the first time you boot with it, you have to do the somewhat kludgy key enrollment process (which, AFAIU, only enrolls the key with the shim, not the UEFI keystore) - after that, you can autoboot Grub (or whatever you've chosen). That's the standard pre-compiled shim - a linux distribution that's willing to shell out the $99 for a signing cert can build a version that has their own key embedded, and thus avoid the first-time kludge.

What most of us were hoping was that any computer owner could elect to permanently disable UEFI/SecureBoot and still have Windows 8 function the same way it does on a non-UEFI machine. That would allow users who wish to dual-boot (or simply not use WIndows at all) to sidestep this entire issue and continue working as they did before.

Dunno if there's anything in Win8 that (currently!) doesn't work if Secure Boot is disabled - one could expect potential DRM nastyness. But as long as UEFI implementations allow you to do your own key management, and there's alternate solutions like the Shim loader, there's no need to panic.

I really do believe that Secure Boot isn't necessarily a bad idea in and by itself - it does offer an additional level of protection against resilient malware. It might be broken, we'll see about that (given how complex a beast UEFI is, there'll probably be a way), but it's going to be one additional barrier that an attacker has to penetrate.

Heck, I even think it's possible that the engineers that came up with the idea actually did have security in mind.

On the other hand, I am cynical enough to know that there's bound to be a lot of slimey creeps in MS that are waiting for the right opportunity to use it for ultimate vendor lock-in... so I am weary & wary about the whole thing. But I'll still rather keep my eyes open and discuss things rationally and wait a bit before I cry wolf.

[Edvard]

Edvard[/b]: there's no such thing as an "UEFI chip" - it's a software implementation (possibly using a TPM chip, but that's a different matter). As things currently are, x86 vendors are required to allow the user to disable Secure Boot to get Win8 logo certification... and motherboards (as opposed to prebuilt systems) tend to come with full-blown key management facilities.

Ah, thanks for clearing that up.  I had assumed that since UEFI was a replacement for BIOS, it was a similar implementation, and I saw NOTHING in all my random web surfing research that suggested anything else.
I'd also prefer to be on the watchful side, and not the omg-teh-sky-is-falling side. 

But while we're on the subject, if UEFI is a software thing, can it be replaced with something less nefarious?  My mention of TianoCore/Coreboot was the only things I could find that was insinuated as any sort of a replacement.

Also, still waiting to see if Gummiboot comes back with a signature...

[f0dder]

Ah, thanks for clearing that up.  I had assumed that since UEFI was a replacement for BIOS, it was a similar implementation, and I saw NOTHING in all my random web surfing research that suggested anything else.

BIOS is software as well

I'm honestly a bit fuzzy on BIOS vs. UEFI, but... my understanding is something along the lines of this:
1) you have some really core code that does initial CPU and chipset setup, and you have the menu configuration stuff ("BIOS menu") - neither of this really has to be "BIOS vs. UEFI" (although on an UEFI system the menu config might be an "UEFI shell"? - haven't studied it closely enough!).
2) then there's the boot stuff, and this is where changes are radical. "Legacy BIOS" and UEFI boots are very different in nature (even for UEFI without Secure Boot). Both with regards to how additional boot code is loaded, but also the services the firmware exposes. BIOS exposes old 16bit code with a whole lot of legacy that no modern OSes use. UEFI is proper protected-mode APIs.

Any system that supports "legacy boot" in effect has a full BIOS.

UEFI in and by itself isn't a bad thing, it's good to get rid of some of the legacy junk - and boy do UEFI systems boot fast (not sure if this would be possible with a normal BIOS-only system... I still legacy-boot my Win7, but on an UEFI capable system, and this is very fast as well). UEFI is probably a bit over-engineered and bloated, and Apple have had some quirks that almost smell like intentional harassment.

But while we're on the subject, if UEFI is a software thing, can it be replaced with something less nefarious?  My mention of TianoCore/Coreboot was the only things I could find that was insinuated as any sort of a replacement.

Theoretically, yes - problem is that motherboard vendors only ship a full package with the CPU+chipset initialization, config menu and BIOS/UEFI booting, they don't ship just initialization + config menu. This means that any alternative project needs to implement every from scratch, and goot luck getting your hands on detailed chipset specifications.

[40hz]

Be interesting to see what happens with all this on Dell machines now that the company has gone private. Microsoft is in on this deal to the tune of a $2 billion loan. Wonder if there will be a quid pro quo to help Microsoft sort out this problem.

[Tinman57]

Tinman57: you don't need any "permission" to install XP, you simply disable Secure Boot... which you kinda have to, anyway, since XP doesn't support UEFI boots.

  XP has to "Phone Home" to "Get Permission" from MS to work, otherwise it goes into a reduced function that won't allow you to use the entire OS.  Kind of like a "Safe Mode".  If you have the XP upgrade OS like I do, you can ONLY use it on this motherboard.  If I was to change out the motherboard, MS would NOT give the OS permission to operate at it's full capacity.

  HOWEVER, I do have some "Workarounds" for this problem if I should need it in the future.....

[Edvard]

BIOS is software as well

D'oh!!  >_< ... I knew that, it just didn't come out right, let me clarify.  I mean formerly, it was possible to re-flash your BIOS chip with replacement BIOS software, say, Coreboot as long as your board was supported.  So I guess my question really is, can the chip the UEFI software resides on be flashed, so as to POSSIBLY bypass a UEFI that does not allow turning SecureBoot off, or as a bonus, utilize the benefits of UEFI while not needing Microsoft-signed keys to get around SecureBoot?  
You answered that one:

Theoretically, yes - problem is that motherboard vendors only ship a full package with the CPU+chipset initialization, config menu and BIOS/UEFI booting, they don't ship just initialization + config menu. This means that any alternative project needs to implement every from scratch, and goot luck getting your hands on detailed chipset specifications.

Apparently TianoCore is a direct attempt at doing this very thing, but the code and implementation is still in very early development.  Here's hoping for more advancement on that front...

UEFI is probably a bit over-engineered and bloated, and Apple have had some quirks that almost smell like intentional harassment.

Ya think? Or maybe just...

Oh, yes, despite E820 being an x86 BIOS-specific thing, we use it for the in-kernel representation of the address map under EFI as well. So despite the EFI memory map being available to the kernel, the bootloader has to construct something that looks like an E820 map, losing information in the process. So even though it's been given the E820 map, the kernel has to look through the EFI memory map in order to find the EFI runtime services section in order to mark it executable. This is, arguably, insane, but so is the entirety of EFI so that's ok then.

[f0dder]

So I guess my question really is, can the chip the UEFI software resides on be flashed, so as to POSSIBLY bypass a UEFI that does not allow turning SecureBoot off, or as a bonus, utilize the benefits of UEFI while not needing Microsoft-signed keys to get around SecureBoot?

Dunno if the UEFI standard says anything about where the code resides etc., but it'd be weird if it wasn't in flash-rom; after all, it "might need upgrading". The systems I've seen have had normal flash-rom.

Of course flashing could be locked down to require updates to be cryptographically signed, but we're not there yet. However, it's probably almost defacto impossible to flash something else due to the level of complexity of modern systems, and the vendors not being keen on releasing full chipset specs. (I havent' followed tianocore or coreboot/linuxbios, but was under the impression hardware support is relatively thin?).

Oh, btw, there are some systems where parts of firmware aren't stored in flash-rom but a harddisk partitions or the like. Mostly non-x86 systems I guess, haven't really come upon them myself. But iirc there's also been a few x86 vendors doing this in the dark & dirty past - perhaps Olivetti or COMPAQ? Dead harddrive, good luck getting that machine booting again.

Ya think? Or maybe just...
*snip*
This is, arguably, insane, but so is the entirety of EFI so that's ok then.

Big grin - if I understood that part correctly, though, it was a rant on the Linux kernel (using BIOS-specific E820 memory map as runtime rather than boottime data structure)?

Don't know enough about UEFI to comment on whether it's "insane", but it is big-corporation committee work, so... *rolleyes*. Idea of replacing BIOS with something more modern was good, though.

[f0dder]

40hz: wrt. the bricking, shouldn't you blame Samsung? Or blame the linux kernel driver developer? I can fry my BIOS/UEFI by flashing it with garbage, who should I blame for that? :-)

Right, there's more information on the bug, seems like it's a (Samsung) UEFI firmware bug - so no blame on the Linux kernel developers