Ubuntu's Plans To Implement UEFI SecureBoot: No GRUB2

[crazycheese]

Interesting enough, it is not a requirement for the Ubuntu certification to have a disable Secure Boot switch.

Its not a bug, its a feature.

[AdamW]

Definition of monopoly:



Microsoft being the only valid key signer perfectly FITS the definition of monopoly.

So, instead RH, SUSE and Canonical getting together and SUING microsoft, they decide to swallow the crap that is thrown onto them???!

WTF!!!



How it should have been done:

Independent entry, that is signing for free, provided the payload passes its review. The costs for review should NOT be extraordinary, especially when the code is open-source.
That would solve EVERYTHING.

You can't just sue someone because 'they have a monopoly'. Doesn't work that way. What's illegal is *abusing* a monopoly.

Microsoft, as things stand, will have a monopoly on providing public signing services for Secure Boot. This is accurate. They won't have sought out that monopoly, or done anything illegal to get it - as has already been noted multiple times in this thread, they've done nothing at all to stop anyone else offering public signing services. The mere fact that a monopoly will exist will not be illegal. This situation is actually a neat illustration of why: it's possible to become a monopoly without doing anything really wrong, as in this case. It's only illegal if the entity which has the monopoly abuses it for anti-competitive purposes; nothing Microsoft has so far done in the Secure Boot case stands a remote chance of qualifying as monopoly abuse under the relevant statutes, AFAIK.

edit: you entirely missed all the other costs of running a certification authority, which are not insubstantial.

[AdamW]

"Booting our CDs will rely on a loader image signed by Microsoft's WinQual key, for much the same reasons as Fedora: it's a key that, realistically, more or less every off-the-shelf system is going to have,"


They are declaring themself as "off-the-shelf system".

This means they are not going for 1st class, but crap class.

With such attitude, Canonical is on sure way to hell!

I don't think your English comprehension is quite up to scratch. The reference to 'off-the-shelf system[s]' there is not talking about Ubuntu. It's talking about computers you can buy in the consumer marketplace. An 'off-the-shelf system' is the kind of computer a regular consumer is expected to buy - what you get if you walk into Best Buy and ask for a computer.

[AdamW]

First of all grub2 does not detect efi windows installs using os-prober. But i have got a tiny custom.cfg that would find em with grub 2.00. grub 1.99 is not optimal for that, but i dont know why there is not even an experimental debian package with 2.00. Basically you do not necessary need grub, you can use the integrated bootmanager in the setup, then you use just quick boot selection and start the os you like. You just dont get a menu all the time, only when you press the quick boot selection key.

How the EFI boot manager is presented is up to the discretion of the firmware UI designer, Kano, and it can vary considerably between systems - just FYI. Others may not behave as yours does.

mhenriday: in case you didn't quite get what Kano was saying, let me take a crack at it...

If we just consider Secure Boot *in itself* the easiest way to make sure it doesn't interfere with anything is just to turn it off. Most of what Kano explained is about a subtly different topic: not Secure Boot, but UEFI itself. The key point here is that booting a UEFI system is rather different from booting a BIOS system, particularly as regards multiboot. You don't multiboot UEFI-native OSes the way you multiboot BIOS-native OSes.

BIOS is pretty dumb as regards booting the system - really all it can do is pick a device and fire up whatever it finds in the MBR. That's it. This is why we have complex bootloaders like grub capable of booting multiple operating systems. One way to look at what UEFI does is to say that it moves a lot of that complexity into the firmware. Instead of there being a bootloader in 'userspace' which presents a list of operating systems, that gets offloaded to the system firmware. This is the 'EFI boot manager' we're talking about. Basically, how it's meant to work with UEFI is that you install an operating system and the OS registers itself with the firmware; it adds an entry to the EFI boot manager. The entry has a name - that's what you see in the list of options at boot time, however your particular system's firmware presents it - and it points to a partition and a path (by spec, within the EFI system partition) where that OS's second-stage bootloader can be found. These second-stage bootloaders are meant to be unique to each OS - they're not complex clever beasts which can load multiple OSes.

Speaking personally I actually really like this approach as, properly implemented, it'll make it a hell of a lot easier for both users and OS devs to handle multibooting. The firmware is exactly the right place for multiboot to get done. The BIOS approach is horrible to deal with, as it's very difficult for every OS to understand exactly how each system is supposed to get booted and keep all the configurations in sync, there's a huge range of complexity when there can be a bootloader on every MBR which does something different, and other bootloaders on root or /boot partitions which get chainloaded from the MBR bootloaders and do different things again...it's just a nightmare to try and deal with.

Going back to Secure Boot - given the way UEFI itself works, the question of how it 'interferes' with multiboot looks a bit different, I guess you'd agree. AIUI, if all the OSes you want to multiboot are signed with one of the keys approved by your firmware, then they'll multiboot just fine.

[Kristian Joensen]

So UEFI does a way with the whole "A fresh Windows install overwrites the MBR" issue? No more need for fixing/repairing the MBR? The order you install your multi-boot OSes doesn't matter any more?

[AdamW]

Kristian: As long as both the firmware and OS implementations are sensible, yes.

[Kano]

@Kristian Joensen

Pure UEFI works like that: Windows installs a fallback bootloader (which is mainly used on removeable devices) in the efi (fat) partition as efi\boot\bootx64.efi. In theory you could do that with a copy of grubx64.efi as well. The nvram where the info is stored is inside the "bios" chip. So only when you replace it, it's content gets currupt (very dangerous, especially on laptops) or when you exchange the motherboard the installed system will not boot until you add a new entry or use efishell to start the efi binary manually (you can use the standard position on removeable media or the name shellx64.efi if you have to a setup entry to launch efishell. What you should never do is to use "-B" option with efibootmgr with entries which are created by the firmware itself. Some systems might work still, but can cause problems later (which happened with my asus z68 board). In that case the system will not even run POST successfully. Very bad when this happens on a laptop where it is so easy to exchange the chip The cmos clear jumper is completely useless when a system can not POST because the functionality looks like a software solution in case of the clock is wrong.

You can boot mbr hds at any system usually, but not ones without fallback loader - which still require uefi. You might want to try a hybrid mbr to boot syslinux and then DUET, which will store "nvram" on hd and works with a legacy bios, but did not try it.

http://www.rodsbooks.com/bios2uefi/

[blackiwid]

I don't think your English comprehension is quite up to scratch. The reference to 'off-the-shelf system[s]' there is not talking about Ubuntu. It's talking about computers you can buy in the consumer marketplace. An 'off-the-shelf system' is the kind of computer a regular consumer is expected to buy - what you get if you walk into Best Buy and ask for a computer.

do I get here the wrong point or do you mean that ubuntu-pcs dont get sold by discounters? or are not good enough for the regular consumer? they even installed some totaly crap linux-distributions on the first netbooks. that was sold to regular people so they even thought that a really bad linux-distribution is good enough for the regular consumer. the only reason they backed out here was because microsoft said, ok we give to laptops also a completly free (5,- Dollars = free) else that would be the point were linux would have become a big player on the desktop market...

But thats another story... point is if you say the discounterpcs could never be a ubuntu pc you are wrong... but maybe I misunderstood you?

[AdamW]

do I get here the wrong point or do you mean that ubuntu-pcs dont get sold by discounters? or are not good enough for the regular consumer? they even installed some totaly crap linux-distributions on the first netbooks. that was sold to regular people so they even thought that a really bad linux-distribution is good enough for the regular consumer. the only reason they backed out here was because microsoft said, ok we give to laptops also a completly free (5,- Dollars = free) else that would be the point were linux would have become a big player on the desktop market...

But thats another story... point is if you say the discounterpcs could never be a ubuntu pc you are wrong... but maybe I misunderstood you?

Wow, you seem insistent on confusing the issue as much as possible.

Let's just go back to the original context, shall we? Someone from Canonical said:

"Booting our CDs will rely on a loader image signed by Microsoft's WinQual key, for much the same reasons as Fedora: it's a key that, realistically, more or less every off-the-shelf system is going to have"

It means exactly what it says. They will have their general-release images signed with the Microsoft key, just like Fedora is going to, for the same reason: because it's a key that, in practice, you can expect to be on any typical consumer-bought computer.

You may be confused because Canonical have actually described _two_ approaches to the Secure Boot issue, which is appropriate for them. Systems pre-loaded with Ubuntu, via an official OEM relationship with Canonical, will have a Canonical key loaded into their firmware, and the Ubuntu that comes pre-installed will be signed with that key. The quote above relates to Canonical's _other_ approach, which is what they'll do for the Ubuntu images you can download for free off the internet, for installation on any old PC you have lying around (which, most likely, shipped with Windows). Those images will be signed with Microsoft's key, not Canonical's, because it's vastly more likely that the systems people want to install them on will have Microsoft's key. In practice, just about all PCs will have Microsoft's key. That's what the quote says.

[Kano]

And what do you think about the idea just to sign the bootloader? Is there any reason why nobody else should use the same bootloader to boot custom code?