Ubuntu Lays Plans For Getting Past UEFI SecureBoot 393
An anonymous reader writes "Canonical has laid out their plans for handling UEFI SecureBoot on Ubuntu Linux. Similar to Red Hat paying Microsoft to get past UEFI restrictions, Canonical does have a private UEFI key. Beyond that they will also be switching from GRUB to the more liberal efilinux bootloader, and only require bootloader binaries be signed — and they want to setup their own signing infrastructure separate from Microsoft."
How much of the 'operating system' needs to signed (Score:4, Interesting)
Re:How much of the 'operating system' needs to sig (Score:5, Informative)
Re:How much of the 'operating system' needs to sig (Score:5, Informative)
This smells of the war against terror. There are actually very few pieces of malware out in circulation which rely on rootkits invoked by the bootloader. It's something which we haven't really seen much of since the viruses of the DOS days. I'd rather take my chances with the malware than have the liberties of doing what I want with my computer taken away.
Re:How much of the 'operating system' needs to sig (Score:5, Insightful)
Re: (Score:3)
Comment removed (Score:5, Interesting)
Re: (Score:3)
$50 windows 7 HP, $100 family pack and I'll upgrade ALL of my machines to Win7 from XP. So, I concur.
Re:How much of the 'operating system' needs to sig (Score:5, Informative)
Re: (Score:3)
Go to TPB and you'll see they have "Windows 7 all versions pre-activated" DVD which will give you ANY version from Basic to Ultimate and they all get full Windows Updates using the bootloader hack.
Just a heads-up for anyone considering going to TPB or any other torrent site and downloading one of these things to install:
Welcome to the botnet.
Every single one of them is infected. The ones that scan clean have simply not had their rootkits entered into the malware databases yet, and it takes a good while fo
Re: (Score:3)
Since the certification requirements for Win8 (on x86) mandate that Secure Boot can be disabled, I predict that the instructions for the Win8 version of Windows Loader (or whatever it is the kids use these days) will be roughly:
1. Disable Secure Boot.
2. Run program, click OK
I also predict that for Win9 MS will change that requirement to its opposite, due to the "overwhelming success of the programme" or somesuch, citing the fact that even Linux vendors have signed on as a "see, we're not evil" argument.
I wo
Re:How much of the 'operating system' needs to sig (Score:4, Insightful)
Here's a link for an Office license for $0: http://www.libreoffice.org/ [libreoffice.org]
Re: (Score:2, Interesting)
Absolutely, 100%, this. In doing this, M$ is looking out for its bottom line; it is only tangentially interested in your data security, and then only insofar as it affects said bottom line. The only rootkits "in the wild" that M$ is even remotely concerned about are the ones which circumvent its own activation and policing systems.
Re:How much of the 'operating system' needs to sig (Score:5, Informative)
This smells of the war against terror. There are actually very few pieces of malware out in circulation which rely on rootkits invoked by the bootloader.
Whether or not the reasons they gave are bogus, THIS isnt true. There are TONS of rootkits out there that screw with the bootloader, which is why MBRCheck should be a standard part of everyone's rootkit removal kit. If you ever see a machine with a virus, you must assume the bootloader has been tampered with.
Off the top of my head, Sinowal and TDSS come to mind.
Re:How much of the 'operating system' needs to sig (Score:4, Informative)
Re: (Score:3)
The MBR lock is useless. The fact that dd is able to clone and overwrite the MBR-- the fact that dd even exists-- should answer the question of "why is it useless".
Re:How much of the 'operating system' needs to sig (Score:5, Insightful)
The point isn't to protect against bootloader infections, per se. The problem is that if you use a protection mechanism based on one layer being signed (say, signed application code), then it's made irrelevant by attacking one layer lower. So you need to sign from the bottom-most layer all the way up. That means either a signed BIOS or one that can't be changed in software, a signed bootloader, a signed kernel, signed drivers, and signed application code. The purpose of the signed bootloader isn't to protect against bootloader malware that exists now, but to protect against the bootloader malware that would appear if you started relying on a signed kernel.
I'd rather take my chances with the malware than have the liberties of doing what I want with my computer taken away.
So turn off UEFI Secure Boot.
Re:How much of the 'operating system' needs to sig (Score:5, Interesting)
And how long before Microsoft and/or the OEMs start saying you can't do that?
Re:How much of the 'operating system' needs to sig (Score:5, Insightful)
And how long before Microsoft and/or the OEMs start saying you can't do that?
Not very. And I don't have much hope given the hordes of people on the last article that honestly believed that Microsoft was being altruistic in this and that anyone questioning their motives was a conspiracy theorist/had a low IQ.
Re: (Score:3)
For systems based on one popular architecture, about 6 months ago [softwarefreedom.org].
For other architectures, as soon as they think they can get away with it.
The rootkit would just infect the kernel (Score:3)
Re: (Score:2, Interesting)
I'm less familiar with the workings of Linux, but you generally solve that problem in FreeBSD by setting the kernel modules and the various start up files to be immutable and run the system at secure level 1 or higher.
There's probably still ways of infecting or messing with the boot process, but it's a lot harder when you can't change any of the files to load other code.
Signing the kernel, modules and various start up scripts is probably not a bad idea, but you end up with some trouble figuring out where ex
Re: (Score:2)
you generally solve that problem in FreeBSD by setting the kernel modules and the various start up files to be immutable
Does Windows honor FreeBSD immutability?
Because of rounding (Score:3)
Your suggestion would [...] require them to figure out how to resize partitions without anybody noticing it.
Because of rounding, statistically nobody is going to notice losing 100 MB of a 500 GB partition.
What's more why the fuck would you use immutable files if you're intention is to use it to hijack the system.
One wouldn't use FreeBSD immutable files to hijack Windows. I was referring to using FreeBSD or Linux to hijack Windows, not to hijacking FreeBSD or Linux.
Re: (Score:2)
That's a pretty big if, though. Anyone who is worried about that attack vector can use a signed kernel (as I believe MS is), and those who are more concerned about the signing mechanism itself can minimize their exposure. Folks who are really concerned about it will probably be replacing their BIOSes, but if I understand correctly this compromise will maintain the ability to dual boot with Windows.
Re: (Score:3)
Anyone who is worried about that attack vector can use a signed kernel (as I believe MS is)
But unless the bootloader is designed to require a signed kernel, the bootloader can be configured to load a Linux kernel that chain-loads a compromised Windows kernel. And at that point, Microsoft will add the bootloader to the blacklist in a Windows update.
Re: (Score:3)
But unless the bootloader is designed to require a signed kernel, the bootloader can be configured to load a Linux kernel that chain-loads a compromised Windows kernel. And at that point, Microsoft will add the bootloader to the blacklist in a Windows update.
True, but with TPM enabled Windows Update should be able to download code that checks the boot path status and then alerts the user that their Windows has been compromised. Chapter 8 – UEFI and the TPM: Building a foundation for platform trust [infosecinstitute.com]. TPM is not a requirement for Secure Boot, but I don't really see how it can be that effective without it. I wouldn't be surprised if some pressure is brought to bear on vendors to enable TPM by default.
Re:The rootkit would just infect the kernel (Score:5, Interesting)
the bootloader can be configured to load a Linux kernel that chain-loads a compromised Windows kernel
That strikes me as an odd proposition.... The Windows kernel has a lot of requirements out of its bootloader. ...
While that may be true, GRUB has been booting Microsoft Windows for years now. It may have a lot of requirements, but obviously those requirements have been met.
What you might have forgotten is that boot loaders can simply call other boot loaders. It's call chaining, and it is exactly how GRUB boots Micorsoft Windows. You boot to GRUB, which might configure a thing or two (like hide Linux partitions), and then it boots NTLDR (or whatever the latest Microsoft loader is) and the Microsoft boot loader then satisfies all those requirements for the Microsoft Windows operating system.
It's absolutely possible, of course, but the sheer amount of hackery that is required to make it work is just mind boggling... at least to me. Can you link anything that explains your concept?
I won't link, but consider a mail forwarding service. They receive a letter, the might move it internally through a few mail boxes, and then eventually ship it out to you at your new address. What they don't know is that the new address could also be a mail forwarding service. Chaining two mail forwarding services together will still get the mail to the final destination address.
The above example pertains to boot loaders, except that you have the first boot loader set the environment to "boot something" which happens to not be an operating system (actually boot loaders can not differentiate between an OS and a boot loader, because at that level, there are just programs). Without the motherboard configured to only boot signed boot loaders, any number of intermediate boot loaders could be inserted which could then hijack the booting process, perhaps even to the point where they boot a pre-infected (by some means) operating system.
Hopefully this clears things up a bit. I know that boot loaders are only somewhat understood, even by those who use Linux quite a bit. I don't even pretend to be an expert, but it is clear to me that if you want to assure that a certain operating system is booted as it was delivered by the distributor, you need to control the entire boot process from power on to the kernel launch.
Linux's security model protects itself well post-kernel launch, but even Linux could be subverted by sloppy controls over the booting process.
Re:The rootkit would just infect the kernel (Score:4, Informative)
How/why would the chainloaded [modified] Windows boot manager refuse to run? The way UEFI Secure Boot works is that the UEFI BIOS will verify the signature on an EFI executable prior to passing control to it. The UEFI BIOS largely relinquishes control of the system to the bootloader when it executes it. The bootloader will itself call the next piece of code that runs, not the UEFI BIOS, which is why the bootloader needs to do its own signature verification on the OS (or second stage bootloader) to maintain the trust chain. But, the bootloader absolutely could pass control to something without verifying its signature. And, if that's a maliciously modified Windows bootloader, that second bootloader could be designed to execute a maliciously modified Windows kernel without verifying its signature first.
Re: (Score:3)
It does if the Windows installer wipes only the Windows folder on the Windows partition and leaves alone the Linux partition that malware installed.
The virus can remain on the drive and it will do absolutely nothing unless it has some mechanism to ensure it is loaded. When you reinstall windows, the old install is moved to a Windows.old folder; while viruses may remain in there, they will not be loaded by the new installation, and are no threat unless someone digs thru there and starts running infected files or installing infected drivers from there.
I thought apt-get couldn't be run offline.
By "offline" i meant "stick an Ubuntu Live disk in and install ms-sys to your ram-disk". You can modif
Re:How much of the 'operating system' needs to sig (Score:5, Insightful)
That's what I like about it. They're not even paying lip service to that bullshit official purpose. Red Hat made it sound like they have drank some of the Koolaide, with all their worrying about how the person who owns the computer might abuse an unsigned module to take control of their computer.
Once you're running your bootloader, then the issue is over. There is no need to further check for any other signatures or try to guarantee that the owner can't run their own code. You have satisfied the requirement and thereby gotten the computer to work.
Re: (Score:2)
Re: (Score:3)
Yeah, I thought about that. There are interesting wrinkles, though.
1) Most of those Ubuntu users would be uneffected. The revocation can only happen if you perform a Windows update. If you never go out of your way to run MS code, they can't damage your computer's operation by revoking your permission to run Ubuntu.
But some people do dual-boot, or may wish to instal
Re: (Score:2)
No. As soon as Windows kernel comes up it uses the TPM to determine who loaded it. If the answer is not someone Microsoft trusts (ie, UEFI), the system is running in 'unsecure' mode.
Re: (Score:3)
I don't think malware protection is the main driver of trusted computing. The main driver is allowing others to trust you. For instance, before a site streams a movie to you it can request that your PC attest that it is running a trusted software stack, to ensure that you have not modified the system to enable you to capture the stream on disk. Or before you are allowed access to a sensitive database at your work they can insure that your access is only by approved software.
In order for that goal to be
Re: (Score:3)
Re: (Score:3, Funny)
Windows 9 will require you to insert your genitals between its spinning blades during the boot process...
Re: (Score:3)
Re: (Score:2, Informative)
Nobody is saying secure boot is an inherently bad idea that I see. They're saying they should be able to sign their own stuff and load their keys... I also think its a bit shady that other vendors are in a position where for practical purposes they have to pay Microsoft to get signed.
"Paying Microsoft" actually goes entirely to Verisign, as RedHat clarified previously. But besides that, they definitely don't have to - as Ubuntu is talking about doing, they can always run their own key server. Or load their key manually. Or disable the feature on x86 systems.
Re: (Score:2)
Re: (Score:3)
Nobody said you can't sign with your own keys. However, doing so (and updating UEFI to accept your keys) is not trivial, and is something the vast majority of the users are not going to want to do. If you are trying to convince people to use your distribution (ie Ubuntu) it is up to you to make it easy, whether that means paying Verisign to sign your stuff or convincing hardware manufacturers to load your key for you.
So what do you propose as an alternative - make the manufacturers ship in non-secure mode
Re: (Score:3)
Re: (Score:3)
And the incentive for anybody to do that is what, exactly? If Microsoft, Red Hat and SuSE sign their stuff, the vast majority of corporate desktops are covered. If Microsoft, Fedora, and Ubuntu sign their stuff, the vast majority of consumers are covered. All without the users having to do anything. The hardware manufacturers don't have to do anything special either, except maybe install a few keys. You are asking the hardware manufacturers to design and implement a standard just to make things easy fo
Re: (Score:3)
First off, this isn't going to effect corporate users at all. This system is not going to be implemented for servers and corporate IT departments will control their own systems (and certainly sign them with they own keys).
As for consumers, the largest current Linux distro is Mint. Unfortunately, according to Fedora, keys will only work with the core distro and not with distros based on that core. This means that Ubuntu, Lubuntu, Kubuntu, Mint, etc. will each need their own keys. Which, in turn, means th
Re: (Score:3)
Nobody is saying secure boot is an inherently bad idea that I see.
Secure boot is an inherently bad idea.
It flies in the face of the concept of the machine as a general-purpose reprogrammable computer.
General purpose means user control of all software right down to the firmware.
The line that secure boot is intended to protect against bad guys on the internet is a lie. The way to do that is to harden network connectivity & all applications that access the network.
The line that secure boot is there to protect against other attack vectors such as the insertion of a USB d
Re: (Score:3)
If the purpose of secureboot were just to secure the boot process, that's all it'd take. The whole system of key signing is a rather obvious attempt to squeeze all the little players out of the game so the big boys can seize more power and profits.
Re: (Score:3)
Something like a config option - 'Enable OS installation for one boot cycle.'
If the purpose of secureboot were just to secure the boot process, that's all it'd take.
That limitation isn't possible, because the UEFI/BIOS is not a hypervisor. Once something else is running in ring 0 there is no way to prevent it from doing whatever it wants. Implementing those kind of hardware locks would entail a much more serious change to many parts of the PC architecture.
The whole system of key signing is a rather obvious attempt to squeeze all the little players out of the game so the big boys can seize more power and profits.
Despite the above, this statement is probably quite accurate, though. It's certainly a convenient side-effect.
Re:How much of the 'operating system' needs to sig (Score:4, Insightful)
I meant for Microsoft to add that capability to its OWN OS. Obviously it could not enforce such a restriction in Linux; I would think there, if there were a need for such protection, someone could write a kernel module that did the same thing and was an optional component for hardened installations.
What Im saying is that rather than doing this at an EFI level and crippling all OSes, each OS maker should be responsible themselves for making sure that the MBR is untampered with.
There shouldn't be any key by default!!! (Score:4, Interesting)
What you have to understand here, is that Ubuntu is only adding yet another layer of vendor lock. It's not better than the one from Microsoft.
The only REAL and TRUE freedom and equality would have been to ask all users to first type a fingerprint before they can use their computer for the first time. Having keys already installed in the BIOS by default is a pure travesty.
And don't tell me that too hard to do for the average user. There's in fact only 2 categories for which it is the case: blind people and those who shouldn't ever touch a computer anyway.
Re: (Score:2)
UEFI SecureBoot is a catastrophy (Score:5, Insightful)
Along with draconian DRM and anti privacy laws, UEFI SecureBoot is crippling the computer as a tool.
It will take generations and countless wars to undo the damage that is currently being done.
Re: (Score:3, Interesting)
My 24" Core 2 Duo iMac has EFI Boot. It didn't stop me from installing Linux Mint on it last month (full format & repartition of the hard drive, not as a "guest"). Can someone help me understand what's the difference?
Re:UEFI SecureBoot is a catastrophy (Score:5, Insightful)
Because Apple doesn't care if you load Linux - they're a hardware company (well, user experience company, but anyways). You've already bought their hardware and software. But Microsoft, which has the x86/x64 non-Mac world by its balls, is a software company, so they will do things that strategically make non-Windows software harder. So a similarly-capable Acer, as an example, is going to be more locked down than your Mac.
Hence, I'm slowly finding myself thinking of buying Mac hardware again, even given the higher-than-I-need quality (and price).
Re:UEFI SecureBoot is a catastrophy (Score:5, Informative)
Of course they care. If you don't use their operating system you are much less likely to use the services they have tailored to that system, like iTunes and iCloud and iWhatNot.
No, they really don't - you already bought the hardware. iTunes, iCloud, the app store, the music and movie stores etc exist to sell the hardware.
You can see this by looking at their financial statements (unless you think they're lying on a massive scale, in which case report them to the SEC) - the hardware division, on both the iOS and OS X sides of the equation are where the profit is made.
They'd love you to buy a Mac and run Linux on it - you bought a Mac and gave them 90% of the profit they'd expect to get from you as a customer. The 20-30% margin on a $1-2k purchase is the lion's share of the money they make from you. The $0.30 they make from you every time you buy a song, or the cost they incur by giving you free iCloud access is peanuts in comparison.
Re: (Score:2)
Re:UEFI SecureBoot is a catastrophy (Score:4, Funny)
Because noone in their right minds would ever install iTunes on Linux, given how catastrophically bad it is on Windows.
Re:UEFI SecureBoot is a catastrophy (Score:5, Informative)
Unlike iOS devices, Macs aren't configured (yet) to require a signed bootloader. This is only an optional feature of EFI.
Re:UEFI SecureBoot is a catastrophy (Score:5, Informative)
The difference is that you have an iMac that currently does not use the EFI Secureboot features, as I understand it. If you purchase a Windows 8 certified PC, those are the ones that will be requiring the EFI Secure Boot.
I told my friends & family that I have bought my last Windows PC, shortly after I purchased a Macbook a few years ago...turns out that may have been a good choice...
I'm not going to encourage PC manufacturers to bow and kowtow to any one software vendors wishes. If I buy my hardware from [insert your favorite PC maker here] and I want to install some oddball software on it, say AROS, or ReactOS, then that is what I should be able to do without having to wage war against EFI or any other "security features" that may prevent me from installing software that I want to use.
That's a bit of a rant...but things like this that don't make sense to me are hot-button issues with me...
Re:UEFI SecureBoot is a catastrophy (Score:4, Funny)
Well let's see...
"My 24" Core 2 Duo iMac has EFI Boot" vs "UEFI SecureBoot is crippling the computer"
hmm...
"My 24" Core 2 Duo iMac has EFI Boot" vs "UEFI SecureBoot is crippling the computer"
ehhh...
"My 24" Core 2 Duo iMac has EFI Boot" vs "UEFI SECURE Boot is crippling the computer"
humm... nope can't see a damned thing different.
Re: (Score:2)
But this is slashdot where we believe Macs are DRM'd to hell and only idiots would buy into Apples iOS walled garden. Derp!
Who would have thought that Microsoft could make Apple look open... Wow.
...or a bootloader (Score:5, Informative)
It will take generations and countless wars to undo the damage that is currently being done.
Or it will take a signed bootloader that let you then load whatever you want.
That's what Canonical is paying for:
they get EFILinux signed.
EFILinux in turn can load pretty much any kernel you want.
- Either an official distro provided one.
- Or your own compiled linux kernel
- Or another system's kernel (*BSD, ReactOS, etc.)
- Or even a better/bigger bootloader like GRUB's stage2.
What we need now is the legislative framework so Microsoft can't revoke the bootloader without attracting a shitstorm of antimonopoly antitrust suits.
Why is this a problem? (Score:5, Informative)
Shouldn't I be able to load my own private key (or that of my distribution of choice) in the UEFI interface and then sign the bootloader I want with it (or use that of said distribution)? Ideally changing the key would only be possible while a jumper on the board is set.
If I trust Ubuntu, then my computer would reject the Windows bootloader and vice versa. Isn't that how it should be?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I'm under the impression that, unfortunately, Windows will run on those machines, they just can't be sold as "Windows Certified". It would be fantastic if they stopped it from being installed. The hardware vendors would love it as a vast number more machines would be sold.
Re:Why is this a problem? (Score:4, Funny)
I'm under the impression that, unfortunately, Windows will run on those machines, they just can't be sold as "Windows Certified". It would be fantastic if they stopped it from being installed. The hardware vendors would love it as a vast number more machines would be sold.
Did I just flip into a Bizarro World where there are a ton of people looking to buy PCs which won't boot Windows?
Surprised.... (Score:3)
Seems like this leaves things open for an MS rootkit. A rootkit that happens to have an entry point resembling a linux kernel seems a likely scenario.
Also surprised with efilinux. It can load from block devices only, which omits network boot. I understand that grub2 GPL3 concerns make sense, but you would think they might go with elilo. It may be less 'active', but it is capable of doing more than efilinux, notably network deployment.
Re: (Score:2)
It can't load GPXE from a small block device?
That seems like it would solve your netboot concern.
*STAGED* boot (Score:4, Interesting)
Also surprised with efilinux. It can load from block devices only, which omits network boot. I understand that grub2 GPL3 concerns make sense, but you would think they might go with elilo. It may be less 'active', but it is capable of doing more than efilinux, notably network deployment.
Canonical specifically stated that EFILinux could be used to a non-signed Grub2 (or maybe they could even sign it through their own infrastrucutre if they can make it GPLv3 compliant). On non-SecureUEFI machine, this is supposed to be the default behaviour they want to do (if EFILinux detects that Secure is disabled, it chains straight to Grub2).
The idea is to load the smallest possible bootloader in signed mode and then do everything else you want from that point onward.
Once EFILinux has chained to Grub2, you can do all the crazy cool stuff you want here.
Just think of EFILinux as a special type of stage1 that is compliant for SecureUEFI devices. (Well technically, the UEFI firmware is the stage1, but you got the idea).
Next -- compilers (Score:5, Insightful)
The next step should be requiring a background check in order to have access to a compiler. Compilers are a subversive tool that is essential to creating malware, the cyberspace equivalent of a chemistry lab. Just as having an unauthorized chemistry lab should automatically make one suspect for creating drugs, explosives or chemical weapons, posession of an unauthorized compiler and of a machine that does not have a secure boot should make one suspect of cyberterrorism.
Of course, this is impossible right now, just as fifty years ago nobody would have taken such a dire view on chemistry. However, the next generation of people raised in fear of pedophiles and terrorists will work hard to make this a reality. And the generation after that will be the blessing of knowing that things have always been like this, since all authorized books will be in electronic format, periodically updated with the best and most recent knowledge about the past.
Since the 7800 (Score:3)
The next step should be requiring a background check in order to have access to a compiler.
Microsoft, Nintendo, and Sony already require this for software that runs on their video game consoles.
Re: (Score:2)
Apple for iOS (so far) as well.
NO a high cost NDA with lots of fine print (Score:2)
NO a high cost NDA with lots of fine print is the next place.
So... (Score:3, Insightful)
Re: (Score:3)
As much as I hate MS in all of this, the cost to sign a binary through MS is $99, always and for any binary. The ability to disable secure boot is in the spec. The reason that MS ensured that this ability exists in the spec is to prevent a cry of anti-trust -- they can always point at it and say, "We made sure there was a way for competing operating systems to get installed." Now, of course, they can run the FUD machine claiming that without secure boot enabled Ubhatse (sounds sexy) can be owned, but MS
Re: (Score:2)
So, assuming the UEFI loads a signed bootloader, the bootloader can run anything it wants.
Yup, run anything indeed. (Score:3)
So, assuming the UEFI loads a signed bootloader, the bootloader can run anything it wants.
Yup, and if you read the phoronix blurb, that's their plan.
Have efilinux run either official canonical kernels, or any custom kernel compiled by the user, or even Grub2 for a more complex boot behaviour (the default behaviour if SecureUEFI is not detected to be active).
This needs to be something you can disable (Score:3)
I have no problem with security features being put in the bios. But if they could potentially make given OS's incompatible then it has to be something you can turn off.
And if you can turn it off then everyone gets what they want.
MS gets a little security on their malware plagued OS. And everyone else can just shut it off.
crazy stuff (Score:4, Insightful)
How can it happen that one company (however large) can seemingly make most of the manufacturers to comply with their crazy ideas? The option to easily disable uefi secureboot _should_ be there on every and each motherboard (desktop, server or laptop). It should not be the manufacturer (and indirectly Microsoft) who decides what kernel and drivers (regardless f the operating system) a user or developer uses. How would anyone make custom kernels and/or modules (Linux) and/or drivers (e.g. Windows) if signing everything through a 3rd party signing service would be required every time? This is crazy.
Second, I don't like where Fedora/RH and Ubuntu are going with this. Aligning with MS on this issue is definitely not the right way to go and most people start to see this. Yet, nobody seems to want to find a way out, most seem to even have stopped protesting, or asking for mandatory secureboot disable options. There are not only 2 distros out there, there are a lot more of them, and most of them will not go along with MS-signing kernels and drivers. Also, if Ubuntu goes for a secureboot lockdown scheme, they might be good from the enterprise side, moving away from the average users, and that just might be what they want to do.
Some still say this whole thing is a non-issue and too much fuss about nothing, but if it were so, then please, for crying out loud, why is there so much smoke around about the planned existance or non-existance of a secureboot disable option? If manufacturers would just say disabling will be there always, this whole issue would just go away.
The biggest problem still is that most average users can't see the point in all this, simply don't care, thus unwillingly participating in making it worse for those, who do.
Re: (Score:2)
Because despite what the Libertarians, deluded Linux fans and Microsoft apologists will tell you, Microsoft do have a monopoly in this area. There are no realistic alternatives, otherwise there would have been a mass exodus a long time ago, especially in the corporate sector.
Re: (Score:3)
otherwise there would have been a mass exodus a long time ago
Oh, but there was a mass exodus away from Windows. Native applications have fallen prey to browser interfaces for server applications. That most of the machines are still running Windows is incidental, even if it superficially benefits Microsoft and explicitly benefits Windows desktop specialists.
Re: (Score:3)
How can it happen that one company (however large) can seemingly make most of the manufacturers to comply with their crazy ideas?
Like this: "Our operating system will only run on machines with this idea implemented. We've told all your major customers this, and we've made it clear that we will only sell operating systems to them if they only buy equipment that can handle this. You sure wouldn't want to lose 95% of your customer base." If their market share was 5% rather than 95%, they couldn't pull that off.
wrong information, again! (Score:4, Informative)
Seriously... I read the article the FIRST time this UEFI news was posted from http://mjg59.dreamwidth.org/12368.html [dreamwidth.org], when it was regarding Red Hat, and the edit was already made back then. The money does not go to Microsoft! Why are people still saying this?
It is very misleading to write "Similar to Red Hat paying Microsoft to get past UEFI restrictions" when it is really not the truth.
"Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want)"
my bias: I have Linux on all of my systems, no MS OS around here. Please, stop the inaccuracies and write what is true.
Keep your dirty hands off my PC (Score:3)
I want to boot whatever software I want, not what you gracely will allow me.
Hardware is MINE, not yours!
Flash your UEFI (Score:3)
This would add just one step to the alternative OS setup!
Re: (Score:3)
There STILL might be a way. Most ARM cpu's support a JTAG debugger and the motherboard might even have the required connector (or connector footprint) on it. You could then still be able to flash the bios using the hardware debugger (JTAG). ARM tools to support jtag are open source and there are many suitable JTAG devices available at reasonable cost. OK not a very non-geek frendly way, but it IS possible.
Kill with fire (Score:4, Interesting)
But no, instead they'll institute this ludicrous dance of keys which will impair the end user's boot experience (which is what UEFI should really be all about) without adding a gram of security (loadable modules at runtime = zero advantage from using "secure" boot).
Ubuntu Founder knows about signing ... (Score:5, Interesting)
Hi Guys & Gals,
before you all get worked up, please remember that Ubuntu was founded by Mark Shuttleworth. Mark became a billionaire by running Thawte. Thawte is a certificate authority for X.509 certificates.
My take is he knows a thing or two about such infrastructures and I also think he is a positive influence for the free software world.
have a good day!
Best news ever for open software/hardware (Score:3)
All of a sudden, a genuine reason to buy Raspberry Pi! Sparc/PowerPC workstations and laptops back in demand as being "better for business/medicine/science" when consumer x86 hardware is restricted to tablet touchscreen OS! PC vendors pissed off by Surface offer custom desktops/laptops for running Linux and FreeBSD and without Windows 8 support!
I for one welcome our new diverse hardware overlords.
booting cd's (Score:5, Interesting)
"Booting our CDs will rely on a loader image signed by Microsoft's WinQual key, for much the same reasons as Fedora: it's a key that, realistically, more or less every off-the-shelf system is going to have,...
So that means if my bootcd's that I create or the ones that I have like Hiren's boot cd, bartpe or any other won't work anymore if its not signed by MS ? That means the IT world will get a kick in the balls with this... like Hiren's will pay for the key
Besides, Microsoft made it clear that arm computers which is loaded with windows 8 will make it impossible to disable the UEFI. in other words, no other OS will be possible. Is it me or it's a very bad idea for all of us...except Microsoft which is clear what their intent is with this crap.
No restrictions (Score:2, Interesting)
I work in a lab where we often need to make a custom build machine. There is no way we will accept any kind of UEFI OS restrictions, nor will we pay an extra fee for their removal. If they wish to do business with us and our partners, then we must have the option to install whatever we like.
Chain loading from "secure" boot to libre boot (Score:3)
If that's the case, we'll eventually start to see Debian, Mint, etc. distributions that make use of the Ubuntu boot loader to get the system up and running.
Re:Chain loading from "secure" boot to libre boot (Score:5, Insightful)
And also Windows malware that does exactly the same thing. At which point the Canonical key will be revoked, and all Linux distributions that relied on it will cease to function.
Legal framework (Score:3)
If that's the case, we'll eventually start to see Debian, Mint, etc. distributions that make use of the Ubuntu boot loader to get the system up and running.
...and according to the phoronix blurb even Grub2. (For more complex booting option beyond the small capabilities of efilinux itself).
Just get the EU legal whatdogs involved to hit microsoft with a big legal anti-monopoly hammer, if they ever try to put a "sony-linux" and suddenly decide to revoke the bootloader.
Also, other big players with money (Novell Suse ?) could join the trend and signs other similar boot loaders (elilo got mentionned) to give more such options.
Re:Why not ignore UEFI? (Score:5, Insightful)
Re: (Score:3)
x86 Android tablets shouldn't have this problem. As for laptops, I guess MS is pushing people to buy Macs?
I'm kidding, of course, purists are already buying from System76 or the like, which is why GP says "or steer clear of any large OEM that wants Windows 8." Everyone else will deal with this as RH and Canonical are.
Re: (Score:3)
Re: (Score:2)
FOSS/GNU/Linux people will not purchase Windows 8 signed machines anyway. They will be forced to build their own PCs, which is, guess what, what they do already.
This will force more people to build their own or steer clear of any large OEM that wants Windows 8.
What components will they use? How much will it cost if they go for special non-UFEI components when the majority of the industry is using UFEI motherboards?
Re: (Score:3)
Re: (Score:2)
The tax is $99 per binary signed by MS, total. So if you distribute one copy, yes, it's a $99 tax. If you distribute 99 copies, it's a $1 tax. If you distribute 99 billion copies it's a 1 Zimbabwean dollar tax.
Re: (Score:2)