Results 1 to 10 of 71

Thread: The UEFI SecureBoot Saga For Linux Continues

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,373

    Default The UEFI SecureBoot Saga For Linux Continues

    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

  2. #2
    Join Date
    Mar 2011
    Posts
    209

    Default

    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?
    Last edited by M1kkko; 05-31-2012 at 06:28 PM. Reason: not everything is black and white

  3. #3
    Join Date
    Feb 2009
    Posts
    26

    Default

    Quote Originally Posted by M1kkko View Post
    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.
    Last edited by smani; 05-31-2012 at 06:40 PM.

  4. #4
    Join Date
    Aug 2007
    Posts
    6,607

    Default

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

  5. #5
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by Kano View Post
    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.

  6. #6
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by smani View Post
    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
    Last edited by crazycheese; 05-31-2012 at 08:04 PM.

  7. #7
    Join Date
    Aug 2009
    Location
    Albuquerque NM USA
    Posts
    42

    Default 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?
    Last edited by Zapitron; 05-31-2012 at 09:39 PM.

  8. #8
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    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,

  9. #9
    Join Date
    Sep 2010
    Posts
    229

    Default

    Quote Originally Posted by crazycheese View Post
    The best security ever at boot stage has already been invented several decades ago, it was called BIOS MBR protection.
    The BIOS can't protect Windows or linux applications from writing to the MBR, because they don't use the BIOS to do disk I/O.

    It worked to protect against (most) DOS malware though...

  10. #10
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by JanC View Post
    The BIOS can't protect Windows or linux applications from writing to the MBR, because they don't use the BIOS to do disk I/O.

    It worked to protect against (most) DOS malware though...
    When you reboot hardware, who is called? It is very well possible to implement. Of course, "real-time" protection won't work anymore, but just comparing CRC and restoring on failure is sufficient enough.

    The thing that they are doing here is a lot bigger however - they are trying to create semi-HDCP, but for all middleware level. And because they are not giving users the control and understanding, that means they want to decide what is to be allowed all by themselves (corporations).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •