User: Password:
|
|
Subscribe / Log in / New account

No signed kernel, just a signed boot loader

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 16:49 UTC (Mon) by micka (subscriber, #38720)
In reply to: No signed kernel, just a signed boot loader by pboddie
Parent article: Details on Ubuntu's UEFI secure boot plan

I just checked. In my country, causing someone else's computer to not function anymore seems to be able to send someone to prison (up to 5 years).

Of course, what applies to common people may not apply to Microsoft or Canonical.


(Log in to post comments)

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 17:01 UTC (Mon) by gioele (subscriber, #61675) [Link]

> I just checked. In my country, causing someone else's computer to not function anymore seems to be able to send someone to prison (up to 5 years).

I suppose that there are a lot of other things that must happen at the same time before you jail someone. Otherwise every borked update to Debian sid or Rawhide would send quite a bit of people in prison.

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 18:26 UTC (Mon) by pboddie (guest, #50784) [Link]

I think there's a difference between a "best effort" update - one that the users may actually have instigated themselves - and someone bricking those users' computers because they're running something that the people with the control don't like. Moreover, if a Debian or Fedora update went wrong, you could probably do a re-install - the hardware would still function in most cases - whereas "secure boot" seems to be all about making the hardware useless unless you agree to run precisely what other people want you to run. And even then, at least for the average user, maybe it also involves the penalty of having to return the hardware for servicing.

But as I noted, such schemes are mostly used to erode the rights of users in the name of something else so that people don't question such schemes until after they have been introduced, and thus any argument about how a dominant vendor has managed to obliterate the competition can be waved away many years after the fact with excuses like "it's what the market expected" and "nobody demanded anything else".

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 18:39 UTC (Mon) by raven667 (subscriber, #5198) [Link]

> "secure boot" seems to be all about making the hardware useless unless you agree to run precisely what other people want you to run

That is hyperbole and is not what secure boot on x86 does. It'd be great if we could stick to a discussion based on the facts.

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 21:28 UTC (Mon) by pboddie (guest, #50784) [Link]

Oh sure, you can sign your own payloads and install your own keys, but in practical terms this means that people who buy computers will not only have to put up with what the vendor pre-installed - just like the majority of people won't ever "install Linux over Windows", even though lots of people think that this is a good enough workaround - but they will have yet another barrier if they do ever discover that they could run something else.

And I'm sure it's not beyond the skills of the vendors to make installing one's own keys a near impossibility and then claiming it was an accident for as long as it takes before they can then claim that the product is no longer supported.

So in practical terms, it is all about control. We can discuss technical workarounds as much as we like and deny that the technology imposes any particular restrictions, but the combination of one company's continuous strategy of pushing the regulatory envelope and that technology results in a shoring up of that company's position.

Why else are the distributions jumping through hoops? Because they like a challenge? The practical effect of the misuse of such a technology is as much a fact as any aspect of the "it's OK - I can still boot my kernel" technical discussion.

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 21:40 UTC (Mon) by raven667 (subscriber, #5198) [Link]

> you can sign your own payloads and install your own keys

So we agree on the substance of the matter. I can't comment on the rest of your post because I can't find any facts or point, just a lot of rhetorical flailing about.

No signed kernel, just a signed boot loader

Posted Jun 26, 2012 11:03 UTC (Tue) by pboddie (guest, #50784) [Link]

Oh well, let this be another place on the Internet I have to go back to at some point in the future and write "I told you so" for all the good that actually does. Nothing to see here, I guess: keep staring at the bits and bytes.

No signed kernel, just a signed boot loader

Posted Jun 26, 2012 18:10 UTC (Tue) by marcH (subscriber, #57642) [Link]

> > you can sign your own payloads and install your own keys

> So we agree on the substance of the matter. I can't comment on the rest of your post because I can't find any facts or point, just a lot of rhetorical flailing about.

Too bad things are not that obvious to Fedora and Canonical. They should have hired you and saved a lot of effort.

No signed kernel, just a signed boot loader

Posted Jun 26, 2012 19:14 UTC (Tue) by raven667 (subscriber, #5198) [Link]

Oh har har har, Mr Sarcastic guy. In any event I am merely relating the understanding and rationale that Fedora and Canonical have publicly written. The fact that the OP doesn't seem to want to read or understand that is the issue I'm trying to correct.

Foolish on my part I suppose. http://xkcd.com/386/

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 18:56 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

The core issue here is the on-by-default requirement for consumer hardware coupled with the specs limitations which prevents a mult-vendor trust chain.

Secureboot as a concept is not a bad thing. The policy surrounding how to enable secureboot for consumer devices needs some iteration however. There is absolutely nothing wrong with an off-by-default secureboot even with the current specification and limitations. On-by-default, has some definite challenges, and MS's certification process requirements brings these challenged directly into the forefront of the discussion.

Even with an on-by-default scheme, if users can disable secureboot to regain access to a system that has been impacted by a key revocation I really don't see a fundamental problem. As long as users are not locked out of the firmware config screens to disable secureboot on the hardware they purchased, a 3rd party revocation process is best described as a very stringent notification about a potential system compromise. If users can disable secureboot they do not lose access to their systems even after a key that their current configuration requires has been revoked.

In fact I'd wager that once the security benefit is digested more widely large institutions like the US Department of Defense and the State Department and even municipal power companies will be making heavy use of secureboot with their own signing keys on a lot of critical infrastructure and even desktops and laptops...so they don't even have to implicitly trust any Vendor (including Microsoft). They'll use the firmware reconfiguration to the fullest to load their own keys on their hardware and then self-sign binaries and to control the revocation process from end-to-end.

-jef

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 19:13 UTC (Mon) by raven667 (subscriber, #5198) [Link]

> specs limitations which prevents a mult-vendor trust chain

I'm not sure that's true, you can have many vendor and user keys loaded into the firmware but to get your key pre-loaded would require some relationship with the vendor so your hardware coverage is likely to be less than 100%, whereas all the vendors want to be able to run MS so that key is virtually guaranteed to be loaded by default.

Actual binaries can be signed by only one key though so to boot and reduce the number of boot media spins required forces you to choose which key you are going to use to sign your initial boot loader and the MS key wins on convenience there.

> Even with an on-by-default scheme, if users can disable secureboot to regain access to a system that has been impacted by a key revocation I really don't see a fundamental problem

Which is exactly the case now for x86. Win8 ARM hosts are boot locked but that's its own separate issue at this time, I don't think any Linux vendor is going to fool around with them. Just don't buy them an expect to run anything else on them (not much different that the rest of the ARM market anyway).

> companies will be making heavy use of secureboot with their own signing keys

Thats probably something they will want to do but it depends on how to sign or re-sign boot binaries. Is it possible to re-sign the Windows 8 boot loader for example and have the system not broken? Certainly this will be do-able, maybe even common, with Linux systems.

No signed kernel, just a signed boot loader

Posted Jun 26, 2012 7:27 UTC (Tue) by ssmith32 (subscriber, #72404) [Link]

You seem to have a lot of faith in municipal power companies commitment to security...

Unfortunately, regardless of the "should", there are plenty of examples to the contrary.

Whatever the original intent, in reality, UEFI's largest impact so far has been to impose a significant cost on open-source software, with the to-be-determined security benefits still vaporware..

No signed kernel, just a signed boot loader

Posted Jun 25, 2012 21:33 UTC (Mon) by dlang (subscriber, #313) [Link]

so why aren't the sony execs in prison for their PS/3 update that made it impossible to run linux or other OSs?

No signed kernel, just a signed boot loader

Posted Jun 26, 2012 7:41 UTC (Tue) by micka (subscriber, #38720) [Link]

Citing myself :

> Of course, what applies to common people may not apply to Microsoft or Canonical.

or Sony. The "Microsoft or Canonical" was not meant to be exhaustive.

Of course I'm exagerating. Even the individual cracker that bricks _one_ computer would not go to jail... t1he first time, unless they go against a police or big corporate computer.

The second time would be very different, though.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds