Announcement

Collapse
No announcement yet.

The UEFI SecureBoot Saga For Linux Continues

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Larian
    replied
    Isn't this anti-competitive?

    Okay, the idea behind UEFI is great and all, but I fail to see how this isn't taking advantage of a monopoly to enforce anti-competitive behavior. It's not that much different from their bundling of Internet Explorer to stifle competition in the browser market - just slightly more shitty. The $99 license fee takes the cake.

    Leave a comment:


  • uid313
    replied
    Thoughts

    Does a package need to be signed at a price of $99 once, or does it need to be re-signed at a price of $99 every time there is a new bugfix release?

    This maybe will work for big players like Red Hat, Novell, etc.
    But what about small hobbyist projects by students?

    Is it only the initial bootloader that needs to be signed, or is it the kernel, and other stuff too?
    $99 * X = $$$$$$$$$

    What about users (people and companies) that tune and compile the kernel themselves?

    What if this $99 price increases over time? $99 becomes $999 which in turn becomes $9999.

    How long does it take to get something signed?
    You send the package to Microsoft and they sign it the minute or later, or its going to be a lengthy process that takes months? Every line of code will need to be audited?

    What if there are any DMCA complaints or intellectual property dispute, the signature will be revoked? retroactively revoked?

    Leave a comment:


  • Zapitron
    replied
    Originally posted by allquixotic View Post
    It's not whether anyone wants to or not. It's as Alex said: for systems where disabling secure boot is not an option (because disabling it isn't implemented properly or not at all or the user is too stupid to disable it), it will be impossible to get a signed bootloader / signed kernel for a system with the proprietary modules. That's because the proprietary modules essentially do "user-space modesetting", and most of the real low-level logic is done through a user-space library. Allowing this kind of low-level access into the hardware from userspace would not be permitted by the secure boot folks; they wouldn't allow you to sign a bootloader and kernel that has this kind of gaping security hole, where anyone with root could just write to an arbitrary area in memory.
    A $99 service is going to audit the whole kernel? My bet is that whoever is taking that $99 probably doesn't even know what Linux is, much less has the time or inclination to think about what proprietary driver modules are. Whatever peon is in charge of the signing is just going to do it.

    Something isn't being explained; Garrett seems to be taking this whole thing way too seriously.

    RH should stop trying to make the system "secure"(marketing term) by secureboot standards, and just keep on trying to make it secure by their customer's standards (you know, the people who actually pay Red Hat) like they have been doing for the last decade or two. Pay lip service to secureboot's bullshit, give 'em the stock RH grub2 and see if they'll sign it. If they don't fall for that, then give 'em the dedicated-to-loading-a-RH-kernel version of grub2 (or however it is that the kernel gets loaded) combined the full blast of immensity that is the existing Linux kernel. By the time you get to that second try, the $99 service is already losing money. Grind them down from there, until they give up on the enormity of the task and just sign the damn grub2.

    Someone who takes only $99 isn't thinking about all the ways a kernel can restore power to the admin. Even if they're smart enough, they don't have the time.

    Leave a comment:


  • oliver
    replied
    Originally posted by Kano View Post
    I still don't get your point, ms definitely stated that on x86 platform the uefi setup MUST provide an option to disable secure boot. Only on ARM there may NOT be an option to disable it. That makes it non trivial if you dont want to desolder the eeprom of course, but maybe you find a spi interface to use. UEFI is not graved into stone, if you want to modify it, you find a way.
    Are you sure it MUST provide an option to disable it? I believe it was 'does not have to be enabled. In any case, this will be just the first step.

    Leave a comment:


  • ulenrich
    replied
    enlighten me

    Please, enlighten me about features of secure boot:

    - Just to prevent some rootkit to be installed from a running MsWin?
    This you could be prevented, even if they give away secure-boot keys: Uefi just has to announce the owner of the starting software from key before booting!

    - Prevent criminal hardware access?
    This for you have to encrypt all bits on the drive.

    - Prevent users in a commercial environment from tampering?
    They have to encrypt all bits on the drive,
    and they have to keep secret admin-root passwords from the users.
    And they have to disable alternative starting points.

    I think all is possible. And I think Red Hat and SUSE do want to provide services to their customers for all of it ...
    Last edited by ulenrich; 06-01-2012, 07:08 AM.

    Leave a comment:


  • 123456789
    replied
    Why cant we just ensure that Linux boots on an SecureBoot enabled box
    and then, do what ever we want, like loading closed source modules, installing a
    self-compiled kernel ...
    Essentially guaranteeing the freedom of the user to do what ever he wants.

    Leave a comment:


  • Kano
    replied
    I still don't get your point, ms definitely stated that on x86 platform the uefi setup MUST provide an option to disable secure boot. Only on ARM there may NOT be an option to disable it. That makes it non trivial if you dont want to desolder the eeprom of course, but maybe you find a spi interface to use. UEFI is not graved into stone, if you want to modify it, you find a way.

    Leave a comment:


  • oliver
    replied
    The little problem that a lot of people are forgetting, especially those of us who would boycott secureboot, is that all vendors will put it in their systems and why should they even care about the option to be able to disable it? "All our users are windos users anyway, who cares?" And server users are actually 'happy' with this.

    This is just a tool for MS to increase their grasp on the user.

    If this would even work remotely, a separate instance unrelated to M$ will need to be in charge of signing. But even better, would be the option to put your key into the bios yourself. Ubuntu, Redhad can buy their key for 'joe user'. Everybody else can just use their own key and put it in the bios. Of course the bios would have to support putting the key into an area that cannot be written to from the OS, ever. Hell, require 12V programming voltage that can only be applied by the use of a jumper. Annoying and difficult? Absolutly, but it would be a reasonable safe option.

    Of course this would only ever come if required by the EU law. As USA law will be adapted to suit whatever M$ wants and just bends over for them anyhow.


    Finally, hopefully this will spurt coreboot development. If a board is properly supported by coreboot, just remove the 'secureboot hell' and put coreboot in and be happy.

    Leave a comment:


  • Kano
    replied
    That's pure nonsense. And if you don't know: you can use Coreboot with UEFI payload.

    Leave a comment:


  • Qaridarium
    replied
    Originally posted by Kano View Post
    You can attack every system, but be sure the most common way is to use the mbr up to now for those things. the first virus that used the mbr must be as old as dos. It does not matter if you use coreboot or whatever, if you want to attack a system you find a way - and if you need to write a new bios/uefi then you do so. As soon as flashrom works and your enemy is root on your system he can attack the bios directly as well, no matter if it is internally uefi or not. You can simply add an option rom with your code that will be executed on boot. Of course you dont know that as you never modified a bios, but i did - i added/replaced vga rom, raid rom, pxe, plop...
    because of this you use virtualizations with full hardware emulation then the enemy THINK he attacking something but he only do it in the emulation and this set the emulation to "hold" because of the Intrusion Detection System.

    Leave a comment:

Working...
X