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

SUSE and Secure Boot: The Details (SUSE Blog)

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 16, 2012 16:56 UTC (Thu) by khim (subscriber, #9252)
In reply to: SUSE and Secure Boot: The Details (SUSE Blog) by gmaxwell
Parent article: SUSE and Secure Boot: The Details (SUSE Blog)

I suspect you're measuring "similar to" in a much different way I am. I don't consider the under the hood mechanism all that important: only the impact on user and developer freedom.

And so do I. The problem with freedom is the infamous Your right to swing your arms ends just where the other man’s nose begins.

Some people become upset when they are not given freedom to do something even if there are no reason to perceive that they are indeed entitled for such freedom. "YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES" approach with manual bypass made sense fifty years ago when only trained professionals had access to the big iron systems in a conditioned room. In fact they had no need for such protection because the very fact that they have physical access to the body of the device meant they are privileged enough to do whatever they want with it.

In today's world where computers are used everywhere there are huge number of system where the person which actually has physical access to the system does not have the legal right to alter it - and technical solutions must reflect this fact.

Secureboot unmodified except for a super easy semi-automatic key enrollment process for new OS installs would be a perfectly reasonable thing in my book.

And will be perfectly unreasonable in my book because it'll rob the real owner of the device (the company which paid for it) from the valuable and much-requested capability.


(Log in to post comments)

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 16, 2012 17:09 UTC (Thu) by gmaxwell (guest, #30048) [Link]

If the _owner_ of the system wants to turn it off, then that sounds like a fine accommodation.

I don't see how that has anything to do with how systems shipped by OEMs to end consumers works by default. Secureboot, as its described today, doesn't solve that owner's choice issue itself— it's solved by locking down the system and denying access to the firmware, something that can be done independently of secureboot.


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