This trademark won’t make sense unless you’ve read this FUD:
http://tmrepository.com/fudtracker/everything-microsoft-does-it-does-to-destroy-linux/
To quote FBM on OMGCheesecake:
“Am I the only one seeing the flawed logic there?
1. Microsoft makes UEFI a requirement for Windows 8.
2. UEFI supports a new feature, Secure Boot, which requires a chain of trust until the bootloader.
3. GRUB can’t be signed because of some GPLv3 bullshit.
I don’t see how this makes Microsoft the culprit. To me, the first culprit is the GPLv3, for not allowing GRUB to be signed. Then, it’s the OEMs if they don’t make an option to disable Secure Boot. But why MS, seriously?
Also, let’s not forget that the Windows bootloader is perfectly capable of booting Linux. All it takes is declaring a boot sector (which is a regular file on the HDD) in boot.ini. The bootloader will then load it as if it was the HDD’s MBR.
Whenever I need to boot my Linux partition, I do it with the Windows bootloader.”
LILO will also not face these problems as it is BSD licensed.


Comments
Microsoft isn’t directly the culprit. I’ve read some analysis by Linux developers and my impression is that the GPL issue is circumstantial. The real problem is that there’s no central certification authority for UEFI signing keys. Furthermore there still is some uncertainty about UEFI specification about hash algorithms. There’s been disagreements between Intel and Microsoft about signature design, which wasn’t resolved until sometime this year.
Even if Windows 8 ships with Secure Boot enabled, if nothing changes from its current situation, we’ll still have a quite messy implementation in that there’s no real common standard. If that will the case I believe there’s at least reason to be critical of why not make Secure Boot right from the start.
Whereas the various start-up scripts for *nix systems adhere rigidly to a common standard, right?
I should have thought that the Loons are, by now, quite accustomed to hitting a moving target during the start-up process. If you’re right, this is just one more element in the chain.
The “certification” non-issue is just that. How does certification inhibit your 0.000002 million eyeballs from luxuriating in the awesome open-ness of a small and very badly designed piece of utility code?
Good to know that Linux is so Inherently Secure that it magically knows when something else has booted up in its place…
That’s not the point DrLoser. You could even exclude Linux all together and you’ll still have an argument over why not settle for a working UEFI standard and get a certification authority in place.
I think you need some loons getting on your nerves, because if that’s your reasoning, it’s worryingly complacent. On on hand you’re ridiculing something you view as hacked up, while at the same time neglect something that at the moment without doubt is hacked up.
There are technical issues to solve, so what’s your real argument for not addressing them?
“Microsoft isn’t directly the culprit. I’ve read some analysis by Linux developers and my impression is that the GPL issue is circumstantial. The real problem is that there’s no central certification authority for UEFI signing keys.”
There is no “central” certification authority for any other kind of signing keys either, but yet I haven’t heard anyone complaining about their online banking service showing up as untrusted on their browsers.
Analysis my rear end.
@ JoeMonco
That’s to compare apples and oranges. Certificates you refer to are distributable to end-user, and you as a user decides whether to trust and rely on it or not.
Secure Boot deals with hardware you buy and hence own. It’s like a license. The reference to a “central certification authority”, however its administration will be labelled, is about an organised way to distribute signatures for Secure Boot. Right now everyone would need to explicitly deal with all manufacturers to include their signature, which would be very inefficient and could cause problems for users.
Edit: the sentence “It’s like a license” should be: “It’s not like a license”.
“The reference to a “central certification authority”, however its administration will be labelled, is about an organised way to distribute signatures for Secure Boot.”
There is no organised way to distribute CA certs to your browsers either.
And, no, that’s not comparing apples to oranges. The two are essentially the same technical issue.
Is the GPLv3 really a barrier to signing GRUB2? The way I understand it, hardware vendors don’t have to distribute the signing keys with their products, they only have to give keys of devices to their owners if they request them.
From http://www.gnu.org/licenses/quick-guide-gplv3.html: “This requirement is limited in scope. Distributors are still allowed to use cryptographic keys for any purpose, and they’ll only be required to disclose a key if you need it to modify GPLed software on the device they gave you.”
@Kim:
Oh, but it is the point. I’m happy to take your word for it that UEFI is “hacked up.” 99% of de facto standards, and we normally end up with de facto standards, are “hacked up.”
You seem to be implying that I approve of a “hacked up” (read: currently worryingly botched) standard. I do not.
I am merely pointing out that, to be consistent, Loons would have to admit that practically every other “standard” which they loving proclaim as heralding a new way of Doing Things Right is … in fact … botched.
HTML5 springs to mind. For that matter, any W3C thing at all.
The point is, it’s a bit silly picking on just one botch amongst so many, unless it has serious consequences. I’m open to arguments that this one has serious consequences. I do not yet believe that this one has serious consequences.
@IMGX64:
That’s a very interesting dusty little corner of the GPL, isn’t it?
Yet another fscking sticking plaster in a doomed attempt to deal with reality.
Honestly. Does anybody really believe that the issuer of a certificate for GPL software package X is going to put up with the hassle of issuing a new certificate for every X’ chucked out of mommy’s basement?
I hardly think so.
JoeMonco, I’m not that interested in whether distribution is done through a centralized authority or not. I’m interested in whether companies involved sort out how to distribute signatures. As far as I can understand that isn’t solved. I hope though they do before its rolled out on any significant scale.
@ DrLoser
I know, or more accurately I made the conclusion based or your previous writing, that you don’t approve hackep up standards (I just wanted to make clear what you meant). I agree that what becomes standards often are hacked up, probably because all want their pieces added to the mix.
It potentially has serious consequences, but I will of course not claim to know whether some even want to exploit them. I actually doubt someone will, and I also doubt that it’s that easy nowadays to pull off a “stunt” like that. Hence it could well be much ado for nothing.
> Also, let’s not forget that the Windows bootloader is perfectly capable of booting Linux.
No, it’s not. The only loader I could remember that is capable of loading both Linux and Windows is freeloader from ReactOS. What you’re talking about (let’s ignore 10 y.o. boot.ini thingie for now) is called chain loading (http://en.wikipedia.org/wiki/Chain_loading): current bootloader discards itself and proceeds as if another bootloader has been loaded by firmware in first place. And I’m not even sure if chain loading is supported by UEFI.
As for “centralized store” and other nonsense – WHY? You have a device, you can upload public certificate (presumably x509) to it. Why would anyone want to have this centralized (other than existing PKI).
As for GRUB/GPL3, I see one possible solution. OEM generates unique certificate for each device, signs it with its own certificate and releases public/private pair along with device itself. Oh wait, they will probably just say screw this sh*t – cost/benefit has 0 in denominator – not exactly best way to get OEMs on your side.
“Oh wait, they will probably just say screw this sh*t – cost/benefit has 0 in denominator – not exactly best way to get OEMs on your side.”
You’ve just described how All Things Durden relate to pretty much anyone or anything – no value, only costs.
“Secure Boot” is a euphemism for an attempt to take control of what you are allowed to run on your computer. It’s no different from their Palladium “Trusted Computing” crap.
This is Mafia$oft’s plan in a nutshell.
(1) Mafia$oft requires “Secure Boot” for “security” for Windows 8
(2) Maifa$oft secretly bribes/forces OEMs to only bundle Mafia$oft’s only certs with their firmware
(3) Linux is unbootable on all modern hardware
(4) With Linux and free operating systems dead, Mafia$oft instructs OEMs to extend their firmware to only allow Mafia$oft signed apps to run on Windows
(5) The PC becomes the new console. Software freedom and small/hobbyist software development is dead and only Mafia$oft decides who is allowed to even write software for PCs, which they will reserve only for themselves and select partners.
Anacondas and funnel-web spiders, Adam.
Anacondas and funnel-web spiders.
“Step three: Linux is unbootable on all modern hardware”
So how is this different from the current state, where Linux may actually boot, but then either nothing or only a few things work (and even then, only after invoking obscure eldritch magick).
Linux has always been effectively unbootable, even if your FUD was true, nothing would change.
Adam – (3) Linux is unbootable on all modern hardware
You better not try to boot Linux on any modern hardware, because it cannot recognize any device, which costs > $100.
“You better not try to boot Linux on any modern hardware, because it cannot recognize any device, which costs > $100.”
Can you clarify what “modern hardware” do you mean?
Guys, guys, how about we first wait to see if “secure boot” actually prevents Linux from booting, and then we start bitching about it?
Here is how i think things will pan out: If a manufacturer disables the ability to turn off secure boot, a massive sh!t storm will occur, so they will immediatelly enable it back. It doesn’t cost them anything to enable it. Plus, many companies like HP actually support installing Linux on their laptops and desktops (despite the alleged bribing from Microsoft), so you can bet secure boot will be disable-able in their laptops.
Seriously, this whole paranoia about secure boot came to existence because one freetarded writer in OSNews said that “OEMs will disable the ability to turn off secure boot, like they always do with BIOS features”. What? OEMs disable some BIOS features because they were sick and tired of being flooded with returned machines having stability issues, just to find out later that little Jimmy had overclocked the machine to death. Features that can’t cause stability problems are always there.
P.S. Wanna bet that Ballmer will come out the next week and say that secure boot isn’t about preventing linux from running, and it’s all about preventing OEM copies to be sold as retail copies, or about preventing rootkits from running? In the same way WGA was going to spy on the poor users, according to the loons, while in reality was just an anti piracy tool?
Kurkos, quite surprisingly, I completely agree with you. But I’d replace WGA example with TPM one (which does EXACTLY the same on BIOS machines). SUDDENLY all those tinfoil hat fans are out of woodwork with their IPredict™-ions http://en.wikipedia.org/wiki/Trusted_Platform_Module#Criticism
Almost 10 years after most hardware TPM capable and still no apocalypse. But just you wait, Ebil Mafia$oft is planning to enslave you the same way as it enslaved your software.
I’ll take that bet, Kurkos. I promise you a trillion dollars if … oh, wait. This is kind of repetitive of you, isn’t it?
Twat.
You must be signed in to leave comments.