4 ms·

What a catch 22. We want commitment to OSS so we're GPL v3, but because of our commitment we can't supply OSS so instead we're going to go for something else th

What a catch 22. We want commitment to OSS so we're GPL v3, but because of our commitment we can't supply OSS so instead we're going to go for something else that's not OSS so we don't disclose the key. Someone, somewhere, has just torn their beard out in fury.

rquirk 14y ago
efilinux looks to be BSD, so at least it isn't like they are using a proprietary boot loader. https://github.com/mfleming/efilinux https://github.com/mfleming/efilinux
- _delirium 14y ago
  While true that you will be able to modify the efilinux code, you won't be able to run the modified version, since it won't be signed, making it a very theoretical sort of open source. That kind of open-source-but-not-really situation is exactly what GPLv3 was trying to prevent.
  - kryptiskt 14y ago
    If you're able to build your own version, you are certainly able to disable secure boot or install your own keys (both of which are mandatory for Intel hardware). The big drawback is that you have to splash out on your own $99 key if you want to distribute your alternative to people who don't want to disable secure boot.
  - Jach 14y ago
    > ...you won't be able to run the modified version... "Tivoization"[1] is a different problem than "can't run because of [any reason besides the hardware owner doesn't want you to]", unless you're talking about another aspect of v3. For instance anything that is AGPL'd presumably is released without the passwords to the database, which presumably doesn't allow remote connections! Are you saying that doing such is a violation of the A/GPLv3 in either legality or spirit? (And you can't license all the data in your DB--think of all the poor sites storing user passwords in plaintext. Also data licenses are more tricky than software ones, but if code is data and data is code...) And of course, even with DRM that supposedly makes it so unauthorized code cannot be run, it's more or less really just saying "we make it harder." I've seen a lot of "we got our tivo to run Linux or something else" posts, and the PS3 drama was interesting to watch unfold. [1] I side with Torvalds with a dislike for this word: "[Stallman] calls it "tivoization", but that's a word he has made up, and a term I find offensive, so I don't choose to use it. It's offensive because Tivo never did anything wrong, and the FSF even acknowledged that. The fact that they do their hardware and have some DRM issues with the content producers and thus want to protect the integrity of that hardware. "The kernel license covers the kernel. It does not cover boot loaders and hardware, and as far as I'm concerned, people who make their own hardware can design them any which way they want. Whether that means "booting only a specific kernel" or "sharks with lasers", I don't care."
gcb 14y ago
No. You're wrong. We want open source because we want control of what run on our machines. That standard goes against it. Why not have a per machine signature that you sign your code against? Centralize it and have no more control. That's no catch22 whatsoever.
- recoiledsnake 14y ago
  >We want open source because we want control of what run on our machines >That standard goes against it. >Why not have a per machine signature that you sign your code against? And the Microsoft UEFI rules for getting a Windows 8 Logo REQUIRES UEFI setup to provide to a physically present user the option to turn off secure boot and add/delete your own keys. How many times has this to be repeated to the same seasoned and regular commentators on this site and many others in similar stories from the past few months? Is there a problem with communication here? Or is it intentional misunderstanding with an aim to spread FUD? Sorry for the outburst, but I am really lost here with the same people making the same 50 silly wrong comments many, many times over and over again about UEFI secure boot. It's like they just see the headline like 'Red Hat to pay MS for booting Linux' and don't care or bother to read Microsoft's, Red Hat's and Ubuntu's take before spouting off in the comments about evil lockdown.
  - miles 14y ago
    the Microsoft UEFI rules for getting a Windows 8 Logo REQUIRES UEFI setup to provide to a physically present user the option to turn off secure boot and add/delete your own keys. Can you please provide an authoritative link for this? The only thing I turned up was this "Secure Boot Overview" updated a few weeks ago: http://technet.microsoft.com/library/hh824987.aspx http://technet.microsoft.com/library/hh824987.aspx [This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.] [A]fter final firmware validation and testing, the OEM locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, and then generates a platform key (PK). The PK can be used to sign updates to the KEK or to turn off Secure Boot. EDIT: Just found this (tl;dr - disabling Secure Boot is mandatory for x86 and forbidden for ARM): Windows Hardware Certification Requirements http://download.microsoft.com/download/a/d/f/adf5bede-c0fb-4cc0-a3e1-b38093f50ba1/windows8-hardware-cert-requirements-system.pdf http://download.microsoft.com/download/a/d/f/adf5bede-c0fb-4... 17. MANDATORY. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following: a) It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx) which will put the system into setup mode. b) If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with SecureBoot turned off. c) The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults. On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.
adestefan 14y ago
The GPLv3 does not require you to provide a key. It only requires you to provide a way to bypass the need for a key. Allowing a user to add their own keys or even the option to disable the need for a key is fully within the bounds of the GPLv3. There's also the outstanding issue that if you only supply software, then you might not even need to do anything to comply with the TiVo-ization clauses of GPLv3.
- obtu 14y ago
  Interesting, but I think this needs further analysis. That bypass mechanism must also comply with the “no additional restricions” aspect of the licence.

rquirk 14y ago

efilinux looks to be BSD, so at least it isn't like they are using a proprietary boot loader. https://github.com/mfleming/efilinux https://github.com/mfleming/efilinux

_delirium 14y ago
While true that you will be able to modify the efilinux code, you won't be able to run the modified version, since it won't be signed, making it a very theoretical sort of open source. That kind of open-source-but-not-really situation is exactly what GPLv3 was trying to prevent.
- kryptiskt 14y ago
  If you're able to build your own version, you are certainly able to disable secure boot or install your own keys (both of which are mandatory for Intel hardware). The big drawback is that you have to splash out on your own $99 key if you want to distribute your alternative to people who don't want to disable secure boot.
- Jach 14y ago
  > ...you won't be able to run the modified version... "Tivoization"[1] is a different problem than "can't run because of [any reason besides the hardware owner doesn't want you to]", unless you're talking about another aspect of v3. For instance anything that is AGPL'd presumably is released without the passwords to the database, which presumably doesn't allow remote connections! Are you saying that doing such is a violation of the A/GPLv3 in either legality or spirit? (And you can't license all the data in your DB--think of all the poor sites storing user passwords in plaintext. Also data licenses are more tricky than software ones, but if code is data and data is code...) And of course, even with DRM that supposedly makes it so unauthorized code cannot be run, it's more or less really just saying "we make it harder." I've seen a lot of "we got our tivo to run Linux or something else" posts, and the PS3 drama was interesting to watch unfold. [1] I side with Torvalds with a dislike for this word: "[Stallman] calls it "tivoization", but that's a word he has made up, and a term I find offensive, so I don't choose to use it. It's offensive because Tivo never did anything wrong, and the FSF even acknowledged that. The fact that they do their hardware and have some DRM issues with the content producers and thus want to protect the integrity of that hardware. "The kernel license covers the kernel. It does not cover boot loaders and hardware, and as far as I'm concerned, people who make their own hardware can design them any which way they want. Whether that means "booting only a specific kernel" or "sharks with lasers", I don't care."

gcb 14y ago

No. You're wrong. We want open source because we want control of what run on our machines. That standard goes against it. Why not have a per machine signature that you sign your code against? Centralize it and have no more control. That's no catch22 whatsoever.

recoiledsnake 14y ago
>We want open source because we want control of what run on our machines >That standard goes against it. >Why not have a per machine signature that you sign your code against? And the Microsoft UEFI rules for getting a Windows 8 Logo REQUIRES UEFI setup to provide to a physically present user the option to turn off secure boot and add/delete your own keys. How many times has this to be repeated to the same seasoned and regular commentators on this site and many others in similar stories from the past few months? Is there a problem with communication here? Or is it intentional misunderstanding with an aim to spread FUD? Sorry for the outburst, but I am really lost here with the same people making the same 50 silly wrong comments many, many times over and over again about UEFI secure boot. It's like they just see the headline like 'Red Hat to pay MS for booting Linux' and don't care or bother to read Microsoft's, Red Hat's and Ubuntu's take before spouting off in the comments about evil lockdown.
- miles 14y ago
  the Microsoft UEFI rules for getting a Windows 8 Logo REQUIRES UEFI setup to provide to a physically present user the option to turn off secure boot and add/delete your own keys. Can you please provide an authoritative link for this? The only thing I turned up was this "Secure Boot Overview" updated a few weeks ago: http://technet.microsoft.com/library/hh824987.aspx http://technet.microsoft.com/library/hh824987.aspx [This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.] [A]fter final firmware validation and testing, the OEM locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, and then generates a platform key (PK). The PK can be used to sign updates to the KEK or to turn off Secure Boot. EDIT: Just found this (tl;dr - disabling Secure Boot is mandatory for x86 and forbidden for ARM): Windows Hardware Certification Requirements http://download.microsoft.com/download/a/d/f/adf5bede-c0fb-4cc0-a3e1-b38093f50ba1/windows8-hardware-cert-requirements-system.pdf http://download.microsoft.com/download/a/d/f/adf5bede-c0fb-4... 17. MANDATORY. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following: a) It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx) which will put the system into setup mode. b) If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with SecureBoot turned off. c) The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults. On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.

adestefan 14y ago

The GPLv3 does not require you to provide a key. It only requires you to provide a way to bypass the need for a key. Allowing a user to add their own keys or even the option to disable the need for a key is fully within the bounds of the GPLv3. There's also the outstanding issue that if you only supply software, then you might not even need to do anything to comply with the TiVo-ization clauses of GPLv3.

obtu 14y ago
Interesting, but I think this needs further analysis. That bypass mechanism must also comply with the “no additional restricions” aspect of the licence.