Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ubuntu Can't Trust FSF's Secure Boot Solution

Posted by Soulskill on from the dem's-fightin'-woids dept.

sfcrazy writes "The Free Software Foundation recently published a whitepaper criticizing Ubuntu's move to drop Grub 2 in order to support Microsoft's UEFI Secure Boot. The FSF also recommended that Ubuntu should reconsider their decision. Ubuntu's charismatic chief, Mark Shuttleworth, has responded to the situation during an interview, and explained the reason they won't change their stand on dropping Grub 2 from Ubuntu. Shuttleworth said, 'The SFLC advice to us was that the FSF could require key disclosure if some OEM screwed up. As nice as it is that someone at the FSF says they would not, we have to plan for a world where leaders change and institutional priorities change. The FSF wrote a licence that would give them the rights to take specific actions, and it's hard for them to argue they never would!'"

5 of 377 comments (clear)

  1. Mandatory Warning. by Anonymous Coward · · Score: 5, Informative

    Serious Sandwich, aka Bonch, Sharklaser, Tech* etc is one of a number of sockpuppet accounts established and maintained by Burson Marsteller on behalf of Microsoft.

    Their presence in this discussion means comments and moderation will be slanted to emphasize their client's viewpoint.

    Treat all commenters in this discussion with suspicion and derision. Do not post or reply to posts yourself.

    1. Re:Mandatory Warning. by Anonymous Coward · · Score: 4, Informative

      Well, whoever he is he's factually wrong.

      UEFI booting has absolutely nothing to do with boot sectors. Secure boot is part of (A superset of?) UEFI booting. A system doing a UEFI neither needs, looks for, nor cares about the boot sector.

      Boot sectors are part of the old, old, old legacy boot method where you had to chain larger and larger bits of code to jump the CPU in to its newer, more powerful modes. More or less, the sytem starts in a mode so dumb it can only run a few bytes of code. It can't read or interperate filesystems. It cant jump in to a modern 32 or 64bit kernel I can't do anything but read very simple code from a fixed location. This location is the boot sector, and it's always sector 0. This code calls a larger boot loader, then a larger one, then eventually reaches a point where it can start up a modern operating system.

      UEFI is actually a tiny OS that can read partitions/filesystems directly and can call a modern UEFI compatable boot loader directly. Now, not to say you can't subvert your modern UEFI bootloader. (Thats what secure boot is all about) But it certianly has nothing to do with boot sectors.

  2. Shuttleworth isn't being entirely candid by Todd+Knarr · · Score: 4, Informative

    I'm sure the SFLC did tell him that a mistake by an OEM could force disclosure of the signing key. But notice he doesn't say explicitly that they told him it could force disclosure of Canonical's signing key. That's because I'm pretty sure they didn't tell him that. Think about it. The logic here is that an action that breaches the GPLv3 by a downstream distributor (the OEM) could force the upstream to correct the breach. Now, suppose I put that in the context of code: I distribute a GPLv3'd piece of software, you receive it from me, modify it and distribute the modified version. If Shuttleworth's argument is correct, then I am in breach of the GPLv3 because I'm not distributing the source code to your modifications as required by the GPLv3. But that's obvious nonsense, since I'm only required to distribute the source code to the software I'm distributing and I'm not distributing your modifications at all. Only you're doing that, and the only way you can pass your obligations back to me is if you're me in the legal sense (ie. a wholly-owned subsidiary company or a division of my company) or if I've signed a contract with you to take on those obligations for you.

    So I suspect that while Canonical would be required to distribute any tools needed to create signed bootloaders and the keys needed for the BIOS to boot them, unless they're distributing the actual hardware it'd be on the OEM (who selected the hardware) to take any steps necessary to comply with the GPLv3 as regards the hardware (ie. either choose a BIOS that allowed keys to be enrolled or Secure Boot to be disabled, or distribute their own signing keys). Of course that could place the OEMs in a bind: if they used Canonical's signed binaries and keys then the OEM would be obliged to provide the signing key, but Canonical is not obliged to provide it to them. Which I think is exactly the situation the FSF desires: OEMs placed in a position where to use a very desirable bit of software in their equipment requires selecting a BIOS that permits user control over the Secure Boot process and keys.

  3. A little background on Burson-Marsteller by Anonymous Coward · · Score: 5, Informative

    (please note that I am NOT the same AC that made the accusation, but rather, one that wondered who this firm is, so I figured I would share my findings...)

    Ok, so I do a bit of digging for two minutes, and came up with this:

    Who:
    Burson-Marsteller is a PR firm. As in, a really, really, REALLY big fuckin' firm. Apparently the only place on Earth worth mentioning that doesn't have an office of theirs is Antarctica.

    http://en.wikipedia.org/wiki/Burson-Marsteller

    Where:
    Burson-Marsteller has been very, very busy. I haven't had time to second-source the entries from Wikipedia, but supposedly this firm has been at the forefront of a lot of really, really bad shit. The original Tylenol Poisoning scare, Three Mile Island, PR for Phillip Morris; you name the PR nightmare, and there's a good chance they've been there to mop up. In other words, these guys are "World-Class Spin Doctors".

    When:
    "When" really doesn't even apply in the context I'm using because they are still in business as part of the WPP plc, the world's largest advertising agency. Which means, "when" is really all the time.

    http://en.wikipedia.org/wiki/WPP_Group

    What:
    It took a bit of digging but I found a set of links that tied them back to Microsoft. Ok, so now we have something tying the two together with Microsoft as Burson-Marsteller's client.

    http://www.economist.com/blogs/babbage/2012/03/microsoft-v-google

    http://www.techdirt.com/articles/20110513/15424314269/burson-marsteller-digs-itself-deeper-hole-deletes-critical-comments-its-facebook-page.shtml

    The accusation:
    I myself have observed "shill-like" behavior over the last decade on Slashdot, and in the last 4 years it has intensified quite a bit. I believe that, while there is no direct way to prove the accusation, there is sufficient background for readers to make an informed decision as to the possibility of the accusation being accurate.

    Why AC:
    Yes, I have an account here, let's just say numbered under 200,000 and leave it at that. No, I will not post this with my account for reasons that should be readily apparent to anyone with two brain cells attached - which is to say, attracting the attention of a world-sized firm to my little pittance is probably not the wisest move to make. If they have enough money to pay people to sit around all day and troll slashdot forums, then they certainly have enough money to harass me (given the opportunity).

    Sometimes the best tactic to keep out of harm, is to simply not be seen.

  4. Re:I Call Bullshit. by LourensV · · Score: 5, Informative

    I think the reason for the SFLC's advice regarding having to reveal th key is that Canonical distributes updates directly. Here's the scenario:

    1. The OEM sells a PC with Ubuntu preloaded and the BIOS locked.
    2. The user buys the PC and then updates GRUB2 to a newer version supplied from the Ubuntu repositories. It'll install fine, because it's been signed by Canonical, and the Canonical key is in the BIOS.
    3. User wants to modify GRUB2. They get the sources from Canonical, modify, recompile, and try to install. The computer won't boot, because their modified version is missing a signature.

    This means that Canonical is violating the Tivoisation clause in the GPLv3. Canonical is redistributing GRUB2 to the user, and the licence won't let them do that unless they also provide the user with everything they need to be able to change GRUB2 and load it onto their computer just as they're doing with the original they were given. Since Canonical can't unlock the BIOS (only the OEM can), the only way they can fulfil those requirements is by giving out their key.