| |||||||||||||
SUSE and Secure Boot: The Details (SUSE Blog)SUSE and Secure Boot: The Details (SUSE Blog)Posted Aug 11, 2012 22:07 UTC (Sat) by geofft (subscriber, #59789)In reply to: SUSE and Secure Boot: The Details (SUSE Blog) by mmorrow Parent article: SUSE and Secure Boot: The Details (SUSE Blog)
I think the question of whether this is an achievable goal an interesting question. However, I'd like to address Secure Boot in particular. Okay, I certainly agree that the Secure Boot implementation is distasteful for many reasons (having interacted with it, I'm going to throw "Microsoft requires that you upload your bootloader via Silverlight" into the list of reasons to hate it). But to bring this more on topic, I'm curious if you think that the goals of Secure Boot are good goals, and whether they're worthwhile. It seems to me, as an end user, that I want to know whether my OS has been tampered with at the boot loader level, because if that's gone then I have no trust in the rest of the OS, and if that's okay, there's a lot of validation that can be done of the rest of the OS (automatic checksums of packages, etc.) by bootstrapping that root of trust. It also seems to me, as someone who occasionally fixes other nontechnical people's computers (and tends not to fix them by replacing their OS with a Linux distro), that a configuration that makes it harder to infect Windows machines with malware, and can also scale to making it harder to infect non-Windows machines with malware, while not getting in the way of running things other than Windows, would be desirable. Do you think these are good goals, and do you think there's some amount of inconvenience in running non-Windows operating systems that should be tolerated in pursuit of this goal?
(Log in to post comments)
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 11, 2012 22:48 UTC (Sat) by mmorrow (subscriber, #83845) [Link]
> But to bring this more on topic, I'm curious if you think that
> the goals of Secure Boot are good goals, and whether they're worthwhile.
I do indeed think that the end user having auditability at the boot-loader
> Do you think these are good goals, and do you think there's some amount
This is absolutely not tolerable. Why Windows? Why not OSX, or Linux, or _?
This is precisely where I see Secure Boot possessing real danger. Its stated
Furthermore, it reinforces the precedent on ARM system of hardware-crypto
And last and most unsettling, all that needs to be done to lock down x86
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 11, 2012 22:55 UTC (Sat) by geofft (subscriber, #59789) [Link]
Well, as it turns out, Secure Boot does not inconvenience the user booting most Linux distributions (and you cannot even run OS X legally on a non-Mac, so that argument is moot). It's only about _custom_ kernels.
And it certainly inconveniences the developer, but that's a different argument.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 0:48 UTC (Sun) by theophrastus (guest, #80847) [Link]
"_custom_ kernels"? as in those that i configure and compile on debian with make-kpkg ?
here's a super simple stupid question: where does "UEFI secure boot" exist? the BIOS(/ROM)? or is there processor level (Intel) microcode supporting it? and if the former, will there be hacks to remove it by flashing the ROM?
sometimes i'm lead to believe that a pure linux box won't have to even worry about UEFI and other-times it seems that it will prevent linux installation... damn confusing...
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 0:54 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
It's in the platform firmware, not the CPU. You could remove it by replacing the ROM contents, but systems implementing Secure Boot will require signed firmware updates - you'd need to attach a flash programmer directly to your system.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 2:56 UTC (Sun) by theophrastus (guest, #80847) [Link]
Is there no hope and possibility that a motherboard maker will offer a non-UEFI (BIOS) option? i suppose it'll be said that merciless market forces will eliminate this when the IT departments of *all* businesses will insist upon it?
but otherwise... where is the sticking point in the following scenario?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 3:19 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
All Windows 8 certified x86 systems will let you disable Secure Boot in the firmware configuration. You'll still be running UEFI, but it'll boot anything you want it to.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 5:38 UTC (Sun) by tonyblackwell (subscriber, #43641) [Link]
Sounds good in theory. In terms of our current needs to buy motherboards, I've discussed this with ASUS and Gigabyte - with whoever there would respond to my attempts at communication. As I understand their replies, neither company has any system at all for disabling secure boot and no plans to do so. Does anyone have inside contacts?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 5:41 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
If hardware vendors want to prevent their boards being used for anything other than Windows 8, that's a thing they can do. They won't be able to sell those boards to anyone who wants to build Windows 8 certified systems and they'll be locking themselves out of the corporate market for the forseeable future, so it doesn't seem like a likely thing for them to do - it seems much more likely that whoever you're talking to just has no idea what they're talking about.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 7:16 UTC (Sun) by steveriley (subscriber, #83540) [Link]
Windows Hardware Certification Requirements - Client and Server Systems
http://msdn.microsoft.com/en-US/library/windows/hardware/...
16. Mandatory. Secure Boot Variable. The firmware shall implement the SecureBoot variable as documented in Section 3.2 "Globally Defined Variables' of UEFI Specification Version 2.3.1 Errata B"
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:
1. 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.
2. 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.
3. 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.
18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 4:19 UTC (Sun) by geofft (subscriber, #59789) [Link]
UEFI and Secure Boot are two different things. We've been having EFI machines forever (look at your nearest Mac for an example); it's just that the EFI standard is maturing into UEFI now and is something that can be reasonably implemented, and also that the legacy BIOS boot mechanism is a sufficiently crappy and '80s way to boot a PC that you couldn't implement Secure Boot on it even if you tried, so the forces that want Secure Boot are designing it as part of UEFI.
Secure Boot is no more an inextricable part of UEFI than, say, cookies are of HTTP. Yes, FTP is a sufficiently crappy and '80s protocol that you can't add cookie support to it, but that doesn't mean we need to go back to FTP to eliminate the threat of tracking cookies.
A good number of machines that have been on the market for months are UEFI with legacy BIOS boot support, and have no idea what Secure Boot is.
In any case, as Matthew mentioned, Secure Boot should be trivially disableable in the BIOS menu (on the one test machine I have, with basically a standard-looking BIOS menu with just a few more knobs, it's as obvious as the option to enable hardware virtualization). The worry is just that that's an additional hoop for people to go through before installing Linux. Anyone competent enough to compile their own kernel will know how to go into their BIOS menu and turn off Secure Boot and turn on hardware virtualization while they're there.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 4:54 UTC (Sun) by theophrastus (guest, #80847) [Link]
thank you.
now, if anything, i don't understand the fuss.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 5:26 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
Then presumably you also don't understand why the large commercial Linux distributors think its important to distribute software which is cryptographically locked with a pre-enrolled certificate chain?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 5:38 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
Given the combination of how inaccurate that is and how many times this conversation has been had with you, it's difficult to believe you're being anything other than wilfully dishonest at this point. Anything we're distributing will permit the installation of keys by the end user - nothing is cryptographically locked to the shipped keys.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 6:45 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
Your ad hominem now forces me to respond to what is seemingly becoming a pointless subthread—but don't be confused: I'm speaking only to defend my good name and to help clarify for anyone who was confused. I apologize in advance for repeating things almost everyone knows.
Under Red Hat's standing plan (https://fedoraproject.org/wiki/Features/SecureBoot), the system will ship with a bootloader which will only boot a kernel signed by a Red Hat controlled key. This kernel will only load modules signed by a Red Hat controlled key. The early patches to implementing the restrictions are available on your website: http://www.codon.org.uk/~mjg59/tmp/ftsoefi/
The user could replace all the involved keys, but doing so will render their boot chain incompatible with their system unless additional measures are taken. I am assuming that this possible possibility is why you're accusing me of dishonesty?
I know it's hard to tell, but I'm trying to avoid writing a novel in each post. I think it's fair to describe a system as incorporating cryptographic lockdown when it does so, even if there is a convoluted way around it, and especially if even that option may not exist. Otherwise you'd have me saying that the iphone is not locked down— after all, jailbreaking exists for it (and is clearly lawful).
Systems with secureboot enabled will only boot a bootloader signed with an authorized certificate, which the Red Hat one will be signed with. Some systems will likely permit the user to escape from this whole process (by enrolling additional keys in some highly complicated manner, or by disabling the whole thing), but the commercial Linux distributors apparently do not consider this 'jailbreaking' ability to be acceptable—or they would simply avail themselves of it. Regardless, as you pointed out in your very next post, vendors may potentially provide no way to disable it (https://lwn.net/Articles/510827/). This is also what my inquiries have indicated: it won't actually be possible to disable as least in some cases, just as is a _requirement_ for MSFT certification on ARM.
I hope that the inability to disable doesn't turn out to be a common reality, but I am skeptical of the argument that that functionality will deprive these products of Windows 8 certification, in light of the understanding I received (from you) that the original requirements also had the ARM-like limits on x86. Surely there is no reason to believe that Microsoft is obligated to deny their own certification to a vendor who violates their requirements in a manner they are indifferent to. But, even if it is and it remains forever possible to disable this on all PC hardware, I still hold the position that the additional inequality created by access to easy installs is material, and is a violation of the social and economic compromises embodied in copyleft software—but that point is just my opinion.
The rest is just the simple, and I believe fairly uncontroversial facts; and it makes me sad to see you resort to ad hominem here. If you have the spare mental cycles and are willing to be responsive I'd be happy to run all further posts of mine past you for fact checking, because I really do care that I am entirely accurate and not misleading.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 15:09 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
The implementation will use any keys used in db, and the Suse approach lets us extend this to a separate key database with a consistent and non-arcane management UI. This is a far cry from being "cryptographically locked with a pre-enrolled certificate chain" - it's cryptographically locked with whatever set of keys you want to use.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 13, 2012 2:58 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] I'm delighted to see how open you are to adopting improvements proposed by competitors; it's a refreshing change from the "NIH" attitudes I see so often.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 5:37 UTC (Sun) by rahvin (subscriber, #16953) [Link]
The major OEMs might allow adding new keys with secure boot, it really depends on how many enterprise customers want the ability. But if you buy your components separately and put them together yourself I fully expect the manufacturers to not only allow turning of secure boot but adding keys and probably even deleting and modifying the system in-line with the specification.
Lets not underestimate how much MS would like to lock other OS's out of computers, it has long been speculated that was the goal with palladium and other initiatives. But secure boot can most certainly be used for good. Its possible to secure a system with kernel and a signed key that could be used with and IDS system that would prevent the running of any non signed binary. This could essentially eliminate all trojans as long as the keys are handled securely and if you have access to add the keys yourself you could be fully responsible for locking out every binary you haven't personally signed.
Secure boot isn't evil, it's like any tool though in that it can be used for evil.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 0:55 UTC (Sun) by mmorrow (subscriber, #83845) [Link]
> (and you cannot even run OS X legally on a non-Mac, so that argument
> is moot).
;)
> It's only about _custom_ kernels.
By "custom kernel" you mean "kernel which has not been signed with a
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 4:22 UTC (Sun) by geofft (subscriber, #59789) [Link]
An individual user who wants to recompile (or merely re-sign) their kernel has every ability to turn off Secure Boot in their BIOS menu. This is only about what people boot out of the box, and I can't really see the problem if all semi-popular Linux distros get an MS-signed shimloader with their private key embedded.
It's certainly morally offensive, but not hugely practically problematic -- nobody installs a custom kernel the first time they install Linux.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 6:42 UTC (Sun) by tzafrir (subscriber, #11501) [Link]
But many users build kernel modules (look for dkms packages).
Furthermore, it makes creating a custom distribution with any changes to the kernel (including modules, and also to grub's configuration, including its screen?) a whole lot more difficult. Which means you'll have less custom Linux distributions.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 16, 2012 15:50 UTC (Thu) by jschrod (subscriber, #1646) [Link]
But many people want to install NVidias proprietary graphics driver kernel module, since they are the only way to get full support for the respective hardware.
And I think it's wrong to assume that this module will get signatures for all Linux distribution schemes that are out there.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 11, 2012 23:03 UTC (Sat) by gmaxwell (subscriber, #30048) [Link]
> Do you think these are good goals,
Something must be done; this is something, so it must be done!
The goal you're describing is laudable. However, secureboot is neither an effective or necessary measure to achieve that goal.
If the operating system is secure (as in the kernel correctly enforces its policy) then unauthorized software can not replace the bootloader. If the kernel is not secure, than the attacker's _goal_ of fully controlling the system and preventing update that would exclude him can not be thwarted by secureboot. (His rootkit will run shortly after startup and exploit the kernel and prevent its detecton or removal from the startup sequence). This could only be prevented by preventing all execution of unsigned code on the system.
Moreover, a secure boot system which gave a simple easily manually disabled bypass for installing new operating systems: "YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES" would still achieve almost all of whatever small marginal improvement the cryptographic lockdown provides.
As to the question of the problem actually being soluble— it depends on which "the problem" you're speaking of. The problem of it being hard (or eventually impossible) to install non-vendor/microsoft approved distributions, or the problem of some downstream reusers of free software have inequitable access to create software that regular users can run due to their participation in cryptographic lockdown. They are distinct issues, both of which are problematic for the future success of Free Software.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 11, 2012 23:13 UTC (Sat) by geofft (subscriber, #59789) [Link]
> "YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES"
We all know that users click "Yes" on anything that looks like it might be a dialog box with a "Yes" button.
Possibly having the BIOS cache the boot sector, and completely refuse to boot if the boot sector is modified, unless they go into the BIOS in advance to say "okay, boot any boot sector once", would be helpful.
It may need to cache the stage 1 bootloader, too, and also the stage 1 bootloader will need to be expected to do checks on the rest of the bootloader on the kernel, to enforce the property you want that no untrusted code can run with privilege (and then the kernel does checks on the trusted components of userspace).
Of course, that makes it awkward to deliver software updates to the boot sector / stage 1 bootloader. So maybe those things should just have a digital certificate, and you need to go into the BIOS to say "okay, accept any new certificate once", but don't need to go into the BIOS to accept new boot sectors / bootloaders signed by the certificate.
And this is (unintentionally) starting to sound a lot like Secure Boot as actually defined. In fact, I think approximately the only difference is that Microsoft is being so kind as to let other people's code be signed by their certificate (and that Microsoft still has a monopoly over the PC market, so "being so kind" is pretty much the _least_ they could do to not be abusing their monopoly... but in a more competitive market, this seems technically reasonable).
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 17:00 UTC (Sun) by khim (subscriber, #9252) [Link] Possibly having the BIOS cache the boot sector, and completely refuse to boot if the boot sector is modified, unless they go into the BIOS in advance to say "okay, boot any boot sector once", would be helpful. This approach was tried more then decade ago. It does not work. Either user knows nothing about BIOS menus (that's the majority of them!) and only creates needless pressure on support channel or s/he have enough knowleadge to open BIOS menu and boot anyway — in this case they WILL open menu and boot anyway even on malware infected system. You really don't want to give knobs to normal user. Knobs for some geeks (think ChromeOS devices with a switch under battery) are Ok and in fact can be considered security feature (it severely reduces pool of the people who want to crack your boot process), but normal user should never see “yes/no” message.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 0:02 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
"YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES"
A proposal that was explicitly rejected by the industry.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 1:39 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
> "YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES"
how exactly would you be sure the user saw this message and is what replies yes to it?
do you even know what video cards are installed in the system? let alone what mode they are in or which of the displays are hooked up to a monitor?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 2:17 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
> how exactly would you be sure the user saw this message and is what replies yes to it?
> do you even know what video cards are installed in the system? let alone what mode they are in or which of the displays are hooked up to a monitor?
Because it would be displayed by the firmware at boot time. And yes, you can create a situation where a user with e.g. a serial console can't install a /new/ OS without special stunts, just as things _already are_.
And yes, "the industry" (how polite we are to not name names, I suppose) made an affirmative decision to unnecessarily deny the end users reasonable control over their devices. It's a fact, but it's not a justification. And
> this is (unintentionally) starting to sound a lot like Secure Boot as actually defined. In fact, I think approximately the only difference is that Microsoft
Not unintentionally at all. A previously installed bootloader from a vendor using signing to support remote updates from the author of the bootloader sounds fine for software created under a model where that makes sense. This is orthogonal to the question of authorizing that bootloader in the first place, however. The "only difference" that matters is that under secureboot a new operating system can not be installed at all or only via an opaque, undocumented, and user hostile procedure (depending on the platform and implementation details). It may be the only difference, but its the one that matters because its what determines if the owner of the hardware can choose to take control of it by authorizing a free operating system, and its what determines if all downstream distributors of free software have equal access to the deployed equipment.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 2:40 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
>> how exactly would you be sure the user saw this message and is what replies yes to it?
>> do you even know what video cards are installed in the system? let alone what mode they are in or which of the displays are hooked up to a monitor?
> Because it would be displayed by the firmware at boot time
but it's not boot time that you are installing the OS.
so do you give the warning the next boot after the change?
or are you trying to say that an OS install/upgrade should only be possible through the BIOS?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 13, 2012 1:50 UTC (Mon) by HenrikH (guest, #31152) [Link]
On the next boot of course, just like how Secure Boot detects an invalid key today.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 17:21 UTC (Sun) by khim (subscriber, #9252) [Link] And yes, "the industry" (how polite we are to not name names, I suppose) made an affirmative decision to unnecessarily deny the end users reasonable control over their devices. Wow. Just… wow. That's biggest load of bull I've ever seen. There are no names because this is not something which was decreed by someone but a wisdom gained through much suffering. Different companies reached this point at different time, but by now it's universal knowledge. It may be the only difference, but its the one that matters because its what determines if the owner of the hardware can choose to take control of it by authorizing a free operating system, and its what determines if all downstream distributors of free software have equal access to the deployed equipment. Indeed. Now, please, explain why you are trying to push for the solution which makes owner absolutely powerless? P.S. Before you'll start sputtering nonsense I want to point out that I've typing this on a laptop I don't own (my employer does) and I've first seen this discussion on a phone which I was not mine either (it's owner is a telecom company till I'll pay the rent for two year and it's ownership will be transfereed to me). You said your solution puts owner in control so obviously it should prevent my ability to tinker with these devices somehow… well how exactly it works?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 13, 2012 1:53 UTC (Mon) by HenrikH (guest, #31152) [Link]
It would probably work just like how you would protect the ability to add keys to Secure Boot today, i.e password protected access to the functionality by your admins. I.e, if you can add keys to Secure Boot then you also press Y to add the current boot loader to the acceptable list, there is no difference in security between the two.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 14, 2012 17:11 UTC (Tue) by khim (subscriber, #9252) [Link] It would probably work just like how you would protect the ability to add keys to Secure Boot today, i.e password protected access to the functionality by your admins. I.e, if you can add keys to Secure Boot then you also press Y to add the current boot loader to the acceptable list, there is no difference in security between the two. Actually there is a difference and it's pretty large one: there are no way to remotely push update in the scheme with password-protected boot loader whitelist. Which makes it, frankly, pretty useless for the absentee owner who does not have physical access to my laptop or phone.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 15, 2012 15:43 UTC (Wed) by HenrikH (guest, #31152) [Link]
Only if the mechanism would only be to whitelist the bootloader, what it could whitelist is the bootloaders certificate authority. There is no reason why this "Press Y to accept the current bootloader" wouldn't work exactly like the "Add custom key" in the BIOS menu.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 15, 2012 19:45 UTC (Wed) by khim (subscriber, #9252) [Link] At this point it's not simple "YOU APPEAR TO BE INSTALLING A NEW OPERATING SYSTEM. IF THIS IS WHAT YOU WANTED SAY YES" system but something similar to SecureBoot.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 15, 2012 20:10 UTC (Wed) by gmaxwell (subscriber, #30048) [Link]
Funny, because thats what I intended to be describing. If it didn't enroll a signing key you couldn't ever apply updates on an unattended machine, which would be pretty boring.
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.
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.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 15, 2012 20:56 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
The SUSE approach effectively gives you that, except for the single small binary object that you don't get to modify. Just pretend that it's part of your firmware instead of being on the media and you'll be fine?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 16, 2012 12:37 UTC (Thu) by anselm (subscriber, #2796) [Link] The unmodifiable-blobs-are-worse-than-builtin-firmware faction is so going to love this …
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 16, 2012 16:56 UTC (Thu) by khim (subscriber, #9252) [Link] 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.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 16, 2012 17:09 UTC (Thu) by gmaxwell (subscriber, #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.
|
|||||||||||||