Stop UEFI
kephra.de
kephra.de
We should totally endorse secure boot for "webiances." I have to invent a word here because we haven't coined one yet, but its a device you use to surf the web, read email, chat on facebook, edit our resumes, Etc. It is something hobbiests and experimenters never ever need to write code for. Its the thing our grandparents use and we don't have to worry that Rico from Brazil is going to clean out their accounts with. It is an information telephone/tv/typewriter, it is an appliance.
Few people complain that you cannot boot unsigned code on the computer in your BMW, that is a good thing, you want to trust your car.
That said, there should always be (and no doubt will be) computers that engineers, hobbiests, and others use which are completely programmable. Those will be distinguished as being "General Purpose" computers as opposed to "Task specific" computers. They may even share the same instruction set architecture with their counterparts, but it should be perfectly Ok for a task specific device to refuse to run any code that hasn't been verified though some system of trust.
The comments about unlocking phone bootloaders, or the iPad, are quite relevant here. Those devices, when locked, aren't general purpose computers. Locked they can be task specific and reasonably safe [1]. Without such barriers they put their users at unnecessary risk and for users who have neither the ability nor the time to understand the risks that is a good thing.
[1] "reasonably safe" - This discussion will often jump to 'nothing is 100% secure' which is true of course and not the point. Planes fall out of the sky and kill people, but they are 'reasonably safe' which means that the risk of them killing us is acceptable given the benefit returned. Similarly with cars. Computers these days are not 'reasonably safe'. Huge swaths of non-technically literate people are harmed every year by the inability to create a reasonably safe environment for them to use.
The Apple ][ cost $1200 at release. In 1977.
Look at what you call "innovation" today, what is it? Nothing about having locked down computers will prevent random folks from creating another Instagram. Look at the demo day for YC, how many of those demos require that the people install new program code on their "customer's" computer?
But a fully general purpose piece of hardware, could become much more expensive in the future.
I don't know, maybe 20 years ago average young computer hobbyists were writing small OSes, but today, people write websites and mobile apps. 20 years ago everything was simpler. You could learn about ins and outs of 8086 in a week, and it was "practical" to have such low-level access to hardware. Today, the landscape has changed. We should change too.
The other weird thing about this discussion is that none of the hobbiests in 1977 were concerned with the fact that you couldn't root an IBM S/370. They didn't need too, they just built their own computers. That said, anyone could get complete access to an IBM S/370 (one of my summer jobs at IBM gave me full control over one, right down to what microcode we were going to load that day) so the tools to 'create applications' will no doubt continue to exist.
What will change is that there will be a device that people use to communicate and play games and stuff which you can't just buy, install your own ROM image, have it do that other stuff and the stuff you want too. Not that scary.
You also toss out with the bathwater virtual machines. You can boot a virtual machine where the hypervisor is 'signed' on a machine which gives you 100% access to your virtual machine that can do most anything you might want, from talking to the network, to displaying graphics, to running the latest fizzbuzz contender.
My guess is that wmf's is correct, the relatively low volume of 'general purpose' computers will cause the cost to rise but I doubt it will ever be impossible to put one together.
My point being, I doubt that this was your first encounter with programming a computer, and even if it was, you are in the extreme minority, even on HN.
>You also toss out with the bathwater virtual machines. You can boot a virtual machine where the hypervisor is 'signed' on a machine which gives you 100% access to your virtual machine that can do most anything you might want, from talking to the network, to displaying graphics, to running the latest fizzbuzz contender.
Ah, where is this VM i can run on an unrooted ipad?
I don't doubt for a minute that my kids, should they choose to, could use a terminal application on a securely booted appliance device to access a computer 'instance' somewhere in the cloud (an EC2 instance perhaps). No need to root my iPad.
If you look at the Beagle board, or the RPi, or the Pandaboard or any number of 'kit' computers, they are still out there in numbers, and there will always be a market for them. And, depending on your level of sophistication you may start with a webiance and remove or simply access its internal compute engine with some other bit of code. Nothing UEFI can do, cannot be undone with a JTAG loader and new firmware. But it won't be useful for running those standard applications any more. Just like the TV I hacked into so that I could display video directly that was generated by my Z80 system ever tuned in TV shows again after that.
Plus, it's hard enough to get people to switch to Linux now as it is - telling people they need to buy new computers, that'll reserve Linux purely for geeks at a time when it is starting to appeal more and more to consumers (though admittedly, not quite there yet).
None of the security and simplicity arguments hold any water because no one asks platform/device vendors to provide support to someone who decided to replace the OS or guarantee their security.
I'd claim that people selling a platform have established the set of things such a platform can support. So a Ruby 'platform' only supports Ruby programs, a 'Facebook' platform only supports Facebook Applications, an Android 'platform' only supports Android applications. In contrast a general purpose computer can host any platform, even multiple platforms simultaneously.
Smartphones and tablets are sold as a way of running any program that can run within the constraints of that platform.
General purpose computers are sold able to run any program you can think up.
I'd claim that 'General purpose computer' is a superset of the concept of 'Platform' and that nothing in the secure boot scenario prevents platform conformant applications from running on a platform (no 'taking it back') It does however give additional tools of platform limit enforcement.
http://www.apple.com/ipad/business/apps/
"[...] there's no limit to what iPad can do for your business."
That's what platform means. A basis for doing anything without a limit, not just some pre-specified set of tasks. They are expressly different than feature phones or kitchen appliances or automobiles.
Also, I don't understand the need. I've heard the excuses about malware, but is that even a significant problem? I know I've never booted up a machine and said to myself, "You know what I need? An upgrade to my BIOS."
I mean, it is purely and transparently anti-competitive. But why now? This is something the 90s, we're-deathly-afraid-of-linux Microsoft would do. So why now and not then?
Its similar like a dictator shooting at civilians at the moment he realized that he lost the love of his people.
Then why did they make it so that to get your x86 hardware certified and allowed to use the Windows 8 logo, you are REQUIRED to provide a UEFI setting to turn off secure boot and to allow the user to remove and add keys?
If they are trying to prevent people from running Linux or Windows 7, you'd expect them to leave it up to the OEM whether or not secure boot can be disabled or the keys can be modified--knowing that many OEMs would not bother, rather than explicitly requiring the OEMs to allow that.
If they were trying to do this, all they'd have to do is tell OEMs to only allow the system to boot with Windows bootmgr. No fancy signature checking required! And they could have done it at any point in the past, even with BIOS.
Are you serious? It's mandatorily configurable. Are you suggesting that Secure Boot just not be implemented by motherboard manufacturers? Or rather that Microsoft should just pretend it doesn't exist?
Secure Boot is quite a useful part of the UEFI specification, albeit maybe not in the average case. I should hope it doesn't get ignored just to satisfy conspiracy theorists.
The most dangerous malware is now produced by states.
If RedHat and Ubuntu can pay their us$99, I guess NSA, BND, CIA, Mossad and others can also. So secure boot is not adding any security, imho. There was already the case that Microsoft implemented a backdoor in NT export versions for NSA 13 years ago.
> 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.
Anyway, the latter claim is purely conjecture. Why would they change convention once everyone has already implemented all this standard/custom mode stuff that they require for 8?
That is exactly what Microsoft mandates for secure boot for Windows 8 certification. Please stop spreading misinformation.
There was conspiracy theory speculation that they did so, if it is _NSAKEY that you are thinking about, but few competent cryptographers or security researches took that seriously. Typical responses were like this: http://www.schneier.com/crypto-gram-9909.html#NSAKeyinMicros...
Pasted from one of my earlier comments:
Here are some references about boot malware which UEFI secure boot can prevent.
http://www.chmag.in/article/sep2011/rootkits-are-back-boot-i....
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_....
http://www.computerworld.com/s/article/9217953/Rootkit_infec....
I recommend reading atleast the first link.
Here's one juicy bit:
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.
The problem is not overwriting MBR; the problem is privilege escalation (in this case, ability to install it's own driver without user's knowledge). The operating system has means to make all processes behave. So now Microsoft throws up hands and says, that they cannot make Windows secure?
What a stupid idea.
What happens next, you think? OEMs will hug you and other Linux users and kiss you? No, they won't issue driver updates. And your graphic card is useless. If you (Linux users) cost them too much, they'll dump you. It's business, nothing personal.
But, of course, it's open source. You can always write the drivers yourself.
-----
By the way, it's very funny that a "forward-thinking, open source-loving" guy who (supposedly) wants to make computing world better, doesn't think it's absolutely immoral to do such a stupid thing. You ruin the cables, and the company has to pay for it. The CEO doesn't pay the money from his pocket you know, they increase the price for "all" customers a little bit, so it's Dell (or other OEM) customers pays who are paying money for your stupid "cause".
Anyway, my point was that if Linux guys prove to be costly, they'll be dumped or neglected. It's bad for open source guys, it's bad for OEMs (they get worse deals with Microsoft), and it's bad for everyone other than Microsoft. So, if you think SecureBoot is bad, make your case like civil citizens without inducing cost to others.
I don't actually support the kind of crude protest measure suggested by the article (although I doubt a non-negligible number of people will actually carry it out in any case), but drivers really aren't the issue here.
There's nothing worrying about it. What's happening is what used to be general purpose is now becoming an appliance.
Until Cory is out there petitioning blender makers to open their firmware, he's just grabbing headlines with this nonsense.
http://craphound.com/overclocked/Cory_Doctorow_-_Overclocked...
Anyway, no, the problem is that other people get to decide what software you get to run on your computer. And those people aren't engineers who want to build cheaper and more convenient, if limited, appliances. The people who will be deciding what software you can run are the lawyers and congressional lobbyists.
There's nothing worrying about it. What's happening is what used to be general purpose is now becoming an appliance.
I find the prospect of Apple or Microsoft having veto power over how I use "my" computer extremely worrying.
Until Cory is out there petitioning blender makers to open their firmware, he's just grabbing headlines with this nonsense.
The manufacturers of blenders are generally not advocating that taking them apart should be a federal crime.
Yes, and that sucks. But that's just Windows, and there are other options. For now.
This is because we expect "computers" to do so many things. When their area of responsibility shrinks to more trivial tasks, like only browsing or running simple apps, the limitations become less of an issue.
There will always be a need for a "development" caliber platform where you can do whatever, install anything, build whatever you want.
It's just that for 90% of the people out there, they don't need or want this. While I find it amusing that grandma's new MacBook Air comes with a C compiler, bash, and Perl, this really isn't something she's ever going to find a use for and would hardly notice if it was absent. For the 10% of the market that does care, perhaps they need a different sort of product. The two markets are destined to split.
Well, Erich Fromm criticized the death of rationality and the rise of the purely manipulative and blind intelligence a decade before that. Bleh to integrated circuitry: we're so far away from ourselves that even we became a black box, accepting a neverending, meaningless stream of impressions which we compare with other impressions, but not ever understand.
So yeah. That this now takes on physical manifestations isn't exactly surprising if you've paid attention.
IMHO they're both right, and "they're criticizing something I assume to be beyond criticism", isn't an argument. Neither is "this could have been extrapolated before".
"he's just grabbing headlines with this nonsense."
Ahhh, sweet complacency, and the peaceful dreams of those who don't.
And I think we have to fight them early, before its to late.
Not exactly: http://sourceforge.net/apps/mediawiki/tianocore/index.php?ti...
(b) The bits of TianoCore source that I've read are overcomplex and ugly. There's no reason for a bootloader to even have all this stuff.
(c) That's not the UEFI implementation I have on one of my servers which AFAIK is completely closed source, and does all sorts of weird stuff when I boot. I reverted the machine back to plain BIOS "boot the first sector" booting.
b) Not knowing what exactly you've read, I don't know if I'd agree, but anyway, it just implements the UEFI spec.
c) As far as I'm aware, all UEFI implementations are built on top of TianoCore. But as it is BSD-licensed, the OEMs don't have any obligation to release their source code.
I really think that UEFI is superior to BIOS in every way. It could also be open, except that hardware manufacturers choose to keep it closed. Not allowing user keys for Secure Boot is, also, a decision of Microsoft and manufacturers, not a problem with UEFI itself.
Tianocore "just implements" the UEFI spec, but that's what is overcomplex and ugly. Also, Tianocore picks the ugliest possible way to implement things (or at least, they really try to).
UEFI SecureBoot on Intel/AMD is optional and will not deliver on its promises IMHO.
The REAL thing to focus on (and the one thing that all of these doosmday guys seem to willingly ignore) is that on the ARM platform it is truly worse what the Windows requirements are enforcing - locked bootloader, no way to change that. So instead of whining about an OPTIONAL problem, how about fighting a REAL problem?
TPM was widely misunderstood (thanks to the Anderson "TCPA FAQ", which went into hyperbole real quickly). It was also defused a bit due to public pressure.
With the Windows Logo Requirements (which are the real issue surrounding secureboot), there are some indications that things will end up bad, but that's speculation (but on a better foundation than the TCPA FAQ back then IMHO). What's going on now is public pressure - and it already worked to some degree, since the Logo Requirements went from "has to provide it, disabling optional" on x86 to "must allow disabling secureboot".
Not to mention the ethical issues here.
For crying out loud. Nothing can stop LinuX.
Not even spelling mistakes.
hint: it's spelled Linux
The main issue is the MBR format which doesn't allow >2TB easily (there are hacks, but those break with older systems). It would be perfectly possible to teach BIOS GPT, and use the boot sector of the system partition for booting (ie. what happens today).
2TB disks are just the excuse to finally force the issue (after about 10 years of promoting EFI without much success).
>This is most easy from Germany, where we have a law that allows us to send back any mail order, internet order or things that had been sold at the door or on phone within 14 days, and charge our money back. So my suggesting is doing this at the moment the first computers ship that are locked to boot only Microsoft systems. Order them, unpack them, ruin the paper and cardboards, and send them back with a note: Can not install Linux.
>The same can be done by people who have an American Express credit card, within 30 days worldwide, I think.
Please think twice before doing that, this will just make the OEMs think that a section of Linux users are mean and just too costly to support. I prefer that some other way of indicating support for Linux is used, like buying hardware with preinstalled Linux.
>It also won't help much if major distributions like Ubuntu or RedHat get a signed key into the boot loader, because UEFI will prevent any normal Linux system programmer from installing his own self compiled operating system.
Huh what? Doesn't Microsoft mandate(to the extent they can, because of antitrust laws) that secure boot be able to be turned off and users be able to add their own keys? Or is the author talking about the slippery slope of the mysterious future?
On x86, but not on ARM. And that's quite possibly more important, because ARM platforms are likely porting targets for things like Android that "regular users" might actually want.
After all, it's my goddamn tablet that I'm buying.
I'd even be happy if it was a hidden switch like on the first Chromebooks.
Without Linus tinkering on his own machine back in the '90s, we may have never had Android today. We may have never had OS X on x86 if the random apple employee hadn't decided to try to do it one day.
I support the ability to make, modify, and create. Having good products is important, but let's not sacrifice too much.
Cars still have hoods, even the fanciest ones. Let's not put locks on the computer equivalent.
They publish the Linux kernel for their Android phones, complying to GPL. But the lock the boot loader, preventing everybody to install its own kernel.
[1]: https://play.google.com/store/devices/details?id=galaxy_nexu...
If it were guaranteed to always be user configurable, forever, I would actually be quite enthusiastic about secure boot.
Another problem is early indications are that disabling secure boot on many of these machines involves re-flashing the firmware entirely, with a ton of steps, and a lot of room for "buggy" behaviour
Compare something like CableCard https://en.wikipedia.org/wiki/CableCARD, where before the FCC mandated that all receivers must use it, people with HD TIVOs would regularly go through dozens of cards because they stopped working randomly, a complete coincidence of course...
I think its atrocious that Microsoft has turned a supposedly open standard (UEFI) into a standard that gives them complete control of modern PCs.
Its easy to obscure the real issue with discussions about rootkits and security, but these infact have nothing to do with how the exact specifics of this particular technology are implemented, and the problems that result.
This a classic example of the syllogistic fallacy (we must do something -> this is something -> we must do this). These issues need to be separated.
The real question is, why should this obvious conflict of interest even be allowed to exist.
The law exists to protect consumers. I think abusing it to further political goals is just a bad idea.
Surely, if UEFI is indeed the remedy people claim, then having it on as many computers as possible would be a good thing. That you can turn it off is only a surrogate for having an actual workable solution that gives fair access to computer hardware to different operating systems.
Microsoft has a huge malware problem.
Because they are a huge bureaucracy, they are looking for solutions through control.
This is understandable. That's what bureaucracies do. It won't work, of course.
The problem is that Microsoft's huge security debt (by analogy to technical debt) has historically been paid by its customers. The real reason that your bank is running Windows XP SP4 with IE7 (the new browser, they just got it last month) is because their IT folks are paying down Microsoft's debt. If Microsoft Office file formats didn't contain executable code (historical legacy: debt) and the OS didn't inconsistently confuse file extensions with file formats (historical reasons: debt) and email didn't default to HTML (so you can get a pretty blue underlined Comic Sans signature line) piped through 90% of a full browser (historical reasons: debt), then half of their problems would go away.
The other half are deeper and more systematically rooted in their architecture decisions. Still, it's Microsoft being Microsoft. Their products carry hidden costs, just like light bulbs that become toxic waste. The consumer pays the price, one way or another.
Part of the UEFI standard allows a "Do you trust this program?" popup for untrusted media when secure boot is enabled, which would make a lot more sense in this context. If your windows image is modified, it would essentially brick the computer otherwise. A popup would still scare users enough to get their computer looked at (if they didn't know enough themselves), or to be able to say "yes I trust this" if it is a linux system or a different setup (like windows 7, for example).
(Not to get in the way of anyone's pitchfork of course.)