Ubuntu Can't Trust FSF's Secure Boot Solution 377
sfcrazy writes "The Free Software Foundation recently published a whitepaper criticizing Ubuntu's move to drop Grub 2 in order to support Microsoft's UEFI Secure Boot. The FSF also recommended that Ubuntu should reconsider their decision. Ubuntu's charismatic chief, Mark Shuttleworth, has responded to the situation during an interview, and explained the reason they won't change their stand on dropping Grub 2 from Ubuntu. Shuttleworth said, 'The SFLC advice to us was that the FSF could require key disclosure if some OEM screwed up. As nice as it is that someone at the FSF says they would not, we have to plan for a world where leaders change and institutional priorities change. The FSF wrote a licence that would give them the rights to take specific actions, and it's hard for them to argue they never would!'"
They expect OEMs to lock machines down? (Score:5, Insightful)
The SFLC advice to us was that the FSF could require key disclosure if some OEM screwed up.
So in other words they're anticipating not only that OEMs are going to accidentally or intentionally ship machines running Ubuntu that are locked down so that you cannot boot your own kernels on them but also that they won't be able to convince the OEMs to fix their broken BIOSes to allow users to run their own code. By not using GRUB2 they ensure that said OEMs would have no legal obligations to allow you to run the code you wanted on the PC you'd just bought.
Not quite: They want to still work in a screwup... (Score:3, Insightful)
The expect that an OEM may screw up. In that case, their current solution will still allow users to run their own code except for the bootloader itself.
But if they used a GPLv3 bootloader, they have received advice that they might have to reveal the key when the OEM screws up, because that would be necessary for someone to provide their own bootloader.
Far better to not chance it and just avoid the GPLv3 for something that actually has a free license, rather than the significant impositions that GPLv3 attem
Re:Not quite: They want to still work in a screwup (Score:5, Insightful)
The expect that an OEM may screw up. In that case, their current solution will still allow users to run their own code except for the bootloader itself.
In other words, what we had with OtherOS on the PS3.
But if they used a GPLv3 bootloader, they have received advice that they might have to reveal the key when the OEM screws up, because that would be necessary for someone to provide their own bootloader.
How is that a bad thing? This is not a key that is used to protect military secrets, it's a key that serves exactly one purpose: to prevent people from running modified software.
Far better to not chance it and just avoid the GPLv3 for something that actually has a free license, rather than the significant impositions that GPLv3 attempts to impose in the name of the FSF's particular vision of "freedom".
Your freedom to throw punches ends where my face begins. My freedom to install software on my computer is not less important than some OEM's freedom to restrict what software runs on their products.
Re:Not quite: They want to still work in a screwup (Score:4, Insightful)
How is revealing the key bad?
Well, how about that it would be revoked! Having the key would allow one to subvert Secure Boot on windows systems, so you can bet dollars-to-doughnuts that if Canonical had to release its key, Microsoft would revoke Canonical's key.
Re:Not quite: They want to still work in a screwup (Score:5, Insightful)
Otherwise, they are just legitimizing an attack on user freedoms, despite being the maintainers of the most popular GNU/Linux distribution out there (and despite the fact that those very freedoms are what enabled their entire operation).
Which would be a greater attack on user freedom? (Score:5, Interesting)
Which is a greater attack on user freedom?
a) Not being able to change the bootloader?
b) Not being able to install on new systems without changing EFI settings because the signing key got revoked?
Canonical chose "A". Fedora chose A, too, btw, because they didn't sign grub, but built a "pre-bootloader-bootloader" to load Grub.
Re:Which would be a greater attack on user freedom (Score:5, Insightful)
Now is the time to fight back, not compromise. Bootloader restrictions are a direct attack on free software and user freedom, and the response by Canonical and the Fedora project has been to just lie down and accept that attack.
Re: (Score:3)
Re:Not quite: They want to still work in a screwup (Score:4, Insightful)
My freedom to install software on my computer is not less important than some OEM's freedom to restrict what software runs on their products.
THEIR products? You paid for them, they're yours. I'd say you have every right to do anything you damned well please on your own equipment, and the vendor has no rights whatever after he has your cash. His rights are completely unimportant, yours are supremely important.
This is like Ford saying you're only allowed to use Firestone tires, Goodrich aren't allowed.
It's madness to go along with this evil bullshit.
Re:Not quite: They want to still work in a screwup (Score:5, Insightful)
Far better to not chance it and just avoid the GPLv3 for something that actually has a free license, rather than the significant impositions that GPLv3 attempts to impose in the name of the FSF's particular vision of "freedom".
The "freedom" to actually be able to run the software you want on the computer you bought? You're right, they suck.
Re:Not quite: They want to still work in a screwup (Score:4, Insightful)
The FSF's version of freedom is equivalent to nanny-state socialism. They've basically decided that their idea of playing nice needs to be enforced by big stick, and will happily trample over anything and everything that does something they dislike.
In this particular case, Ubuntu wants to place a bootloader that will allow you to load ANY operating system, bypassing the "security" features they dislike in the new UEFI. Ubuntu wishes to ensure that users can boot any operating system they like and run any software they want. Their concern is that the GPLv3 makes provisions by which the FSF could, in this case as the owner of GRUB2, deem that a machine that won't let them replace GRUB2 with something else is in violation of the GPLv3. At that point, they can demand that Ubuntu surrender its encryption keys used to provide secure bootloader verification--which then allows anyone to sign any bootloader they want, thus negating any security features you could leverage out of the bootloader (for example, intentionally instructing it to boot only signed code--keeping the chain trusted, rather than booting a foreign OS as is the option).
The point of contention is where the FSF gets to demand Ubuntu hand over their encryption keys for this particular application because they've decided it's 'unfair' that users don't have the option to replace a bootloader. The GPLv3 is a restrictive license agreement whose provisions do in fact allow the copyright holder to make certain demands about HOW their software is used. Most people fixate on the "Free" part because you're free to distribute and modify the software; but you are also "Obligated" to publish your modifications in source form if published in any form.
The GPLv3 brings restrictions on how you can use the software, such that you must be able to modify it--the hardware you use the software on must be configured to allow the use of modified software (or any other software). 'Jailbreaking' is not a thing with GPLv3 because the vendors would have to supply a way to run custom software. If the Linux Kernel was GPLv3, then you wouldn't have to root any phones to install Cyanogenmod: vendors would be required to provide an official method for the end user to replace the software with custom versions.
The Affero versions of the GPL family of licenses go even further: if you USE a modified version of the software, you must publish its source. That means if you modify an AGPL Web server and use it to serve your Web site, you have to put up the Web server's source code. An AGPL Web application would work the same way: modify an AGPL CMS and you need to publish its source code on your Web site.
These licensing restrictions are important to understand when licensing Free software. Canonical has decided not to license GRUB2 in Ubuntu on UEFI platforms because of potential conflicts between their requirements and the requirements of fulfilling the licensing agreement in certain cases. The FSF is extremely well known for its hard-line enforcement stance and thus there is the concern that they would not negotiate to reconcile technical mistakes, but rather take advantage of them to file a hostile injunction and demand release of encryption keys. The FSF behaves in this way because they have high ideals about what's "good for everybody"--as I said, they are effectively nanny-state socialists and want to get their fingers in everything so they can make people "play nice."
In short, this is why we have many licenses. The FSF uses the GPLv3 because they have their ideals and can support them with the GPLv3 (which, by the way, was born mainly out of the FSF's distaste for locked-down TiVo platforms). Other people still use the GPLv2 because they understand what the GPLv3 entails and their ideals are dissimilar from the FSF--Linux is GPLv2 because the relevant bodies are not sharply against locked-down phones running android, something they could legally prevent with GPLv3. Similarly many people use the BSD and MIT licenses because their philosophy is, "Here is code! Somebody might find this useful!"
Re:Not quite: They want to still work in a screwup (Score:5, Insightful)
That’s why I prefer contributing to GPL projects over non-copyleft: I know that helps the fight for a world in which all computer users have the 4 freedoms.
Canonical decided that they no longer care about that which made their founder rich.
GPLv3 just closes some loopholes, so I prefer v3 over v2: more measures to ensure my freedom in the cases where I am a mere user (98% of all the software I interact with).
Re:Not quite: They want to still work in a screwup (Score:4, Informative)
You don't understand GPL.
GPL is there to allow the final user to do whatever he want with his hardware.
A developer is not the final users, if he wants to use GPL code, he must give the same rights he received to everyone.
GPL2 had some holes that allowed some developers/builders to take the work of others and not giving back what they should.
GPL3 was made to fix that holes... yep, some people that were abusing the GPLv2 holes didnt like it, but bad luck, its not their code.
If you don't like that license, don't use programs with it and start over with your preferred license. you are not important, the final users are!
So here is the global view:
GPL is to give ALL power to the final users
Closed source gives all the power to the product owners/builders... the user loses freedom
BSD/MIT gives all the power to the developer and hope that product owners/builders are nice to not take the user freedom...
<sarcasm>everyone knows that companies are always nice to the users!!</sarcasm>
Re: (Score:3)
If you don't like that license, don't use programs with it and start over with your preferred license. you are not important, the final users are!
Isn't that exactly what Ubuntu is doing here, but the FSF is still objecting?
Re: (Score:3)
Because it's actually true. The heart of socialism is often stated as "from he who has the ability to he who has the need" or such; and overall it's basically a system by which the group shares what it produces. The basic theory is each man can produce more than he needs, and thus we should produce enough for everyone and then share the excess.
The Free Software Foundation is Richard Stallman's brainchild. Stallman's philosophy is that programming code and other creative works are the righteous property
Re:They expect OEMs to lock machines down? (Score:5, Interesting)
It gets better. Ubuntu is assuming this lockdown will be happening with OEMs they have a contractual relationship with.
Think about it. I put out Unknown Hacker Linux with a boot loader signed by me. I publish it on my website somewhere. Evil Bit Computers downloads it and installs my public key into the firmware of machines that they then sell to the public in a totally locked state. A buyer of one of those machines decides they want to wipe the preload and install Windows 8. They go Evil Bit and demand they keys per the GPL3 and get an Evil Laugh(TM). Then they come to me and demand the signing key and I tell them, I feel your pain but I'm sorry I can't do that because it would compromise every machine installed with packages signed by that key. And they couldn't do a darned thing to me legally because I have no relationship to Evil Bit Computers. If push came to shove Evil Bit could be required to issue new firmware allowing rekeying or they could be barred from distribution of GPL3 software. But I'd never see the inside of the courthouse.
And now you know why I have never considered Ubuntu. Never could say why, but they have always given off a 'wrong' vibe. Best explanation would be the short story _Young Zaphod Plays It Safe._ Just an undefined unease with em.
Why are we allowing these "people" to do this? (Score:5, Insightful)
Intel had the bright idea back in the nineties and it was soundly rejected; Intel got a lot of bad publicity and backed off. Then MS came up with "Palladium" [theinquirer.net] ten years ago and it, too, was soundly rejected and MS got yet another black eye.
WTF, people?? FIGHT THIS MADNESS!! This is yet another round of MS's war against all other OSes. This is MS wanting to control YOUR computer. This has no upsides whatever, and is all bad.
Gees, ten years isn't that long, have you folks forgotten already?
Re:Why are we allowing these "people" to do this? (Score:5, Insightful)
Gees, ten years isn't that long, have you folks forgotten already?
Two weeks after 9/11 the USAPATRIOT Act was highly controversial, despite the recent attack, and had sunset provisions.
Ten years later, it's renewed without any real debate.
"Keep us safe from the terr^H^H^H^H rootkits". In both cases the power-hungry gladly assume additional control and remove freedoms.
Re:Why are we allowing these "people" to do this? (Score:4, Interesting)
Gees, ten years isn't that long, have you folks forgotten already?
Everyone forgot their last vague memories of the importance of computing freedom after iOS showed them how nice the inside of a prison cell could be.
Re: (Score:2)
> Perhaps the FSF should learn from this and lighten up on the whole "all code must be given away" thing?
Once you start compromising on your morals it is a slippery slope to "Convenience Morality"
Good riddance (Score:5, Funny)
Grub2 is an epic piece of shit anyway.
Re: (Score:2)
> Grub2 is an epic piece of shit anyway.
Not exactly. It is epic. In that it is trying to live up to the "Grand" in its name. But it has to be admitted that it is in one important way inferior to GRUB 1. The big advantage of GRUB over LILO was that you didn't have to worry about an unbootable machine if you changed anything and forgot to 'rerun lilo'. GRUB2 brings those bad days back with it's mammoth configuration file spread into shards in /etc/ to make it possible for scripts to manipilate it in a
Re: (Score:3, Informative)
The big advantage of GRUB over LILO was that you didn't have to worry about an unbootable machine if you changed anything and forgot to 'rerun lilo'.
Which was never a big deal anyway. Just boot from external media run lilo, and reboot. Worked every single time. Why is that worth writing a whole new boot loader over?
Grub on the other hand would occasionally hose itself for no reason. Booting from external media and running 'grub-install' or 'update-grub' usually worked, but I still had one system that g
Grub bugs (Score:4, Interesting)
I'm sure many would be far less patient than me, so it may help perceptions of Linux/Ubuntu if some of the basics were in place.
Re: (Score:3)
At least Linux Mint's installer, and I think Ubuntu's as well, figure out that Windows is already on your system during the install process, and set up Grub so you can easily just choose "Windows" when the computer is booting up.
In other words, the "powers that be" know about the problem, and have a pretty good solution in place right now.
Re:Grub bugs (Score:4, Insightful)
I miss my grub.conf and menu.lst!
Re: (Score:2)
On noes! Instead of editing /boot/grub/grub.cfg I edit /etc/grub.d/X. The world is ending I say!
Of course you could just edit the file anyway and not run the generator script ever again, but that would be too complicated I guess....
Re: (Score:3)
Re: (Score:2)
Oh, hell, yes. There was a time in the mid 90s where Windows people would install Linux on a separate partition, for fun. Then they tried to get rid of it further down the line and oh fuck, I'm never doing this again. Linux on the desktop might be twice as far along if GRUB hadn't been such a piece of utter shit.
Grub in the mid-nineties? I don't think so.
I Call Bullshit. (Score:5, Insightful)
It seems to me that Canonical is missing the bigger piece -- which is that the vibrancy of Ubuntu depends on the wider vibrancy of Linux. If Ubuntu jumps into Microsoft's lifeboat and leaves the rest of the GNU/Linux community to sink or swim, Canonical is ultimately slitting their own throat slowly.
Trusting Microsoft over the FSF seems foolhardy at best.
Except that OEMs are cannonical's partners... (Score:3)
Part of the vision is that you should buy a Ubuntu system, right? In this case, Canonical is working with the OEMs to produce a certified system.
Thus if one of the OEMs screws up, Canonical does have a relationship with the product, as provider of the software, and may, under the GPLv3's "anti-TiVoization" clause, have to provide the signing key.
This is "Better to avoid the problem altogether"
Re: (Score:2)
It is simple, add to their legal binding document/contract that the OEM must not ship machines with locked keys and if that happens by accident the OEM must provide an updated firmware
Re: (Score:2)
Part of the vision is that you should buy a Ubuntu system, right? In this case, Canonical is working with the OEMs to produce a certified system.
The vision is that you can buy a system that does not impose restrictions on what software you can run. The point of the GPLv3 is to advance that goal. Having Ubuntu but being unable to run a custom bootloader is not part of the vision.
This is "Better to avoid the problem altogether"
There is another option: require that any bootloader restrictions be disabled by default. If a user wants the restrictions to be enabled, nothing should stop them; but if the restrictions are enabled by default, an OEM may very well ship a system that does stop users
Re:I Call Bullshit. (Score:5, Informative)
I think the reason for the SFLC's advice regarding having to reveal th key is that Canonical distributes updates directly. Here's the scenario:
1. The OEM sells a PC with Ubuntu preloaded and the BIOS locked.
2. The user buys the PC and then updates GRUB2 to a newer version supplied from the Ubuntu repositories. It'll install fine, because it's been signed by Canonical, and the Canonical key is in the BIOS.
3. User wants to modify GRUB2. They get the sources from Canonical, modify, recompile, and try to install. The computer won't boot, because their modified version is missing a signature.
This means that Canonical is violating the Tivoisation clause in the GPLv3. Canonical is redistributing GRUB2 to the user, and the licence won't let them do that unless they also provide the user with everything they need to be able to change GRUB2 and load it onto their computer just as they're doing with the original they were given. Since Canonical can't unlock the BIOS (only the OEM can), the only way they can fulfil those requirements is by giving out their key.
Shuttleworth isn't being entirely candid (Score:5, Informative)
I'm sure the SFLC did tell him that a mistake by an OEM could force disclosure of the signing key. But notice he doesn't say explicitly that they told him it could force disclosure of Canonical's signing key. That's because I'm pretty sure they didn't tell him that. Think about it. The logic here is that an action that breaches the GPLv3 by a downstream distributor (the OEM) could force the upstream to correct the breach. Now, suppose I put that in the context of code: I distribute a GPLv3'd piece of software, you receive it from me, modify it and distribute the modified version. If Shuttleworth's argument is correct, then I am in breach of the GPLv3 because I'm not distributing the source code to your modifications as required by the GPLv3. But that's obvious nonsense, since I'm only required to distribute the source code to the software I'm distributing and I'm not distributing your modifications at all. Only you're doing that, and the only way you can pass your obligations back to me is if you're me in the legal sense (ie. a wholly-owned subsidiary company or a division of my company) or if I've signed a contract with you to take on those obligations for you.
So I suspect that while Canonical would be required to distribute any tools needed to create signed bootloaders and the keys needed for the BIOS to boot them, unless they're distributing the actual hardware it'd be on the OEM (who selected the hardware) to take any steps necessary to comply with the GPLv3 as regards the hardware (ie. either choose a BIOS that allowed keys to be enrolled or Secure Boot to be disabled, or distribute their own signing keys). Of course that could place the OEMs in a bind: if they used Canonical's signed binaries and keys then the OEM would be obliged to provide the signing key, but Canonical is not obliged to provide it to them. Which I think is exactly the situation the FSF desires: OEMs placed in a position where to use a very desirable bit of software in their equipment requires selecting a BIOS that permits user control over the Secure Boot process and keys.
Re: (Score:2)
When Monty Widenius sold MySQL to Sun nobody worried. What could possibly go wrong?
Mark Shuttle worth is absolutely correct when he says "we have to plan for a world where leaders change and institutional priorities change."
Not quite the flaw you make it sound like, Mark... (Score:5, Insightful)
Yes! Yes, they could - Because it would mean that the OEM had "accidentally" taken away the user's right to do whatever the fuck they want with hardware bought and paid for by that user. And I have no problem with requiring key disclosure in that situation.
Look, Shuttles, we get the idea that you want every bit as much control over Ubuntu as Microsoft has over Windows, and UEFI has the potential to finally fulfill your little wet dream there. You seem to have overestimated your importance in the Linux world, however - If you won't honor the spirit of "free" software, we'll simply use a distro that does.
Re: (Score:3)
Except that key disclosure would cause a lot of harm.
Canonical's solution still allows you to run all your own code except the bootloader in this case. Since the bootloader itself is not locked down, you can boot anything from the bootloader.
But if they had to disclose the key, then this means Microsoft has to revoke Canonical's key, because that key would allow subverting Window's secure boot model, and now it can't be used to install without requiring user EFI reconfiguration on any PC that includes Cano
Why did you go with Linux? (Score:5, Insightful)
I chose it because I could see the sources, update as I see fit, build as I see fit and be able to do a build without clobbering all my installed software.
So why would I suddenly want to chose a closed source Microsoft solution? This is the company, whose practices since 1995 are the major reason why we have malware, viruses and worms.
Such great vision from the start, nobody would even think to remotely try to control your computer, right?
As a mainframe admin I was charged with keeping sneaky bastages out all the time, why didn't Microsoft believe this sort of thing could happen on a PC? To this day they still have gaping holes in security and their transparency is a thing of fantasy.
But Microsoft isn't changing position? (Score:5, Insightful)
As nice as it is that someone at the FSF says they would not, we have to plan for a world where leaders change and institutional priorities change
As nice as it is that someone at Microsoft says they will sell $99 keys, we have to plan for a world where leaders change and institutional priorities change
Antitrust authoritities? (Score:3)
Anybody heard any reaction from the antitrust authorities?
US would probably remain mum, but I do not think EU would accept the OEM lockdown by convicted monopolist that readily.
Yes, there are security concerns, but they are negligible compared to the power grab by the convicted monopolist.
An impossible solution (Score:2)
I wopiudl be interested in the naive idea that users shouidl be able to turn secure boot on and off. So if it's off, no Windows but other OSes could boot. On, and Windows would boot, but other OSes may or may not.
Then, if I choose to NOT use Windows, I'm in a much simpler reality.
Of course, I'm certain this cannot work. Darn.
Why doesn't Canonical just ask their partners? (Score:5, Interesting)
Sure, it would need to be finalized in a legal document, but the first draft can look something like this:
Canonical: Howdy, Partner. When we work together to bring a computer to market running Ubuntu and GPLv3'd GRUB, can you make sure that the end-user is able to install their own signing keys so they can install modified versions of GRUB, per the licensing terms?
Partner: Okay, how would we do that? I mean, how can we make sure that we meet the terms of the license?
C: It's not that difficult. Basically y'all just need to make sure that the end-user can change the set of signing keys listed in the firmware. The Free Software Foundation wrote a whitepaper [fsf.org] about it. You can also contact them via email if you have any questions!
P: Wow. That's really difficult to understand, too bad we don't have any engineers on staff who can figure....awww... I'm just kidding with you, of course we have skilled engineers and lawyers on staff. We even have people who know how to write emails. We should be all set!
C: Awesome, Partner. Before you actually ship hardware with an Ubuntu-Certified sticker on it, why don't you send one of the pieces of hardware to us so that we can manually test to make sure that end users can install their own signing keys. We'll use my son jimmy, 'cause we want to make sure it's so easy a kid can do it.
P: Okay, sounds great on my end. Glad that we had this conversation. I was worried it would take all day, but it really just took 15 minutes of my time.
C: Yep. Now remember: If you do ship some hardware with GRUB installed and you make a mistake so that users can't install their own signing keys, you're going to have to make a firmware update or otherwise make this problem right. Understand?
P: Isn't that what we have to do when we break the license of any of the pieces of software that we ship on our devices?
C: Yes. But I just wanted to make sure that we stated it explictly so that you wouldn't try to push the mistake off on us.
P: Fair enough.
C: Great to talk. We'll put all of this down in the formal contract when our lawyers draw it up. Have your engineers call our engineers about any kernel bugs. We should be able to get this hardware out by Q1 of 2013. So long!
P: Bye!
---------------
I mean, seriously, what's The Big Deal here? Just make some contracts with your hardware partners and hold them to the terms of the contracts like every other business deal that has ever happened. Why does Canonical think this is so difficult?
Re:Ubuntu understands users (Score:5, Insightful)
Until Windows 9 requires that Secure Boot can't be turned off and you can't install new keys if you want to ship with a 'Windows compatible' sticker.
FSF may be fruitcakes at times, but on this they're correct. 'Secure Boot' should have been named 'Windows lockin'.
Re:Ubuntu understands users (Score:5, Insightful)
Everyone knows the Free Software Foundation cannot be trusted, but Microsoft can.
I just got back from vacation...did the universe invert while I was away?
Re: (Score:3)
Everyone knows the Free Software Foundation cannot be trusted, but Microsoft can.
I just got back from vacation...did the universe invert while I was away?
Oh yea, that - we sent you an email, but since everything inverted it must have gone to your outbox instead of your inbox, so you must have thought you sent it to yourself...
Mandatory Warning. (Score:5, Informative)
Serious Sandwich, aka Bonch, Sharklaser, Tech* etc is one of a number of sockpuppet accounts established and maintained by Burson Marsteller on behalf of Microsoft.
Their presence in this discussion means comments and moderation will be slanted to emphasize their client's viewpoint.
Treat all commenters in this discussion with suspicion and derision. Do not post or reply to posts yourself.
Re: (Score:2)
Do you offer any proof of your claims? Or are we just going on accusations these days?
Re: (Score:3, Interesting)
Can't prove he's on someone's payroll, but damn sure he's a sockpuppet and troll.
Here, check his first ever posts [slashdot.org] and compare with his likely previous account [slashdot.org] (which only survived for a few hours).
Except for common talk points and phrasing, "Google abuses opensource", "only gives back what they're required to by GPL", "hidden behind servers", note the behavioural similarities, fresh account, dives into Google/MS related discussion right from the start with pro-MS/anti-Google trend, manages to weave agenda-r
Re: (Score:3)
"Treat all commenters in this discussion with suspicion and derision."
Suspicion is the norm around here. Derision is the default action of many/most.
I can't hardly tell the difference between the misinformed, ignorant, or paid/unpaid shills. So I end up considering the content of comments. Radical and time consuming, but hey, what else do I have to do?
Re:Mandatory Warning. (Score:4, Informative)
Well, whoever he is he's factually wrong.
UEFI booting has absolutely nothing to do with boot sectors. Secure boot is part of (A superset of?) UEFI booting. A system doing a UEFI neither needs, looks for, nor cares about the boot sector.
Boot sectors are part of the old, old, old legacy boot method where you had to chain larger and larger bits of code to jump the CPU in to its newer, more powerful modes. More or less, the sytem starts in a mode so dumb it can only run a few bytes of code. It can't read or interperate filesystems. It cant jump in to a modern 32 or 64bit kernel I can't do anything but read very simple code from a fixed location. This location is the boot sector, and it's always sector 0. This code calls a larger boot loader, then a larger one, then eventually reaches a point where it can start up a modern operating system.
UEFI is actually a tiny OS that can read partitions/filesystems directly and can call a modern UEFI compatable boot loader directly. Now, not to say you can't subvert your modern UEFI bootloader. (Thats what secure boot is all about) But it certianly has nothing to do with boot sectors.
Re: (Score:2)
Proof? It is hard to take this claim seriously when you provide no proof and post as an AC. I am not saying you aren't right, I am just saying that you are making an assertion with no way to know who you are or verify what you are saying...
A little background on Burson-Marsteller (Score:5, Informative)
(please note that I am NOT the same AC that made the accusation, but rather, one that wondered who this firm is, so I figured I would share my findings...)
Ok, so I do a bit of digging for two minutes, and came up with this:
Who:
Burson-Marsteller is a PR firm. As in, a really, really, REALLY big fuckin' firm. Apparently the only place on Earth worth mentioning that doesn't have an office of theirs is Antarctica.
http://en.wikipedia.org/wiki/Burson-Marsteller
Where:
Burson-Marsteller has been very, very busy. I haven't had time to second-source the entries from Wikipedia, but supposedly this firm has been at the forefront of a lot of really, really bad shit. The original Tylenol Poisoning scare, Three Mile Island, PR for Phillip Morris; you name the PR nightmare, and there's a good chance they've been there to mop up. In other words, these guys are "World-Class Spin Doctors".
When:
"When" really doesn't even apply in the context I'm using because they are still in business as part of the WPP plc, the world's largest advertising agency. Which means, "when" is really all the time.
http://en.wikipedia.org/wiki/WPP_Group
What:
It took a bit of digging but I found a set of links that tied them back to Microsoft. Ok, so now we have something tying the two together with Microsoft as Burson-Marsteller's client.
http://www.economist.com/blogs/babbage/2012/03/microsoft-v-google
http://www.techdirt.com/articles/20110513/15424314269/burson-marsteller-digs-itself-deeper-hole-deletes-critical-comments-its-facebook-page.shtml
The accusation:
I myself have observed "shill-like" behavior over the last decade on Slashdot, and in the last 4 years it has intensified quite a bit. I believe that, while there is no direct way to prove the accusation, there is sufficient background for readers to make an informed decision as to the possibility of the accusation being accurate.
Why AC:
Yes, I have an account here, let's just say numbered under 200,000 and leave it at that. No, I will not post this with my account for reasons that should be readily apparent to anyone with two brain cells attached - which is to say, attracting the attention of a world-sized firm to my little pittance is probably not the wisest move to make. If they have enough money to pay people to sit around all day and troll slashdot forums, then they certainly have enough money to harass me (given the opportunity).
Sometimes the best tactic to keep out of harm, is to simply not be seen.
SECURE BOOT IS A FRAUD (Score:5, Insightful)
Ask yourself, what percentage of a system's time and lifecycle are spent in boot? What percentage of the binary runtime image is loaded in this process?
"Secure boot" is FAKE SECURITY whose ACTUAL risk is GREATER than its SUPPOSED benefit. Lock boot images, and the real security problems for persisting on a host and hiding activity will only move to the next rung on this ladder.
The only thing "Secured" is vendor lock-in.
Sure, you can detect a compromised kernel at boottime. That is a FRACTIONAL coutermeasure, to actual risk. EVERY driver and ring-0 loadable module needs also to be signed. It's bullsht, in the real computing world - unless you have an XBox or iPad model.
Re:SECURE BOOT IS A FRAUD (Score:5, Insightful)
Boot sector virus is not the target, to be fair.
It's to prevent loading a compromised kernel image. A signed boot-loader chain will only load if uncompromisable with cryptographically verified signatures and checksums.
But this is not the threat to most users, most of the time.
And? If they are dumb or mistaken enough to get an infection that will compromise their OS image and ring-0 loadable software? They are going to be compromised in OTHER WAYS that will NEVER touch the system image. Secure system boot is a good way to protect a boot-loader for encrypted volumes - but not even needed for this to be effective.
It is a security chimera - with more opportunity for mistakes and misuse than protection.
Re: (Score:3, Insightful)
This has nothing to do with vendor lock in (in the /. microsoft sense) nor is it really targeted at preventing viruses. It is so that microsoft or apple can sell an OS that is guaranteed to not have been tampered with for content protection enforced at boot time by the hardware.
I imagine there will be ways around this, but it is going to be much harder.
-nB
Re:SECURE BOOT IS A FRAUD (Score:5, Interesting)
Bingo.
This serves the interest of every RENT TAKER on your PC - and does so by depriving YOU, the "owner" of the machine. Your choice is limited, to created guarantee of revenue to certain corporations.
Mind you, now. Shuttleworth is either naive - or playing a sacrifice move in the Chess game. This is an incremental step towards the death of Linux/BSD/etc on general-purpose hardware. It is a CRITICAL step - the direction of the game will be decided on how this plays.
Re: (Score:3)
No, All it does is hasten the move towards obsolescence for Ubuntu and a move to a better fork instead.
There's a real reason I use Mint now, and it's not because of me saying that it's better. It's that Ubuntu has just simply gotten so much worse and bloated lately. In addition, the person in charge of Ubuntu's development is a type-A asshat is essentially acting exactly like your typical tyrannical CEO at work. "You'll suffer under my vision of how things should be and like it".
As if. I jumped ship ove
Re: (Score:3)
>When was the last serious "boot sector virus"
Refer to my other post. http://slashdot.org/comments.pl?sid=2962071&cid=40565349 [slashdot.org]
>however the serious win from this technology can only be had if the owner of the machine gets to set the key and sign his own boot images. Then you are talking about some serious win.
Umm, thats exactly what Microsoft requires for Windows 8 certification of x86 machines. You can even remove Microsoft's key if you so wish.
Why is this so hard to comprehend?
Re: (Score:3)
Why because he says something you dont like?
Well, until people can be persuaded to distrust comments they agree with, people distrusting those they disagree with is the only thing standing between us and total public credulousness.
Re: (Score:3, Informative)
It's also optional
Unless you're on ARM, in which case it won't be, so no, it's not always optional.
Re:Ubuntu understands users (Score:5, Interesting)
> Secure Boot is very much required security feature. It will lock out malware that hides rootkits in boot sector. That's a very good thing.
Somebody with more crypto knowhow, please put me some knowledge on here. Because I'm not seeing it that way. Secure boot will work wonders to ensure Hollywierd and Microsoft that their hardware isn't doing something nasty like letting the guy who put money on the counter and thinks they own it (how funny!) run something of their choosing. What I don't see is how it really protects the user from malware.
The security only runs one way. Once somebody can subvert the boot process in any way (and show me ONE device that hasn't been rooted) all malware need do is what it has always been doing. Take over the boot. Then IT checks the sig on Windows and tells it that "I'm the bootloader, you can trust me." and there isn't a 100% sure way to verify backwards. We all know most vendors will still be flashing the BIOS/UEFI from Windows because anything else will be too much hassle for the end users. They will pretty much have to do it to get key revocation lists. Oh yea they talk now about secure pathways through secured supervisor modes but we know that if it is running Windows nothing on that CPU is really and truly secure. And wait until the motherboard makers start encheapening the system. Remember when a physical write protect jumper was standard to protect flash BIOS? And a ROM portion with an emergency rescue reflash util? When was the last time you saw any of those protective measures on sonsumer equipment?
> It's also optional, so you can always install Linux.
On x86, for now.
Re: (Score:2)
fwiw, just last week I bought an intel n2800 mobo and it allowed bios flash 'f7' from a regular fat formated usb drive. not even bootable! pure fat16 blank non-system usb drive, copy the .BIO file there, hit f7 and do an upgrade. worked fine.
this was not a secure system but requiring windows for upgrades of bios is not the norm anymore. I've seen quite a few 'boot from cdrom' style bios upgrades, too. and on the cdrom? syslinux! ;)
Malware vs. DRM (Score:3)
Then IT checks the sig on Windows and tells it that "I'm the bootloader, you can trust me." and there isn't a 100% sure way to verify backwards.
For local malware: Indeed, there is no way.
In theory, the correct way to check anything in a Secure Boot environment is to ask the TPM chip.
In practice, a compromised machine might be running inside a hypervisor. All traffic to the TPM chip will be instead routed to a fake-TPM routine which sign stuff with the malware's private key, and at load time, the rogue hypervisor could patch Windows to put the malware's public key where normally the official TPM key resides.
Everytime Windows has a doubt, it will ask
Re: (Score:3)
True, but if a solution causes more problems than it solves, it certainly should mean you don't implement it.
Re: (Score:3)
I'm not sure why they would need a revocation list. There is a handful of keys and they won't ever be revoked.
If any of the root private keys ever got leaked they would need to revoke it, otherwise it could be used to sign arbitrary malware and bypass the whole purpose of secure boot.
Re: (Score:2)
I don't understand why Microsoft requires secure boot. Care to explain?
I mean the boot sector "virus"/"malware" thing is highly overrated. I've never seen one in the wild. The situation as is was just fine.
Re:Ubuntu understands users (Score:5, Insightful)
1. Once the technology is deployed, it requires only altering one line of a contract to kill linux on the desktop.
2. Because being able to ensure the OS hasn't been tampered with by the hardware owner is vital for any attempt to make effective DRM schemes.
Re:Ubuntu understands users (Score:5, Insightful)
If I don't have the keys to my computer, it's not mine.
RMS's The Right to Read [gnu.org] looks less and less paranoid all the time.
Re:Ubuntu understands users (Score:5, Insightful)
I mean reasons that benefit the user
That never enters the picture; users, in this model, are nothing more than an exploitable resource, a source of revenue for the corporate overlords.
Re: (Score:2)
Re: (Score:2)
Re:Ubuntu understands users (Score:5, Interesting)
I don't understand why Microsoft requires secure boot. Care to explain?
Here is but one example: the market for video games is billions of dollars, and while a lot of that money is in consoles and phones, there is still plenty in PC games. The problem is that on my PC, I can modify the game in arbitrary ways -- I can remove a license check, I can cheat (BIG problem in MMOs), etc. The reason I can do this is that the OS has no good way to stop me -- even if Windows tried to prevent me from running unsigned code, I can run a program before Windows even boots up to get around that restriction.
Thus restricted boot environments become a necessity for Microsoft to turn Windows into a DRM-friendly platform. DRM on PCs is not dead, it was just on vacation while the big players worked on a way to sneak in restricted boot environments. No more grabbing secret keys out of running processes, no more replacing WoW DLLs to cheat, no more patching software to evade license checks. That's why Microsoft requires this.
That is also why we need to fight back against this.
Re: (Score:2)
Thus restricted boot environments become a necessity for Microsoft to turn Windows into a DRM-friendly platform. DRM on PCs is not dead, it was just on vacation while the big players worked on a way to sneak in restricted boot environments. No more grabbing secret keys out of running processes, no more replacing WoW DLLs to cheat, no more patching software to evade license checks. That's why Microsoft requires this.
That is also why we need to fight back against this.
And why I am hoping Steam's Linux initiative is both more than a rumor, and successful. Even if they don't get AAA titles, indie games can still appear on Linux, and the big game studios seem to have forgotten one little thing: they were once small studios, making what are now considered indie games. And that was considered the golden age of gaming.
Oh, and even DRM from boot will never work, not completely. Just ask Sony or MS how well that turned out, and they controlled every aspect of the hardware and s
Re: (Score:3)
Just ask Sony or MS how well that turned out
Keep in mind that it took four years to break the PS3 DRM, and even now the majority of PS3 owners are not in a position to jailbreak their devices.
Re:Ubuntu understands users (Score:5, Interesting)
Re: (Score:3)
Re: (Score:3)
It took four years because for the first 3.9 years, the tinkerers were satisfied with the official Linux-on-PS3. Sure, it was more locked-down than any Linux ought to be , but it was good enough for the tinkerers to tinker with.
Once Sony stole* Linux back from the tinkerers, it took what, a month or two, before it was cracked? And cracked it open wider than the old Sony Linux port had?
So depending on how you define when the tinkerers started trying to crack it, it took either years, or weeks.
* Yes, stole. I
Re: (Score:2)
Re: (Score:2, Informative)
> Restricted boot environments are about DRM, not about securing the system from malware
Really? Here are some references about boot malware which UEFI secure boot can prevent.
http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection [chmag.in]
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/ [theregister.co.uk]
http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft [computerworld.com]
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. ....
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.
Atleast you'd have some credibility left if you had said that the restrictions could be
Re: (Score:2)
FUD. Secure boot doesn't enable any of those crazy scenarios that you've mentioned. The user is still free to install software that does all the above even with secure boot enabled.
Re: (Score:3)
And we are supposed to give Microsoft ultimate control over what we run on our computers because you want to play a game?
Re: (Score:2)
So, what's in for the users?
Same thing you get on iOS, and some Android devices.....a walled garden. Unfortunately, some people prefer that. It makes me sad.
Re:Ubuntu understands users (Score:5, Insightful)
Some users prefer walled gardens. They don't know what they've lost.
It's rather stunning how close we are getting to some of the dystopias predicted by the FSF. They seemed silly at the time.
Re: (Score:3)
"But but but, you're in our garden, permission is implied!"
Bullshit; When I take a cab, the drivers do not magically gain the right to go through my personal effects, merely because I'm "using their service."
It never ceases to amaze me the kind of abuse people won't take from bri
Re: (Score:2)
Since you can install your own certificates on your local machine
There is no guarantee of that; see, for example, the iPad.
Re: (Score:2, Interesting)
I don't understand why Microsoft requires secure boot. Care to explain?
Because, it is fairly easy -- especially with so much open source software out there -- to create malware that gets control of the system before the OS does. This malware will then hide itself, using hardware, to intercept any attempt to find it and virtualize the checks to fail. Simply, once in place, it is in control of your system, and the OS (or any anti-virus, etc) software from even being able to tell it is on your system at all. Basically, in the first moments you turn on your computer, you've los
Re: (Score:3)
No, but a secure boot loader is a link in the boot chain, so if you want to require it for the kernel and drivers (which would have solved those) then you do need to extend that to the boot loader or else the boot loader becomes the obvious point of attack. Just because the crooks are coming in the front door doesn't mean you shouldn't improve the lock on the back door at the same time as when you improve the lock on the front door. I
Re:Ubuntu understands users (Score:5, Insightful)
While FSF just tries to fight their ideological war, Ubuntu takes less hard road and understands why Microsoft needs to employ secure boot. Good for them, and better for Linux.
How is this good for users? Restricted boot environments are about DRM, not about securing the system from malware. Canonical does not care about whether or not people can use the computers they own in the manner they wish to use them, so how is that a good thing?
I do not want to choose between Fedora and Ubuntu; I want to use whatever distro I fancy, and I want to be able to switch distros without jumping through hoops (yes, there are hoops to jump through now; this move by Canonical does nothing to advance any solution to that problem).
Re: (Score:2)
So you want what you what you not only do not have now, but somehow manage without.
The point is that we do have a real problem with GNU/Linux: switching distros is difficult and requires a lot of work, and sometimes you do not get what you wanted at the end. That is a problem that we should be working to solve or at least mitigate. This nonsense with signed bootloaders on personal computers is a step in the complete opposite direction.
Re: (Score:3)
Microsoft "needs" to employ secure boot in order to gain an advantage over smaller competitors who can't push OEMs into providing their signing key by default. Nothing more, nothing less. Any other justifications offered are smokescreens, and you are a naive fool if you believe them.
Re: (Score:2)
Ideology wars, are based on Sliding Scale Arguments. If you take your oppositions ideology side to the extremism imagine how bad it could be.
People who are Pro-Life: Go If we let any of these laws get passed we will finally reach a situation where we can kill child under 21 because before that they are not fully developed yet.
People who are Pro-Choice: Go if we let any of these laws get passed we will revert back a century and loose a hundred years of Women's rights, where the woman would be the slave to t
Re: (Score:3)
Re: (Score:3)
Boot sector viruses are a vanishingly rare novelty too, possibly the rarest form of virus.
Re:Ubuntu is doing the right thing (Score:5, Insightful)
If the only thing keeping this secure
Secure from what? The goal is not to secure you from a bootloader virus; I doubt that was discussed for more than five minutes while this system was being designed. The goal is to secure DRM systems from you, the user, because of what happened with DVDs and deCSS, what happens with software cracking tools, etc. The goal is to turn PCs into iPads.
This is a trap, designed to rob you of the freedom you have right now, which as it so happens is the freedom that PCs were meant to provide in the first place.
Re:Ubuntu is doing the right thing (Score:4, Insightful)
Actually, I'm pretty sure that personal computers were simply "meant" to be useful to the most people possible
No, PCs were built by people who wanted to own and control their computers, and whose opinion was that everyone else should have that freedom. In the 1960s (years before PCs), IBM, AT&T and other companies were already talking about how to bring computers into offices and homes, by selling computation as a utility. The plan was for you to have a terminal in your house, which would connect to a mainframe, and you would pay by the CPU hour, by the storage you used, etc. The computer itself would be equipment owned and operated by the utility.
The point of PCs was to give you a computer that you owned and operated, rather than one you rented. You could install whatever hardware you wanted, you could run whatever software without worrying about the bill, you could modify the system in arbitrary ways. It was never a choice between PCs and having no computer access, it was a choice between PCs and renting time on some mainframe.
Perhaps sad for those of us who tinker, but whether or not the bootloader is locked will have zero impact on the vast majority of personal computer users...
I disagree; stronger DRM means tighter controls on what people can do. Copy a movie to your tablet, so you can watch it on the go? That will be something people will be forced to pay for, or even forbidden from doing in the first place. This is not just about hackers. Ordinary people often have no idea what their computer is truly capable of because they are using software, and now hardware, that is designed to restrict them.
It's also sensationalist to assume that those of us who do tinker will not still have plenty of hardware options
Yeah, but we may be forced to make decisions that we would not have had to make otherwise. What if dual booting becomes impossible, because Windows will not run on a system without these restrictions? That will stop a lot of people -- people who cannot afford two computers (like me when I was in middle school) and who cannot give up Windows.
Either turn off "secure boot" (buy x86)
Not necessarily easy to do; OEMs do not have to cooperate and enable custom mode, let alone allow you to disable the feature entirely.
you may also just build your PC yourself
There is no guarantee that Windows will actually run on such a system. Look at the effort required to get Mac OS X running on a homebrew system; what reason does Microsoft have to make Windows available on a home-built system? Maybe only OEMs will get to do that, or maybe only OEMs will be allowed to install Windows with support for certain entertainment services (e.g. Netflix), etc.
I know that it is a little paranoid, but Microsoft does not have a history of being soft on these things. Remember when they integrated Internet Explorer into the desktop? If Microsoft is pushing this because they envision the future of home computer as being entertainment-oriented -- and I strongly suspect that this is the case -- it is reasonable to assume that they will do everything they can to create a "media ecosystem." Why shouldn't OEMs be cutting deals with media companies? Why wouldn't Microsoft want to position Windows as the software that is used for that purpose? This is something that will probably make a lot of money, for Microsoft and the OEMs that ship Windows systems, and the entertainment companies. Perhaps homebrew systems will also get access -- for a price, and probably a higher price than what OEMs pay.
Of course servers won't have locked bootloaders, either.
I used to think this, but I am not so sure about that anymore. Why not have locked bootloaders on servers? There is a larger security concern there (the stakes are much higher; even if bootloader rootkits are a ra
Re: (Score:3)
Let me get this straight. They are saying that an OEM's actions might mean that the GPL could be used to force Canonical to release something?
I release some Code A under the GPL (which works fine on its own) and some Code B under a proprietary licence, and a third party links A to B and releases it, that in no way compels me to release my proprietary code B! This is an analogy, not an attempt to explain exactly what is happening, but I think it's apt.
Re: (Score:2)
I release some Code A under the GPL (which works fine on its own) and some Code B under a proprietary licence, and a third party links A to B and releases it, that in no way compels me to release my proprietary code B! This is an analogy, not an attempt to explain exactly what is happening, but I think it's apt.
Oh no, it's far worse than that, you'd be required to turn over the signing key that you use to cryptographically sign all your proprietary code.
Re: (Score:3)
That's the advice they have.
They could choose to take an analogy in a random slashdot post or they could take the advice of a lawyer specialised in the field of software licensing.
Decisions, decisions...
Re: (Score:3)
Which results in the very thing that it claims to not want. GPL3 code is RESTRICTIVE license. It is an anathema to FREEDOM. True freedom includes some not so nice things