> Their stated concern is that someone might ship an Ubuntu Certified machine with Restricted Boot (where the user cannot disable it). In order to comply with GPLv3, Ubuntu thinks it would then have to divulge its private key so that users could sign and install modified software on the restricted system.
> This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine.
That's because like pretty much everyone who is not the FSF, Ubuntu has not actually carefully read the part of GPLv3 that deals with software that requires signing in order to install. Almost everyone just seems to skim through that section, sees something about having to provide keys, and then moves on. They don't read the definitions that define the terminology used in that section, and so have no clue whatsoever about what they have just read means.
I can kind of excuse it when it is just random end users or individual software developers who don't understand the license they are using...but one of the leading Linux companies!?
Another place you see this problem is in discussion of the incompatibility between Apple's App Store and GPLv3. There are people who still think the signing requirements have something to do with it. They do not. The problem is Apple's terms and conditions, which Apple requires end users to agree to before being allowed to use the store, count as additional terms under GPL (both v2 and v3) that are incompatible with GPL. The GPLv3 restrictions on distributing signed code without the signing keys would only apply to GPLv3 code that Apple ships bundled with iOS devices.
> That's because like pretty much everyone who is not the FSF, Ubuntu has not actually carefully read the part of GPLv3 that deals with software that requires signing in order to install [...] I can kind of excuse it when it is just random end users or individual software developers who don't understand the license they are using...but one of the leading Linux companies!?
In response to:
"Have you talked to the FSF about their position on this? They're the
sole copyright holder of grub 2, so any position they'd publicly take
would be pretty relevant in terms of potential legal action."
The reply:
"I haven't been privy to all the mails on this, but in the ones I saw,
the responses were distinctly equivocal at best. They certainly didn't
say that we were safe, rather the reverse."
I think the problem is it doesn't matter how carefully you read the GPL v3, you still can't understand it. The license is complex and inconsistent in important ways and applied mechanically and literally leads to bizarre conclusions (such as that it is incompatible with the BSD-style licenses but not the MIT license).
I have discussed this matter both with folks like Richard Fontana (involved in SFLC, general counsel for Red Hat, and one of the drafters of the GPL v3) and Eben Moglen (SFLC, FSF, and one of the drafters of the GPL v3) and their understandings of key provisions was not only different but incompatibly so.
Here's the problem: the SFLC's official view, which is also the view of many developers who use the BSD-license, is that the BSD license does not allow a license change on the original code, but only allows restrictions to be placed on new code. Therefore if you write a program and release it under the BSD license, I can change the license to the GPL (any version) when, and only when, I actually make copyright-worthy changes to the code. Anything short of that and I am impermissively sublicensing your code, as prohibited in US copyright law. Now, slowly read the GPL v3, section 7, on additional terms.
Section 7 outlines a few areas where additional restrictions are permitted, and also addresses additional permissions. Since the work as a whole must be licensed according to the GPL v3, this would apply to any modules the work is dependent on, by the terms and definitions of the GPL v3, and additional permissions must be removable without changing the code. Earlier drafts allowed these permissions to be removed only when changing code but this was removed in a later draft. The BSD license does not allow this, and therefore it is incompatible. OTOH, the MIT license does allow it and so is compatible. Oops.
Except that everyone agrees the licenses are compatible. Moglen says that basically you can claim anything you want but nobody can sue you for it (sorry, I am not betting my house on that). Fontana says that the license was intended to be compatible and therefore must be read to be compatible, that one cannot safely convert BSD files to the GPL without modifying them, and that the GPL v3 should be read to accommodate this restriction. What a mess that opens up. Now we have to read the GPL as explicitly authorizing things it says it does not authorize.
So given my time trying to figure the GPL v3 out (and I have slowly read it more than a few times) I will give Ubuntu the benefit of the doubt here. The GPL v2 has problems too, but I would pick the problems of a license which is, perhaps, too simple over one which is undeniably too complex.
Now, my reading of the GPL v3 here is that Ubuntu would only possibly be off the hook but every distributor of Ubuntu-certified computers would have to release their keys. Moreover I am not convinced entirely that if a distributor failed to that Ubuntu could not be held accountable. If it's copyright infringement, Ubuntu is a vicarious infringer unless they did everything reasonably within their power to stop it. They have the power to require the vendor to distribute the keys, and they have a financial incentive. That makes them responsible. Worse if they told any distributor "you don't have to distribute your keys" that might make them guilty of Grokster-style contributory infringement.
I am not convinced Ubuntu would be safe at all. More likely depending on what was in the agreements, they might be held accountable along with the distributor.
I would prefer not to be "protected by a GPL licensed bootloader" from having a machine actually boot successfully under default conditions.
Pretty much ok with Fedora and Ubuntu making the best of a somewhat bad situation. I wish they'd just fix the standard to allow multiple signatures on code and extensions, though. With that, Secure Boot would be basically all positive.
Do we really need UEFI? I believe that there is simpler ways to achieve this. For example:
a. User turn ON a switch to enter "OS Install mode"
b. User install the OS of his choice. During installation the installer read a motherboard specific key from the BIOS and sign his bootloader/kernel/drivers using that key.
c. User turn OFF the "OS installation switch". System is save (at least as long as the OS in choice is not a Redmnond one)
Is there any fundamental problems with this approach?
It seems that UEFI is supposed to protect against malicious actors who have physical access to your machine.
Of course, you're also assuming that securing the end-user is the actual goal of UEFI. ;-) I can see legitimate situations where a corporation would want to ensure that their employees aren't tampering with their hardware.
Of course, I think it's fairly obvious by now that one of the main reasons that MS is pushing UEFI at this point is to prevent Android from being installed on "Windows" hardware.
If someone have physical access to my machine he/she can install keys if the BIOS supports that anyway. And even if it doesn't i have many more things to worry anyway. UEFI don't protect me from stealing the machine or the HD data or installing mallicius software.
Of course, i totally agree with you on that the reall reasons is for MS and hardware manufactures is trying to control MY hardware.
One possible solution to this problem is for the FSF itself -- or perhaps another non-profit organization with similar goals but a more flexible stance -- to get in the business of issuing Secure-Boot keys, backed by a public written policy of non-discriminatory key issuance. Such an organization could work with non-mainstream operating systems to get hardware vendors to adopt its keys. For example, Ubuntu and Red Hat could use keys issued by it.
All non-mainstream operating system projects would be able to request keys from this organization and boot without having to resort to tinkering in UEFI hardware from multiple vendors.
Just assuming that the current UEFI working group agreed to this, the first problem arises when one of the key holders is compromised.
As a possible scenario: what if the Windows 8 private signing key leaked because it was used in Terminal Server somehow - do you want the FSF revoking the Microsoft signing key, thus invalidating UEFI signed drivers (necessary for boot) from hundreds of OEM's?
We can shortcut all this by supporting www.coreboot.org
sounds: coreboot.org is a worthwhile cause but unfortunately, for better or worse, whether we like it or not, most hardware vendors have decided to adopt UEFI.
Shady deals aren't needed. Intel can just make UEFI cheaper than BIOS by providing sample code for one and not for the other. Coreboot was never even on the OEMs' radar.
I have a CR-48 and it already solves this problem. Joe User get a secure, verified boot path by default. If you want to bypass this and use your another operating system, load your own keys, or generally prove that you know what you're doing, you:
1. Flip the machine over.
2. Remove battery.
3. Flip the "developer's mode" switch.
Also, anyone having physical access to your Chromebook can flip that switch and compromise your machine. While you can set a bios setup password to guard against someone flipping the secure boot switch.
>Gain physical access to Any machine, and all security bets are off.
That's not guaranteed. For example, see Droid Milestone's locked bootloader and XBox 360 (recently broken with a cpu bug).
>But what if the attackers has physical access and simply reflashes the BIOS?
Security is all about raising the bar, reflashing takes a lot more time and effort than flipping a hardware switch and inserting a USB key.
Also, a physical switch is harder to implement in a consistent manner for low margin OEMs(who all buy the firmware from the same source), thus a software setting is better. For example, including such a switch on a tablet like the Microsoft Surface Pro will increase the costs and restrict design.
> That's not guaranteed. For example, see Droid Milestone's locked bootloader and XBox 360 (recently broken with a cpu bug).
I was originally going to say, "Well, that's a different matter entirely."
It's not really, though. It's taking longer and longer for people to hack "secured" hardware.
The lesson of the PS3 still stands, though. If you let the hacker community install what they want, then they may not even bother to hack your hardware, unless you piss them off. The economics of hacking and security works like the economics of guerrilla warfare. You don't set up a highly visible and attractive high value target for an enemy that greatly outnumbers you. Doing that is just stupidity.
Guerrilla warfare is just as much about knowing what to cede as it is knowing what to attack.
Is secure boot really gone stop any malware? It will surly make it harder for anyone else to use a different OS. I mean malware is really a huge problem but isn't the majority of it, not related to bootloader.
>It will surly make it harder for anyone else to use a different OS.
Is it really that hard to go into the bios settings to change a setting? Already most people who want to boot a different OS have to do that to change the boot order to boot from DVD first.
For security purposes, wouldn't it be enough for the mechanism to simply display a change in the signing status, and not restrict boot? This would allow for the detection of malware without restricting how people use their hardware.
Displaying or dismissing such a notification needs to be built into the hardware in such a way that the OS wouldn't be able to interfere. There should also be a read-only channel for applications running on the OS to access the signing status to enable security programs.
If this is such a huge deal and users don't like it then there should be a market for machines that are not Windows Logo certified and run Linux. Given that there does not seem to be such a large market maybe those people that want to install linux on their desktop would be willing to pay more for the opportunity to do so.
Sandboxing has become increasingly popular and Microsoft is really the last one to the party. Most users (myself included) are happy with sandboxing. Apple has implemented this with great effect across its ecosystem.
All the actors are private organizations. No one is forcing anyone to buy a computer that enforces any of these restrictions. The FSF should try to understand why if this is such an important issue there does not seem to be a large market for Linux desktops. If there is a private actor can step in and provide the machines. If not, then you can always build your own.
One thing that will be interesting to see is if GPLv3 software slowly withers given that many embedded device makers will be unable to use it. I guess another cause may be Apple's continued rise as a platform of choice for both tablets and desktops/laptops.
While the FSF seems happy with the root Fedora is taken, it is interesting that every suggestion they make will make user's life harder.
I realise that they want to make software more free, and that this is broadly all Microsoft's fault, but I'll be honest as the years go by, I just get... tired. I just want to be able to install Linux as easily as Windows, and have it just work. I don't want to have to install extra keys.
That's kinda backwards. It's not the FSF that is pushing Secure Boot to begin with, but it is the FSF that is pushing for everybody to be able to install their Linux as easily as Windows and not only Fedora or Ubuntu users.
Crypto multiplies, or even exponentiates, the effort you take to secure something vs. the effort an attacker makes to break it. But if you put 0 effort into logging in to your computer (no password, or the same simple password for every website, etc.) it will be broken easily, because 0 to the power of anything is still 0. If your computer has restricted boot, your only options are to make some effort at keeping your computer secure, or let someone else make the decision of what to run on your computer. If you're looking for convenience at the expense of security, you should push back against Secure Boot being enabled by default (which Win8 "certification" mandates).
1) If the user can, but is scared away by a disingenuous message saying "Do you want to make your computer less secure by installing a non-Microsoft key (y/n)?", that would still be bad.
2) They can't on ARM-based machines that have a Windows certification.
First, Microsoft originally promised otherwise. "Pray I don't alter it any further."
Second, I and others have complained about Apple's lockdown for years. There's more leverage right now in pressuring others not to follow their example.
I don't own or plan to own an iPad. So the locking of the iPad is not affecting me directly. It is sad and silly imho that people is buying locked machines, but that's their right to do.
Now ARM boot restrictions from Microsoft directly affects me, as soon i can't buy any ARM based machine, given the way the markets work. And in the future it is a big possibility that i can't buy any other PC and put any OS that i like without pay directly or indirectly money to Microsoft. And i can see some foreign governments to use this technology to control the OS that her citizens runs, and install backdoors.
So yes UEFI secure boot is a treat to my freedom and not only my freedom to run the OS of my choice.
It's amazing. I read the first 3 paragraphs and the eff can't even acknowledge how much of a problem malware is for many computer users.
For the thousandth time: I know a computer user who almost had a $300k sum stolen because his laptop was owned. He has had to resort to having a second laptop used exclusively for accessing his business bank accounts in order to feel some security. He's not dumb: he makes more money than virtually anybody reading this and has an undergrad in math.
The computer security model for most users is incredibly broken. The alternate to secure boot is something like an ios app store for all apps. Users simply want to be able to run their computers without having to be constantly paranoid about spyware and malware. Microsoft is at least trying to do this, but the eff pretty much dismisses these very real concerns.
edit: for the record, I spelled fsf as eff before having my first cup of coffee.
How much of that malware is actually working at the level that the bootloader is concerned with? And how many samples are just trivial keyloggers, screen grabbers, enablers for fishing attacks, etc. that don't even need anything more than user-level privileges? I'd happily run a system with no standard antivirus / malware protection / ... as long as it has a good separation of resources from kernel to user-space. I subscribe to ideas like http://qubes-os.org much more than trying to protect the bootloader. The typical user-space is exposed too much at the moment and the number of really sophisticated exploits isn't that big.
You're saying "Microsoft is at least trying to do this" about a company that continues to hold up fixes to known exploits (maybe not publicly known, but it takes only a single person...) until a convenient patch day, but manages to push own idea of security which breaks other peoples' systems onto the whole industry (strangely those other systems are not affected to the same degree). That's what I would call a very real concern.
From my experience with the "typical user", migrating my gf's laptop from Windows to Ubuntu did more for security than any bootloader hardening could do. And it required no hardware update either...
>And how many samples are just trivial keyloggers, screen grabbers, enablers for fishing attacks, etc. that don't even need anything more than user-level privileges?
They need more privileges for hiding itself from antivirus software, SmartScreen and MMSRT.
That's true. Unfortunately that assumes the user 1. has an antivirus installed 2. his interaction with it isn't limited to closing the "license expired" window as quickly as possible at startup. That's still a very typical pattern.
Unless you can produce credible statistics showing bootloader malware, I'm going to call "strawman".
Bootloader signing is going to do NOTHING against the current threat model, which is all in the much higher levels.
Yes, an ios-app-store for all apps model IS effective against the current threat model (but also harmful to the computing economy at large). Secure boot, at this point, does ESSENTIALLY NOTHING against any of the worms / trojans out there.
TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.
When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.
The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.
The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.
The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows:
Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector.
Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object.
If kernel debugging is enabled then this TDL4 does not install any of it’s components.
TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.
All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.
Another bit:
The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.
But I don't think UEFI is going to make much of a difference, even against the next version of TDL4; In order to get installed in a system in the first place, it had some administrator permissions. What's to stop it from getting those permissions on win8?
From this article, the boot sector lets it hide better and earlier in the process -- but it wouldn't have been less scary to ordinary people even if it couldn't infect the boot sector.
The big thing is it is a half-measure against an emerging threat model.
Don't get me wrong, we need bootloader protection like this. However the approach that is being taken is wrong. This is the UAC of boot loader protections.... A half-assed measure that if Microsoft actually looked at what everyone else was doing they would have supported something different.
Consider the following scenario:
Spear-phishing attach aimed at the right individual compromises their computer through an IE exploit (never happens, right?) and steals the bootloader private key.
What's the response? If the key cannot be changed then overnight this fancy new protection has been rendered no protection at all. The key can then be sold for top dollar to malware programmers. The solution for the user will be to wait a few months and then buy a new computer.....
So you are right that the sort of implementation we are talking about will not make much of a difference long-term, but for a different reason: it offers no long-term security if the key cannot be rotated.
I don't doubt that something could be designed right, but I do doubt that such a design in security-critical aspects of computing will arise with Microsoft's cooperation.
it could get administrator permissions but, to run a device driver, the device driver needs to be signed. to patch a device driver on the system would invalidate its signature and that modified device driver would no longer load.
so you modify the boot loader, but now that is dead. so you modify ... what? now we're "done", there isn't any further down the stack to go, this is the "base" of the "trusted computing base". hooray!
On win7/64, you don't get permission to load unsigned drivers even with administrator (or at least, that's how it is supposed to be). So, once the system is up -- how did the worm modify the boot loader in the first place?
While it's true that with a trusted computing base (and tower), you could turtle all the way down to the boot, but unless something is already wrong (which can and will go wrong the same way even if you have a trusted base), UEFI secure boot should ONLY ever save you from pre-boot INFECTIONS, which I suspect are non-existent.
The best it could do for you for higher level attacks is make it harder for the malware to hide.
you don't need to load unsigned drivers to modify the boot loader, you can do that with administrative permissions alone (as far as I know).
the best you can hope for is locking out unsigned code. we have platforms that do that, like chrome OS and iOS. after many years, it seems they continue to work! but when we try and take this security technique that we know works and move it onto the computers that everyone uses, we are met with much wailing and gnashing of teeth.
> you don't need to load unsigned drivers to modify the boot loader, you can do that with administrative permissions alone (as far as I know).
Now, that's where the problem lies, not with the unsigned boot sector. On the existing win7 system, rewriting the boot sector and loading unsigned drivers are essentially equivalent permissions (elevating from the former to the latter requires one reboot).
> the best you can hope for is locking out unsigned code. we have platforms that do that, like chrome OS and iOS. after many years, it seems they continue to work!
At the expense of JITs on ios; and chrome OS doesn't yet have enough experience in the wild.
Also, locking out unsigned code doesn't stop stuff like "return oriented programming".
> when we try and take this security technique that we know works and move it onto the computers that everyone uses, we are met with much wailing and gnashing of teeth.
A chain of trust is known as a security technique that DOESN'T work, regardless of what it protects -- SSL forgeries are rampant, and the vulnerability is not in the algorithms.
The UEFI secure boot makes a small difference in real security. It will easily become as trustworthy as SSL certificates, meaning, not at all. And if the key ever leaks or is broken ... there is essentially no recourse other than buying a new computer.
There are ways to secure the boot in a way that's helpful for security without limiting choice. UEFI secure boot is not one of them.
I've had similar thoughts. I can make a fairly strong case that the best platform for me to access sensitive information from is iOS (specifically my iPad). It's sandboxed and comparatively secure.
Using Windows these days just seems like asking for trouble on the spyware/malware front. Some of it is your machine getting owned, other times its just missing a checkbox on a program install that installs a browser bar that does God knows what.
My Macbook Air is pretty much my computer of choice these days (with very little third party software). Soon Apple will require sandboxing on the Mac App Store too. Linux of course also being a much better choice than Windows from a security point of view.
On the browser front I can't see myself using anything other than Chrome. Part of this is feature-related and the whole one process per tab thing but it's also the most security-conscious browser IMHO (disclaimer: I work for Google but not on Chrome).
Well managed and secured Windows 7 is actually probably more secure than any other major desktop OS right now (iOS blows it out of the water of course). OSX is more secure out of the box for a single user deployment perhaps (largely due to being less of a target), but in a corporate environment, it's harder to really lock down OSX than anything else. Sadly.
This is the Free Software Foundation's position, not the Electronic Frontier Foundation's. Those are very different organizations. The fact that you confuse their acronyms (and also that you apparently stopped reading after three paragraphs) makes me worried that you are conflating their positions.
Also: how does secure boot prevent your laptop from being "owned?". It doesn't. I will bet a significant fraction of that $300k that the exploit used against your friend was not pre-OS malware.
The FSF, not the EFF. The EFF is generally much more reasonable (moderate?) about things like this; the FSF is generally more in line with Stallman's views (radical or crazy, depending if you agree with him).
I still see the FSF as a bit... idk... zealous? delusional? deliberately blind?
The basic problem is that the GPL cannot live up to it's goal in all cases unless it is backed by both a) software patents and b) a software patent license under the terms of the GPL. Absent that all you have is a license that allows you to do some things otherwise prohibited by copyright law. You have no restrictions beyond copyright law.
The problem here is that copyright law doesn't ban all copying and distribution. Notable cases in the US which allowed verbatim copying of part of source or object code in commercial products as fair use include Oracle v. Google and Lexmark v. SCC. In both cases the court basically said that 17 USC 102(b) precludes using copyrights to ban control secondary markets of practical tools.
So I read this as that in US law you do not need the copyright owner's permission to distribute software that links to a copyrighted library. If I want to link to GNU Readline with my proprietary app, 17 USC 102(b) protects me regarding US law, provided I dont distribute Readline myself. But hey, virtually every Linux distro ships with Readline so, what does it matter?
I don't know how fruits-of-labor jurisdictions address this issue but there is likely to be some line that prevents this as well. Otherwise Microsoft could say "Nobody can distribute MinGW for Windows 8 because no longer give permission to link against our system libraries for that version." No court in the world will give Microsoft that level of power, ergo I doubt the FSF has anything close to that either.
The GPL was designed to protect users, not developers. Under it, developers can't hide the source code from their users, can't prevent their users from modifying the programs they use and from helping other users with the code they have. If you statically link to a GPL'ed library, your code is GPL'ed, end of story. What Lexmark did was to use code as an excuse to prevent the formation of a free market. What Lexmark did is very close to what Microsoft is trying to do preventing the formation of a free market for operating systems for ARM devices.
you know, I use the GPL v2 for most of my code for reasons of history of projects, and the 2-clause BSD license where I can. I refuse to use the GPL v3.
As for what Microsoft did, I think the key case would be Chamberlain v. Skylink. There is going to be no DMCA issue with breaking secure boot because you can't show that this is access control in the way the DMCA intends it. If you can jailbreak your ARM tablet that will be seen as fair use even if it involves literal copying (see the US Copyright Offices opinion on fair use regarding jailbreaking iPhones by copying/modifying iOS). If not, at least there has been enough press for you to consider yourself fairly warned in advance. IOW, it's a technical measure, not one backed by force of law.
I don't mind the GPL v2. It's a relatively simple license. There is some ambiguity (if I statically link your GPL v2 module in my program and provide the source just for your module is that allowed?) but for the most part that's pretty minor.
The GPL v3 is a nightmare and I try hard to avoid touching it. I don't care how many times I slowly read the license, it never makes sense to me.
For example..... Can you include a 2-clause BSD-licensed module in a GPLv3-licensed program? If the BSD license is interpreted not to allow sublicensing or passing on only a subset of rights to the code (this is the official view of the Software Freedom Law Center btw), does that render the licenses incompatible as per the additional terms (particularly the additional permissions) requirements in section 7 of the GPL v3?
With the GPL v2 everyone had a general idea of what it meant and lawyers only really argued around the edges. With the GPL v3, I don't think anyone understands it. And the driver of this problem is the FSF trying to push copyright enforcement where, quite frankly, it doesn't belong.
>I know a computer user who almost had a $300k sum stolen because his laptop was owned. He has had to resort to having a second laptop used exclusively for accessing his business bank accounts in order to feel some security. He's not dumb: he makes more money than virtually anybody reading this and has an undergrad in math.
So what you saying is that just because you know some smart guy that owns a lot of money, UEFI is a good solution for fighting malware. I'm not so sure that UEFI is really gone help your friend to be more secure ... maby feel more secure though, which of course is a valid point but probably not because he will see thru it. Maby you friends laptop was due to a bootloader hack but there is easier ways to hack computer then that. I'm not saying that we shouldn't try to do anything about the risks but not this way, because this do only do it harder for everyone else.
Well maybe you should have read more of it? They explicitly acknowledge the benefits of secure boot - the concern they have is that it's possible for the current model to be used to prevent the owners of machines from being able to choose what their computer will run.
"can't even acknowledge how much of a problem malware is for many computer users"
What text are you drawing that conclusion from? It strikes me that they deliberately pass up the opportunity to disparage the security explanation for secure boot: "This claim ignores the fact that we need protection from them." Not "This claim is total BS."
The FSF statement acknowledges the security concern and brings up a competing concern. They ask that computer makers balance the two competing needs, and state that the plans for implementing secure boot on x86 will satisfy both needs. That's definitely not the blindly one-sided position you seem to think it is.
"I know a computer user who almost had a $300k sum stolen because his laptop was owned."
Was this unfortunate gentleman's laptop subject to unauthorised access by means of a compromised bootloader/bios? I have heard of very few exploits of that nature (but I'm not involved in supporting large numbers of machines).
I am no fan of what Microsoft is doing here, but it is an emerging threat profile and consequently some sort of boot loader signing makes sense. The exact design of course should be such that it is possible for users to update keys, however, because otherwise, once a key is compromised the whole system falls apart.
The concern is not that bootloaders/bios is compromised. It is that once the PC is compromised, the malware can load from the bootloader before the OS or antivirus can even load, and then hide itself from them completely, thus making it effectively invisible.
Think of it like a VM loader, an OS running in a VM may not even be able to find out if it's running on Linux or Windows, but the host can transparently see everything going on in the guest OS.
> It's amazing. I read the first 3 paragraphs and the eff can't even acknowledge how much of a problem malware is for many computer users.
Maybe because those who boot into environments endorsed by the FSF don't have a malware problem. I certainly don't.
That doesn't make me insensitive to other people's problems. But I have no sympathy for those who face such problems because they chose to.
I'll take it seriously when bootloader malware become the dominant model, because only difference is being harder to detect. Each and every malware I've seen is perfectly happy with user-level permissions and privilege escalation from within the OS and, once UEFI becomes the norm, I suspect signing keys will leak anyway.
Until we have 'personality' virtualization for os's, so you can have subaccounts, the model is shitty. Also, programs and users should be treated the same.
Not only that, but after calling secure boot basically useless for security, they turn around and want to secure their PCs against malware known as Windows using secure boot!
They didn't call it useless, they said it could be useful, if done correctly. From their point of view, if it were done correctly, the user ought to be able to block Windows. But since that will be difficult, it undermines the security advantages of Secure Boot. Their position is quite consistent.
>We will fight Microsoft's attempt at enforcing Restricted Boot on ARM devices like smartphones and tablets. Like any other computer, users must be able to install free software operating systems on these devices.
Again, a multi-thousand word essay on the topic of secure boot and lambasting Microsoft about the locked bootloader in the ARM tablets(which many of the same people think are going to crash and burn anyway).
Meanwhile, like in the RedHat and Mozilla blog posts about secure boot, not a peep about Apple or the iPad's locked bootloader which runs about 80% of ARM tablets.
Is this because Apple makes their own hardware so the FSF does not care? Or is it just their PR strategy that attacking MS is preferable due to media and people's favorable perception of Apple?
I see your point, the simple fact is dual-booting Linux-based operating systems on hardware intended for use with Microsoft Windows is the norm, and without this source of computer systems a free license is nearly a moot point.
If ARM becomes dominant the idea that Microsoft can simply restrict access because that's how it was done in the past (even citing Apple as an example) simply means they can restrict a majority of all hardware sold from running a different system, extending their monopoly control through partnership agreements to a new generation of hardware.
Generally, PC compatibles boot an OS from a sector on the hard drive and provide a standard interface to the bootloader to hardware (BIOS, PCI enumeration, and now UEFI). While ARM is now beginning to adopt a similar boot system (in UEFI on RT devices) it's not carrying with it the openness we once enjoyed with PCs. This is the problem.
>If ARM becomes dominant the idea that Microsoft can simply restrict access because that's how it was done in the past (even citing Apple as an example) simply means they can restrict a majority of all hardware sold from running a different system, extending their monopoly control through partnership agreements to a new generation of hardware.
If iPads take over computing and desktops(along with Microsoft) die, won't the same scenario play out? Also, if ARM becomes dominant, won't a secton of the ARM devices be iPads and Android tablets? Why do you think Windows RT tablets will be the majority?
>While ARM is now beginning to adopt a similar boot system (in UEFI on RT devices) it's not carrying with it the openness we once enjoyed with PCs. This is the problem.
As an aside, ARM is different in the sense that each ARM SoC needs special drivers and coding.
Would you be satisfied only if every article complaining about the actions of one company also listed every single other company that has done something similar? That would be tedious, as the FSF has criticized lots of companies for crap like this.
And users of ARM devices shouldn't have the freedom to choose which software they run unless it's one approved by the manufacturer and the companies it serves, right?
Did you even read my OP? I never said anything like that.
They're calling out the platform which has no marketshare and making zero mention of the iPad which has around 60 million tablets sold. FYI that's an ARM device.
So you mean they think iPad users shouldn't have the freedom of choosing which software they run but Windows RT users need to? Right?
I think iPad owners should be able to run whatever they want, but that's Apple hardware running Apple software, much like my Sony TV is Sony hardware running Sony spin of Linux. That's why I don't own an iPad.
UEFI secure-boot is Microsoft pressuring other companies, companies that have no reason to restrict their users (thus reducing the perceived value of their devices) into making their devices tied to Microsoft software. That'll result in thin margins for hardware makers because they won't be able to differentiate and will have to compete in price. Microsoft, of course, is the only one who will benefit from this because they'll be the only source of software (and upgrades) for those devices.
In the 80's, PC makers were dumb enough to commoditize the hardware while Microsoft reaped the benefits of fierce competition. I wonder if tablet makers will be stupid enough to make that same mistake.
>I think iPad owners should be able to run whatever they want, but that's Apple hardware running Apple software, much like my Sony TV is Sony hardware running Sony spin of Linux
How does this distinction matter to the user of the iPad? They buy a tablet, they're able to run only what it came with. How is it better for them because Apple sells the hardware too?
>That's why I don't own an iPad.
Then don't buy a Windows RT tablet. It's not like they forced the OEMs to cancel their Android tablets. LG and HTC did that themselves without even making Windows RT tablets.
>UEFI secure-boot is Microsoft pressuring other companies, companies that have no reason to restrict their users (thus reducing the perceived value of their devices) into making their devices tied to Microsoft software. That'll result in thin margins for hardware makers because they won't be able to differentiate and will have to compete in price
Is dual booting phones and tablets such a big differentiator that people will pay a premium for them? Why do many Android tablets and phones come with locked bootloaders? Why doesn't Apple unlock the bootloader and sell more or sell for a higher price then? Hint: 99% of users don't care
>In the 80's, PC makers were dumb enough to commoditize the hardware while Microsoft reaped the benefits of fierce competition. I wonder if tablet makers will be stupid enough to make that same mistake
This really shows off your inexperience and lack of knowledge. It's the other way around, Dell and Compaq wouldn't exist today if not for MS licensing them MS-DOS when they didn't have to. Because of MS, Dell became a fortune 500 company in just 6 years. Go read about how they started.
>I wonder if tablet makers will be stupid enough to make that same mistake.
You mean they just continue to sell only Android tablets(which seem to be low margin by the way, so blame Google?)) and it's not really making them any good money. LG and HTC already dropped out.
Also you're ignoring how users reaped the benefits of commodotization of the hardware leading to the PC and internet revolution and are focusing on just MS' profits.
Actually, they buy an iPad. Much like you buy a Mac (which is just an exceedingly well designed and built x86 PC). Yet, people don't go to Apple stores to buy a PC - they go there to buy a Mac.
> Is dual booting phones and tablets such a big differentiator that people will pay a premium for them?
Thanks to licensing, it's more likely users will pay a premium for a tablet that doesn't dual boot, that cannot be upgraded and that cannot be repurposed to run anything other than older Microsoft software.
> Hint: 99% of users don't care
And, as we all know, millions of Lemmings cannot be wrong.
> This really shows off your inexperience and lack of knowledge.
I will regard that as an insult and not answer.
> Dell and Compaq wouldn't exist today
Like Commodore, Atari and Apple never existed, because, of course, because computers started to become useful with the advent of MS-DOS. In fact, the x86 PC (and Microsoft) would not exist in its present form if it weren't for Dell and Compaq and a host of other makers who built commodity hardware. Without this huge market, Microsoft would have to address a myriad of platforms and be unable to concentrate on a single one. Before it became clear the x86 PC would be the mainstream of home computing, they even backed the MSX consortium which was all about compatible (read "commodity") hardware running Microsoft software.
It's possible to differentiate around Android. It's not possible to do the same with Windows. It's simple as that.
If you could grasp the concept, you would have by now.
>Actually, they buy an iPad. Much like you buy a Mac (which is just an exceedingly well designed and built x86 PC). Yet, people don't go to Apple stores to buy a PC - they go there to buy a Mac.
So, in the future, some people will buy a Windows RT tablet. If they want an ARM device, they can buy an Android tablet(hopefully not boot locked like many Androidf tablet).
>And, as we all know, millions of Lemmings cannot be wrong.
I never said they are right. I just stated a fact when you implied that the OEMs can sell dual boot as a feature for a premium.
>Like Commodore, Atari and Apple never existed, because, of course, because computers started to become useful with the advent of MS-DOS
Why is it not clear that Dell and Compaq are different from Commodore, Atari and Apple?
From Compaq's Wiki entry:
In November 1982 Compaq announced their first product, the Compaq Portable, a portable IBM PC compatible personal computer. It was released in March 1983 at $2995, considerably more affordable than the Canadian Hyperion. The Compaq Portable was one of the progenitors of today's laptop; some called it a "suitcase computer" for its size and the look of its case. It was the second IBM PC compatible, being capable of running all software that would run on an IBM PC. It was a commercial success, selling 53,000 units in its first year and generating $111 million in sales revenue. The Compaq Portable was the first in the range of the Compaq Portable series. Compaq was able to market a legal IBM clone because IBM mostly used "off the shelf" parts for their PC. Furthermore, Microsoft had kept the right to license the operating system to other computer manufacturers. The only part which had to be duplicated was the BIOS, which Compaq did legally by using clean room reverse engineering at a cost of $1 million.[12][13][14] Phoenix Technologies would shortly follow their lead, but soon "clone BIOSes" were available from many other companies who reverse engineered IBM's design, then sold their version to the PC clone manufacturers.
What about Dell then?
Dell traces its origins to 1984, when Michael Dell created PCs Limited while a student at the University of Texas at Austin. The dorm-room headquartered company sold IBM PC-compatible computers built from stock components.[7] Dell dropped out of school in order to focus full-time on his fledgling business, after getting about $300,000 in expansion-capital from his family.
In 1985, the company produced the first computer of its own design, the "Turbo PC", which sold for US$795.[8] PCs Limited advertised its systems in national computer magazines for sale directly to consumers and custom assembled each ordered unit according to a selection of options. The company grossed more than $73 million in its first year of operation.
The company changed its name to "Dell Computer Corporation" in 1988 and began expanding globally. In June 1988, Dell's market capitalization grew by $30 million to $80 million from its June 22 initial public offering of 3.5 million shares at $8.50 a share.[9] In 1992, Fortune magazine included Dell Computer Corporation in its list of the world's 500 largest companies, making Michael Dell the youngest CEO of a Fortune 500 company ever.[10]
>In fact, the x86 PC (and Microsoft) would not exist in its present form if it weren't for Dell and Compaq and a host of other makers who built commodity hardware.
It's clear that there would be no Dell or Compaq without MS licensing DOS to them. I am not saying MS did it for charity(they did it as a strategy that worked superbly well), but to imply that Dell and Compaq shouldn't have let MS commoditize hardware is not correct either. They didn't ship hardware to do charity work for MS. They made huge profits doing so.
>It's possible to differentiate around Android
Like what? Install bloated skins and junkware that can't be uninstalled? Atleast most Windows junkware is uninstallable. See HTC, their customers have zero loyalty to them and switched to Samsung.
Which Android OEMs are differentiating with great software and beating their rivals? Why are they utterly failing at competing with the iPad?
> It's simple as that.
>If you could grasp the concept, you would have by now.
You mean the concept that people are so sick of the OEMs Android modifications that they're willing to pay a premium for stock Android and still the OEMs ship their crap unless it's a Google device? Sounds like the reverse of what you claim is true.
Trying to enlighten you is, sadly, a waste of time. Oddly enough, time has a good chance of curing you, so, I don't need to waste mine trying. In a couple years, you'll probably be more permeable to reason.
> This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine.
That's because like pretty much everyone who is not the FSF, Ubuntu has not actually carefully read the part of GPLv3 that deals with software that requires signing in order to install. Almost everyone just seems to skim through that section, sees something about having to provide keys, and then moves on. They don't read the definitions that define the terminology used in that section, and so have no clue whatsoever about what they have just read means.
I can kind of excuse it when it is just random end users or individual software developers who don't understand the license they are using...but one of the leading Linux companies!?
Another place you see this problem is in discussion of the incompatibility between Apple's App Store and GPLv3. There are people who still think the signing requirements have something to do with it. They do not. The problem is Apple's terms and conditions, which Apple requires end users to agree to before being allowed to use the store, count as additional terms under GPL (both v2 and v3) that are incompatible with GPL. The GPLv3 restrictions on distributing signed code without the signing keys would only apply to GPLv3 code that Apple ships bundled with iOS devices.