Hacker News Reader

Comment by Jach | Hacker News Reader

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-wind... It's kind of disturbing when the main reassurance is "Hackers will get around it. Probably."

View on HN

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

For now. The story is different for ARM devices, however, unless there has been an update to that policy that I missed.

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.

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.

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.

Sorry, but there is FUD and FUD.

When Microsoft claims Linux violates their patents, that it lacks the level of service companies require or that it destroys value, it is FUD. Microsoft does it very well.

But when we raise the possibility Microsoft will act in its best interest in the future (which is to block competition) I'd argue it would be a fair extrapolation from previous behavior. Microsoft consistently engages in anti-competitive behavior and it would be naïve to expect a sudden surge of morality from its top executives.

"That said, the "For now." is fearmongering."

> I'd say saying it's FUD is playing for time.

Hardware implementors suck at implementing firmware. Didn't you ever had trouble trying to boot from a pendrive? They couldn't get it right with BIOS, why should I think they won't screw it in UEFI? And if they screw it, what will be the workarond? Enable Secure Boot?

The $99 goes to VeriSign.

Thanks for the correction.

Why only VeriSign? Shouldn't there be more than one trusted root?

Reply on news.ycombinator.com