6 ms·

This article seems to focus on closed-source solutions. What about Linux? If the Trusted Computing code would be open-source, that creates another rather huge p

This article seems to focus on closed-source solutions. What about Linux? If the Trusted Computing code would be open-source, that creates another rather huge problem for the big brother and big media. Does that mean Linux machines would be unable to connect to the internet? Or would they need closed-source Trusted Computing drivers instead?

Jach 14y ago
From the article: > Consequently, a trusted computing platform must validate the signature of an operating system before booting it. Operating systems not certified as implementing all the requirements of Trusted Computing will not be issued certificates, and may not be booted on such systems. This has already happened with Windows 8 verified hardware. If you want to run another OS, you (or rather, the OS maintainers) have to pay the $99 Microsoft (ed: VeriSign, see below) tax to get a Microsoft-signed bootloader and kernel. (Fedora has already done this.) A decent write-up is here with some comments from Linus: http://www.zdnet.com/blog/open-source/linus-torvalds-on-windows-8-uefi-and-fedora/11187 http://www.zdnet.com/blog/open-source/linus-torvalds-on-wind... It's kind of disturbing when the main reassurance is "Hackers will get around it. Probably."
- yuhong 14y ago
  The $99 goes to VeriSign.
  - Jach 14y ago
    Thanks for the correction.
  - rbanffy 14y ago
    Why only VeriSign? Shouldn't there be more than one trusted root?
- daeken 14y ago
  > This has already happened with Windows 8 verified hardware. If you want to run another OS, you (or rather, the OS maintainers) have to pay the $99 Microsoft tax to get a Microsoft-signed bootloader and kernel. No. While that is an option -- if you want to use Secure Boot -- MS is requiring certified x86 machines to allow disabling Secure Boot entirely. Does that make it more difficult to install? Marginally, yes; it adds additional steps. Does it mean that you have to jump through the signing hoops? Absolutely not.
  - Jach 14y ago
    For now. The story is different for ARM devices, however, unless there has been an update to that policy that I missed.
    - daeken 14y ago
      Yes, ARM still doesn't allow unsigned kernels to run; I mentioned x86 specifically in my post. That said, the "For now." is fearmongering. It's very possible that MS could change things, but that doesn't mean we should make that assumption -- that's just FUD. There are plenty of legitimate things to gripe about around the Secure Boot stuff, but potential future changes to the policies aren't high on the list.
      - Jach 14y ago
        Fair point. While I think some concern is warranted in Microsoft's case given their history, FUD is FUD. Apart from whether MS will change its policies, I'm interested to see what the responses will be if the private signing key is compromised.
      - pgeorgi 14y ago
        It's like they handled mandantory driver signing on win64: One of the reasons 32bit wasn't affected is that this requirements breaks old drivers. Similarily, on x86 you have two inhibiting factors: old systems without UEFI+secureboot that can run windows 8, and new systems that have to run older windows versions for some reasons (business requirements). In a couple of years, there are only secureboot-capable Windows versions out there (and still relevant), and only secureboot-capable systems to run windows 10 on. That's a much more comfortable situation to pull the plug on non-secureboot boot.

Jach 14y ago

From the article: > Consequently, a trusted computing platform must validate the signature of an operating system before booting it. Operating systems not certified as implementing all the requirements of Trusted Computing will not be issued certificates, and may not be booted on such systems. This has already happened with Windows 8 verified hardware. If you want to run another OS, you (or rather, the OS maintainers) have to pay the $99 Microsoft (ed: VeriSign, see below) tax to get a Microsoft-signed bootloader and kernel. (Fedora has already done this.) A decent write-up is here with some comments from Linus: http://www.zdnet.com/blog/open-source/linus-torvalds-on-windows-8-uefi-and-fedora/11187 http://www.zdnet.com/blog/open-source/linus-torvalds-on-wind... It's kind of disturbing when the main reassurance is "Hackers will get around it. Probably."

yuhong 14y ago
The $99 goes to VeriSign.
- Jach 14y ago
  Thanks for the correction.
- rbanffy 14y ago
  Why only VeriSign? Shouldn't there be more than one trusted root?
daeken 14y ago
> This has already happened with Windows 8 verified hardware. If you want to run another OS, you (or rather, the OS maintainers) have to pay the $99 Microsoft tax to get a Microsoft-signed bootloader and kernel. No. While that is an option -- if you want to use Secure Boot -- MS is requiring certified x86 machines to allow disabling Secure Boot entirely. Does that make it more difficult to install? Marginally, yes; it adds additional steps. Does it mean that you have to jump through the signing hoops? Absolutely not.
- Jach 14y ago
  For now. The story is different for ARM devices, however, unless there has been an update to that policy that I missed.
  - daeken 14y ago
    Yes, ARM still doesn't allow unsigned kernels to run; I mentioned x86 specifically in my post. That said, the "For now." is fearmongering. It's very possible that MS could change things, but that doesn't mean we should make that assumption -- that's just FUD. There are plenty of legitimate things to gripe about around the Secure Boot stuff, but potential future changes to the policies aren't high on the list.
    - Jach 14y ago
      Fair point. While I think some concern is warranted in Microsoft's case given their history, FUD is FUD. Apart from whether MS will change its policies, I'm interested to see what the responses will be if the private signing key is compromised.
    - pgeorgi 14y ago
      It's like they handled mandantory driver signing on win64: One of the reasons 32bit wasn't affected is that this requirements breaks old drivers. Similarily, on x86 you have two inhibiting factors: old systems without UEFI+secureboot that can run windows 8, and new systems that have to run older windows versions for some reasons (business requirements). In a couple of years, there are only secureboot-capable Windows versions out there (and still relevant), and only secureboot-capable systems to run windows 10 on. That's a much more comfortable situation to pull the plug on non-secureboot boot.