Stop UEFI(kephra.de)
kephra.de
Stop UEFI
http://kephra.de/blog/Stop_UEFI.html#en
88 comments
I disagree strongly with this type of argument, nobody starts out a "computer professional", we all get there by experimenting on commodity hardware. With this type of proposal you essentially make it impossible for a user of a regular device to ever advance beyond the walled garden.
You seem to toss out the history of computers. I owned my first computer when I was in high school, I soldered it together from a kit (it was based on a Z80). Today I can do the same thing with an ARM chip (in fact I've been playing with the ST micro STM324F 'butterfly' which is a Cortex-M4 architecture.
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.
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.
You're very lucky. My first computer was an old Dell that my parents were planning to throw away (as it was slow) but which I rescued and, whilst looking for ways to speed it up, stumbled across Ubuntu. That's how, aged 13, I first got into Linux. If we had been using computers with secure boot, I assume I would still have gotten involved with computers, but quite possibly at a much later stage and I highly doubt I would be at the same level I am now.
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).
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).
>You seem to toss out the history of computers. I owned my first computer when I was in high school, I soldered it together from a kit (it was based on a Z80). Today I can do the same thing with an ARM chip (in fact I've been playing with the ST micro STM324F 'butterfly' which is a Cortex-M4 architecture.
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?
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?
My first experience programming a computer was running FOCAL8 on a PDP8 that an engineer that was working with my Mom let me use because I was so bored waiting for her to be done with work and to give me a ride home from school. The second computer I programmed was running BASIC programs that I typed in on an ASR33 Teletype that was connected to a mainframe at the school district headquarters.
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.
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.
So I guess the standard counterargument is that if these "webiances" are allowed to be sold (oops, too late) then they will take 99% of the market and PCs will increase in price to the $2,000-$5,000 range and then all innovation will stop.
High prices didn't stop the first wave of computer innovation.
The Apple ][ cost $1200 at release. In 1977.
The Apple ][ cost $1200 at release. In 1977.
This.
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.
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 agree wholeheartedly.
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.
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.
If in 1977 a locked-down Micro-Soft Surface cost $120 and an Apple ][ cost $1200, would history have been different? Perhaps not.
It is an interesting question, in 1977 the closest analog would be a 'locked down' color TV versus the Heathkit build your own color TV kit.
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.
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.
The problem with your argument is that smartphones and tablets are sold as general purpose computers. They are sold as platforms. The tasks they perform are open ended by design. You can't just take that back.
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.
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.
Lets look at that for a moment, your first claim is, if I understand it correctly, that someone selling a "platform" is bilaterally equivalent to "general purpose computer."
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.
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.
That sounds pretty contrived to me, even tautological. Technically these tablet computers are as general purpose as it gets. That's why it takes extra effort on the part of vendors to limit what you can "naturally" do with them. But we're talking about what they are sold as. So here's an example:
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.
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.
I honestly don't understand how this can be legal. There's precedent, at least in the US. The Bell system was forced to allow non-AT&T hardware on their network. Automobile manufacturers were required to allow third parties to service vehicles.
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?
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?
> I honestly don't understand how this can be legal.
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.
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.
Secure Boot might be a useful part, if everybody could add his own keys to his own board, and delete existing keys for Microsoft and others. But one has to pay to get his key signed by Microsoft. This is comparable to install own software on an iPhone, where one has to pay Apple to unlock a devices.
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.
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.
> There was already the case that Microsoft implemented a backdoor in NT export versions for NSA 13 years ago
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...
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...
Actually, the Logo requirements specify that you must be able to add your own keys:
> 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.
> 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.
You can not change the boot loader on ARM for Windows 8.
And you likely can not change it for Intel for next Windows version.
The former claim is absolutely true, and I'm not happy about it. But that is surely the standard for all ARM devices out today, is it not? Locked bootloaders?
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?
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?
Apple and Android devices are all closed so that excuses Microsoft from doing the same? Guess again; they are all wrong.
[deleted]
>Secure Boot might be a useful part, if everybody could add his own keys to his own board, and delete existing keys for Microsoft and others. But one has to pay to get his key signed by Microsoft.
That is exactly what Microsoft mandates for secure boot for Windows 8 certification. Please stop spreading misinformation.
That is exactly what Microsoft mandates for secure boot for Windows 8 certification. Please stop spreading misinformation.
I thought that only applied to x86 processors, not ARM?
[deleted]
[deleted]
The problem is not rootkit embedded in the BIOS, the problem is rootkits embedded in the boot sector.
Actually, I suspect that the problem isn't rootkits, it's Windows 7 Loader, the one way to pirate windows they haven't been able to squash since it runs from the boot sector.
On the other hand, the TDSS rootkit modifies the boot sector to hook the loader to allow the rootkit which is an unsigned driver) to load.
I guess, because Microsoft now realized that they lost the age of internet, they lost the browser war, the search engine war, and the mobile phone war. They know that Windows 8 sucks that much, that people want to install Windows 7 or Linux, and they need to prevent us doing this.
Its similar like a dictator shooting at civilians at the moment he realized that he lost the love of his people.
Its similar like a dictator shooting at civilians at the moment he realized that he lost the love of his people.
> I guess, because Microsoft now realized that they lost the age of internet, they lost the browser war, the search engine war, and the mobile phone war. They know that Windows 8 sucks that much, that people want to install Windows 7 or Linux, and they need to prevent us doing this
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.
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 are trying to prevent people from running Linux or Windows 7 [...]
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.
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.
> I've heard the excuses about malware, but is that even a significant problem?
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.
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.
It is exactly like stealth viruses in DOS, 20 years ago.
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?
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?
> Order them, unpack them, ruin the paper and cardboards, and send them back with a note: Can not install Linux.
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".
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".
OEMs do not, as a rule, provide drivers for Linux desktops. Graphics card manufacturers are not OEMs, and the rest is mostly open source...
You're right. They don't provide graphics card drivers, but they "do" provide some (less important) drivers. I can't find a link (slow internet connection right now), but see here for example: http://www.canonical.com/engineering-services/oem-services/w...
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.
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.
That page is about "drivers" in the sense of "reasons that drive the decision to ship Linux", not hardware drivers :)
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.
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.
The linked video of Cory Doctorow's keynote at the Chaos Communication Congress in Berlin, "The Coming War on General Computation" is very interesting, insightful, and worrying. http://www.youtube.com/watch?v=HUEvRyemKSg
I'm sure Cory would have given a talk in 1970 on "The Coming War on General Purpose Hardware" where he bemoans the rise of the integrated circuit and an end to you being able to rearrange the components in your computer to suit your whims.
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.
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.
With platforms like Arduino, you can in fact plug arbitrary components into your computer. For now.
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.
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.
"Components" as in individual transistors, resistors, and capacitors as opposed to integrated circuits. And MS already has veto power. You can't run device drivers that haven't been OK'd and cryptographically signed by them. DRM is baked into the media layers (e.g. you can't watch a blu-ray movie on a non-HDCP monitor).
You can't run device drivers that haven't been OK'd and cryptographically signed by them. DRM is baked into the media layers
Yes, and that sucks. But that's just Windows, and there are other options. For now.
Yes, and that sucks. But that's just Windows, and there are other options. For now.
> I find the prospect of Apple or Microsoft having veto power over how I use "my" computer extremely worrying.
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.
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.
Funny you should mention that. I put a blender there. It was made out of printed parts, so it would only last a month before I’d need to print new bearings and other moving parts.
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.
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.
"I'm sure Cory would have given a talk in 1970 on "The Coming War on General Purpose Hardware" where he bemoans the rise of the integrated circuit"
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.
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.
The digital imprimature of John Walker is even more worrying, as he saw this coming nearly 10 years ago.
http://www.fourmilab.ch/documents/digital-imprimatur/
http://www.fourmilab.ch/documents/digital-imprimatur/
I don't understand why the author seems against UEFI in general. I can understand the concerns with Secure Boot, but that's only part of the spec. Am I missing something?
I'm not convinced that putting most of an OS into the bootloader is a good idea. Particularly when that OS is closed source and written by the same geniuses that write BIOSes.
> Particularly when that OS is closed source
Not exactly: http://sourceforge.net/apps/mediawiki/tianocore/index.php?ti...
Not exactly: http://sourceforge.net/apps/mediawiki/tianocore/index.php?ti...
(a) TianoCore is only a small part of the code (the clue is in the name "Core")
(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) 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.
a) As far as I know, EDK compiles to a working bootloader on supported platforms.
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.
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.
"supported platforms" being a couple of emulators. That is, without any need to do hardware initialization.
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).
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).
Clearly the author knows nothing about UEFI other than it has secure boot.
Yawn. Same discussion when Intel introduced the TPM - doomsday didn't happen. Or the Clipper chip? Doomsday didn't happen.
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?
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?
clipper chip didn't materialize.
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".
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".
These tactics aren't exactly going to inspire good will towards linux users.
Not to mention the ethical issues here.
Not to mention the ethical issues here.
This will become the end of Linux and free software.
For crying out loud. Nothing can stop LinuX.
For crying out loud. Nothing can stop LinuX.
>Nothing can stop LinuX.
Not even spelling mistakes.
hint: it's spelled Linux
Not even spelling mistakes.
hint: it's spelled Linux
Isn't UEFI something I need to boot from a disk larger than 2.2 TB?
No, it's not. BIOS supports LBA48 for a _long_ time now (which can address a couple of PB).
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).
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).
We have a huge malware problem and these folks are worried that there's one more setting that a user might need to change before installing Linux? You know, apart from changing the boot order of the devices, partitioning the hard disk, installing into the right partitions, configuring dual boot etc. ?
>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?
>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?
The worry is that in the future, the setting will not exist on x86. Considering it doesn't exist on ARM today, I do not think this is unreasonable.
If it were guaranteed to always be user configurable, forever, I would actually be quite enthusiastic about secure boot.
If it were guaranteed to always be user configurable, forever, I would actually be quite enthusiastic about secure boot.
this is exactly the problem, Microsoft is completely free to change this requirement at any time, also consider the fact they never mandated it previously, until there was a massive outcry.
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.
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.
> that secure boot be able to be turned off and users be able to add their own keys?
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.
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.
But if you want an Android ARM tablet you could always just buy one.
There's something to be said here for consumer choice. Why go out of your way to prevent me running something that I'm willing to put effort into running?
After all, it's my goddamn tablet that I'm buying.
After all, it's my goddamn tablet that I'm buying.
Security and supportability.
The mandatory ability to add keys or disable Secure boot is also quite likely just as secure, except that you still own your device.
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.
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.
Then campaign for unlocking the bootloader on the iPad, which is the largest selling "ARM platform" by a huge margin. Interesting that no one seems to care about that.
I would applaud the same campaign against Motorola/Google.
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.
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.
If having an unlocked bootloader is important to you, stop buying locked phones. It really is that simple. The Galaxy Nexus is $350 unsubsidized on the Play Store[1], and is completely unlocked (okay, I admit, you have to run fastboot oem unlock).
[1]: https://play.google.com/store/devices/details?id=galaxy_nexu...
[1]: https://play.google.com/store/devices/details?id=galaxy_nexu...
Sometimes you have to pick your fights that could possibly be won.
We don't have a huge malware problem.
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.
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.
I would also imagine that intentionally ordering something you don’t intend to keep is illegal (though that’s obviously not really enforceable) and to me very clearly morally questionable.
The law exists to protect consumers. I think abusing it to further political goals is just a bad idea.
The law exists to protect consumers. I think abusing it to further political goals is just a bad idea.
These days linux distros like Ubuntu are incredibly easy to install, and most computers are already setup to boot from the cdrom first. The problem is this setting has the ability to be worded in a way that would scare most users, so it is unlikely many new users will want to enable it.
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).
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).
Why does Microsoft get to use UEFI and others do not? If it is such a valuable tool in fighting malware, why is the only certain option "Microsoft or turned off"?
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.
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.
Which should be a very small number of them as long as they've followed the restrictions that Microsoft places on OEMs to ship Windows 8 certified devices.
(Not to get in the way of anyone's pitchfork of course.)
(Not to get in the way of anyone's pitchfork of course.)
[deleted]
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.