The UEFI SecureBoot Saga For Linux Continues

[phoronix]

Phoronix: The UEFI SecureBoot Saga For Linux Continues

The UEFI SecureBoot saga for Linux continues with another update by Matthew Garrett of Red Hat...

http://www.phoronix.com/vr.php?view=MTExMTI

[M1kkko]

Interesting news, but.. does this mean Ubuntu will be able to benefit from this as well?

Or will they have to pay another 99 bucks?

[smani]

Interesting news, but.. does this mean Ubuntu will be able to benefit from this as well?

Or will they have to pay another 99 bucks?

They will need to have their own signed first-stage boot loader, if they choose such an approach. Red Hat cannot share the keys it obtained from the signing service, since the whole security of secure boot relies on the private keys being kept secret.

[Kano]

For me that sounds like complete bullshit. If you can sign any bootloader for just 99$ then you don't need secure boot. And when you only use it for a stub loader it is even more fun, because that loader must have got the ability to chainload an efi binary. If you call that binary grub.efi or whatever it does not matter, but what cool checks do you want to implement there? do you want to embed your own key to your chainloader that you verify against your efi bootloader? then you need that key to build your binary, which will be available somewhere, so somehow anybody could use it which access to it. If you can get a signed bootloader for arm why would you enforce it the first time? If you can get it for x86 you could just disable it as well as you gain absolutely nothing. You would not only need to sign binary modules, you would need to sign the initrd - thats the main attack vector against encrypted systems as this is usually stored unencrypted. But as initrds are generated dynamically do you want to sign em then within your own system, well thats also weird...

[Qaridarium]

For me that sounds like complete bullshit. If you can sign any bootloader for just 99$ then you don't need secure boot. And when you only use it for a stub loader it is even more fun, because that loader must have got the ability to chainload an efi binary. If you call that binary grub.efi or whatever it does not matter, but what cool checks do you want to implement there? do you want to embed your own key to your chainloader that you verify against your efi bootloader? then you need that key to build your binary, which will be available somewhere, so somehow anybody could use it which access to it. If you can get a signed bootloader for arm why would you enforce it the first time? If you can get it for x86 you could just disable it as well as you gain absolutely nothing. You would not only need to sign binary modules, you would need to sign the initrd - thats the main attack vector against encrypted systems as this is usually stored unencrypted. But as initrds are generated dynamically do you want to sign em then within your own system, well thats also weird...

is kanotix death or do you pay the 100dollar bill ?

i think the clue is they will manage it to make as hard as possible to use the option for non secureboot boot options.

[crazycheese]

They will need to have their own signed first-stage boot loader, if they choose such an approach. Red Hat cannot share the keys it obtained from the signing service, since the whole security of secure boot relies on the private keys being kept secret.

Of course they can! And of course they will! Which security are you talking about? The best security ever at boot stage has already been invented several decades ago, it was called BIOS MBR protection.All this retarded UEFI "security" is centered around single thing - allow only microsoft to boot, and so cause even more trouble to people who want to try other OSes.

Companies should really stop ass-l1cking microsofties and thing twice what they are doing!

BTW this "happiness" was brought to you by Intel

[Zapitron]

What are Red Hat's customers asking them for?

The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot.

Garrett's been saying stuff like this for months, and every time he does, I keep wondering what he's smoking. But maybe it all depends on what the goal is.

Isn't the goal to de-brick EFI machines? You know, so that a Red Hat customer can buy whatever commodity hardware is most ubiquitous, which in tern will refuse to boot unsigned code, and still somehow be able to run Red Hat Linux on it? Isn't that why you're doing this, Garrett?

If so, then nobody gives a damn whether or not loadable modules "defeat the point of secure boot" because the goal of the project is to defeat the point of secure boot, so that computer owners can run whatever code they wish to. And in the case of Red Hat customers, that code is Red Hat's product, hence Red Hat's motivation for doing this. They want to tell customers, "Yes, we have code that you'll be able to run, so give us money."

If that's not the goal -- if the goal is to actually drink the secure boot koolaide, because Red Hat's customers want secure boot, not simply because the hardware they (will be able to) get most easily get requires it, but because those people think it's a good idea to not have final authority on what code their own computers run -- then it all makes sense. But are Red Hat's customers really thinking that way? I don't believe it.

What am I missing?

[Qaridarium]

maybe the UEFI crap will kill the closed source drivers from AMD and nvidia?

i hope the kernel Developers stay hard at this point then the big lose with the name UEFI is a little win for opensource,

[agd5f]

secureboot is coming whether you like it or not. You may be able to disable secureboot in the bios, but every bios vendor will implement it differently and some may forget to implement it at all. How do you tell a new Linux user that they have to hit F11 or maybe Delete or maybe F2 during the first few seconds of boot and then wade through a bunch of bios menus to disable a feature called _secure_ boot (let that sink in) just so they can try out this new Linux thing. Kind of a high bar. Realistically you need to support secureboot if you want your OS to be accessible to a wide audience.

[diriel]

Just Ughhh

I am looking into the Coreboot avenue. I believe Google has a couple boards, maybe those can be bought. This honestly just sounds like a mess that I would prefer to avoid. I can see it now, "Hey man my puter wont work, please come fix it ... say 20 minutes ago ok?" /sigh I am the family "IT" guy. Maybe I am just being jumpy.

Can't we all just agree to Say No!?