As I explained in my previous post, we have the code for the Linux Foundation pre-bootloader in place. However, there was a delay while we got access to the Microsoft signing system.
The first thing you have to do is pay your $99 to Verisign (now Symantec) and get a verified by Verisign key. We did this for the Linux Foundation, and all they want to do is call head office to verify. The key comes back in a URL that installs it in your browser, but the standard Linux SSL tools can be used to extract this and create a usual PEM certificate and key. This is nothing to do with UEFI signing, but it’s used to validate to the Microsoft sysdev system that you are who you say you are. Before you can even create a sysdev account, you have to prove this by signing an executable they give you and upload it. They make strict requirements that you sign it on a specific Windows platform, but sbsign worked just as well and bingo our account is created.
Once the account is created, you still can’t upload UEFI binaries for signature without first signing a paper contract. The agreements are pretty onerous, include a ton of excluded licences (including all GPL ones for drivers, but not bootloaders). The most onerous part is that the agreements seem to reach beyond the actual UEFI objects you sign. The Linux Foundation lawyers concluded it is mostly harmless to the LF because we don’t ship any products, but it could be nasty for other companies. According to Matthew Garrett, Microsoft is willing to negotiate special agreements with distributions to mitigate some of these problems.
Once the agreements are signed then the real technical fun begins. You don’t just upload a UEFI binary and have it signed. First of all you have to wrap the binary in a Microsoft Cabinet file. Fortunately, there is one open source project that can create cabinet files called lcab. Next you have to sign the cabinet file with your Verisign key. Again, there is one open source project that can do this: osslsigncode. For anyone else needing these tools, they’re now available in my openSUSE Build Service UEFI repository. The final problem is that the file upload requires silverlight. Unfortunately, moonlight doesn’t seem to cut it and even with the version 4 preview, the upload box shows up blank, so time to fire up windows 7 under kvm. When you get to this stage, you also have to certify that the binary “to be signed must not be licensed under GPLv3 or similar open source licenses”. I assume the fear here is key disclosure but it’s not at all clear (or indeed what “similar open source licences” actually are).
Once the upload is done, the cabinet file goes through seven stages. Unfortunately, the first test upload got stuck in stage 6 (signing the files). After about 6 days, I sent a support email in to Microsoft asking what was going on. The response: “The error code thrown by our signing process is that your file is not a valid Win32 application? Is it valid Win32 application?”. Reply: obviously not, it’s a valid UEFI 64 bit binary. No further response …
Tried again. This time I got a download email for the signed file and the dashboard says the signing failed. Downloaded and verified. The binary works on the secure boot platform and is signed with the key
subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
Asked support why the process was indicating failed but I had a valid download and, after a flurry of emails, got back “Don’t use that file that is incorrectly signed. I will get back to you.” I’m still not sure what the actual problem is, but if you look at the Subject of the signing key, there’s nothing in the signing key to indicate the Linux Foundation, therefore I suspect the problem is that the binary is signed with a generic Microsoft key instead of a specific (and revocable) key tied to the Linux Foundation.
However, that’s the status: We’re still waiting for Microsoft to give the Linux Foundation a validly signed pre-bootloader. When that happens, it will get uploaded to the Linux Foundation website for all to use.
If it a generic Microsoft key and they can’t revoke it just leak the damn thing!
The application is apparently *signed* with a generic key. I don’t possess the key itself. I think the whole business of having to upload your applications and verify you are who you say you are for them to sign is because Microsoft doesn’t trust anyone with an actual signing key (even a company specific one).
Why do you need the signing key? If UEFI recognizes the key and is willing to execute the bootloader what does having the key do for you?
Releasing the pre-bootloader without Microsoft’s OK would be asking to have the hash of the binary blacklisted.
So there is no technical reason, just a desire to stay in the good graces of Redmond. That makes sense for the foundation, it just seemed from your description that there was some technical reason it would not work.
Seems that this is demonstrating a major security flaw with secure boot. What is to prevent someone who doesn’t care what MSFT thinks from going through the same steps and then releasing the shim or selling it to malware authors?
Microsoft Support did seem to imply in their email that it was a technical problem; I just verified manually that the signed binary did actually work.
However, in order to get your EFI binary signed, you have to do it via Microsoft’s sysdev centre. Even assuming you want to get a single piece of malware signed, and you somehow pass the malware checks and achieve that, Microsoft can still blacklist whatever you get signed via the windows update mechanism (which puts hashes straight into the UEFI forbidden signatures database). So, in practice, this exploit would be short lived.
” So, in practice, this exploit would be short lived.”
Modern malwares were created to have a short live, they are intent to be mutated and polymorphic, so this actually is a big flaw!
Most malwares toolkits have an auto update function, so there’s no problem to a malware to change it’s signed loader and continue the infection. Past experiences already demonstrated that Microsoft never update malware database fast enough.
The real malware problem wasn’t fixed…
Leaking a generic Microsoft Key? Any legalities there?
Pingback: Bottomley: Adventures in Microsoft UEFI Signing | Linux-Support.com
I’m a little fuzzy on this whole secure boot thing. I have a couple of questions.
1) Why is it in microsofts control? This seems alarming to me. Microsoft, Apple and (forgive me) the linux foundation should not be in control of something like this. A third party that does not make any major OS should be given control of this process. Even if they are just contracted by Microsoft, it’d give some impartiality to the procedure.
2) Why do we care? From my limited understanding, secureboot can be turned off on all uefi devices (except ARM).
Matthew Garret has some blog posts on why we’re in this situation but the quick precis is that only Microsoft has the OEM relationships, the existing capability to run a CA and, at the end of the day, is mandating secure boot via the windows 8 hardware certification requirements.
Turning off secure boot isn’t that easy: In a secure boot environment, an unsigned loader on a CD/DVD will look like it’s just unbootable media. That’s a pretty high hurdle to today’s people who expect stuff to just work.
The situation that you describe in those two paragraphs – I don’t know, but it seems to me that this is an actionable thing. Someone that is affected by this issue should contact the FTC immediately.
Pingback: Bottomley: Adventures in Microsoft UEFI Signing | PrishLink.com
Unfortunately, the Moonlight project has been abandoned for about a year and a half at this point (we’ve had to focus on projects that could become profitable and Moonlight, being a free browser plugin, just couldn’t ever be profitable).
Pingback: Организация Linux Foundation столкнулась с трудностями заверения UEFI-загрузчика ключом Microsoft | AllUNIX.ru — Всероссийский портал о UNIX-системах
Deals with the devil usually are.
Pingback: The Mind of David Krider » Reading the Microsoft Tea Leaves
For getting Silverlight running under wine, you may want to look at the work that Erich Hoover has been doing (http://www.compholio.com/) specifically the patches he just realized to get Netflix to work (http://www.compholio.com/netflix-desktop/) under Wine on Ubuntu.
How is Microsoft controlling the boot process not anti-competitive and illegal behavior? What does the European Union think of this? The EU fined Microsoft hundreds of millions of dollars long after the United States bailed on holding Microsoft accountable over Microsoft’s allegedly illegal tactics to run Netscape out of business. Versions of Windows sold in EU nations have to give users a browser choice when they initially setup their machine instead of just defaulting to Internet Explorer.
I would think the best long-term permanent fix (although probably also the most costly, troublesome, and time-consuming one) would be a legal challenge against Microsoft for forcing UEFI signing on non-Microsoft operating systems and bootloaders.
The EU won’t do any serious steps against those mega corporation, as it is built and controlled by the very same cliques that control mega corporations. (remember: the EU was invented by the Bilderberg criminial club directly after WW2, the same people who brought the Europoean totalitarian regimes to power and engineered the war, and also attempted a military fascist coup in the US)
And these little fines against M$ are nothing but a decoy. M$ – and the mafia behind – got back way more indirectly by the bailouts for the totally bancrupt international banking/financial mega corporations – payed by the European taypers.
So, never ever put any hope in that Bruxels Sowjet Regime. They are same enemy of humanity itself, as M$ it.
Instead – as long as or nations aren’t fully destroyed yet – we should use their legislature to file criminal charges against the responsible persons from M$ as well as collaborating hardware companies.
Are you aware that you come across as a ridiculous paranoid delusional tinfoil hat wearing conspiracy nut, thereby completely undermining any credibility you might have had?
Then you are just completely naive.
He is paranoid nuts and your naive idiot. The rest of us is in between.
Microsoft bind OEMs to UEFI secure boot (which no PC OEM will reject). This is not wrong by itself (MS asks something supplemental). The wrong part is the OEMs not allowing “user” keys or disabling secure boot (or making it extremely hard). In the “perfect” world, RedHat, Ubuntu and every other distribution should talk to the OEMs and negotiate keys with ALL of them. Also experienced users could upload their own keys to the firmware (thus secure boot ending up being a “things that user trusts” instead of “things that OEM/MS trusts”).
MS already has those contacts, to it’s cheaper+easier (even with these hurdles) to get a MS-signed (pre-)bootloader that will work by default on all existing systems. Unless MS clearly refuses it. But this will never be hold in court as anti-competitive because the OEMs are 1st link in the chain. And let’s face it, even a suit agains OEMs will highly-unlikely bring updates to old HW, not to mention the funds required to sue many OEMs.
So let’s face it, MS approach is the least painful….if it succeeds. It could make 100% of the systems work “now”, instead of maybe 60% in 2-3 years in the OEM-suing approach (and no! I’m not defending MS…I’m using Win7 just for games thanx to VT-d).
PS: making separate keys for all distributions is also impractical because it would require too much flash space, and, if accepted by OEMs, it would lead to a 1st-come 1st-served priority for distribution keys (e.g.: Mint working on HPs but Knoppix working on Dells instead). And let’s not mention future blacklisting.
Pingback: Организация Linux Foundation столкнулась с трудностями заверения UEFI-загрузчика ключом Microsoft « conon print
Is there any reason that, this being an automatic process, one couldn’t just get Grub’s stage1 signed and use that to chainload absolutely anything?
A couple of things: 1) Grub is GPLv3 which you’re required to certify the binary isn’t and 2) even if you use the pre-v3 grub, it will boot anything and could be used to boot a UEFI virus payload silently. The latter will get either your key or the hash of the grub bootloader revoked.
While you are right, anything can still be booted, the idea is that MS bootloader (which the malware still has to load, otherwise what’s the point) will check and stop. It happened to me on Win8 consumer preview when I changed the boot order thought debian on my Lenovo laptop (although UEFI was loading the binary itself…but maybe the bootloader was too agressive). In other words, the bootloader can check that it was loaded from a signed enviroment (so grub loading Win8 will surely not work).
Pingback: Delays beset the Linux Foundation’s Secure Boot workaround | Up to the hour news
Pingback: Delays beset the Linux Foundation’s Secure Boot workaround » Breaking News | Latest News Headlines | Top Stories
Pingback: Delays beset the Linux Foundation’s Secure Boot workaround | NEWS ONLINE
Pingback: Computer News » Delays beset the Linux Foundation’s Secure Boot workaround
Pingback: Delays beset the Linux Foundation’s Secure Boot workaround » Nottingham PC Repair
Pingback: Delays beset the Linux Foundation’s Secure Boot workaround | Random tech stuff
Pingback: Delays beset the Linux Foundation’s Secure Boot workaround – LiveTechTV
Microsoft can go fsck themselves.
I will not buy any hardware that does not allow one to easily disable UEFI, and I will advise strongly against anyone else doing so.
It is NOT Microsofts place to have ANY purvey or control over what software is allowed to run on hardware they did not make. I refer anyone that thinks this is a good idea to http://www.gnu.org/philosophy/right-to-read.html
On EVERY machine I come across which has UEFI, I will disable it, and if there is any way to “save” the disabled state I will do so.
Their OS will still be an insecure pile of crap. UEFI isn’t about security, it is about lock in.
UEFI != UEFI (in)Secure Boot, just in case. There’s a mobo sitting next to me which does the former but doesn’t (and cannot) do the latter as is.
Addendum:
I will not use or purchase any software which requires UEFI hardware.
I will not use or purchase any hardware which requires UEFI signed software.
I urge others to do the same. I urge Linux distributors to offer easy to follow instruction for disabling UEFI, along with an explanation of why UEFI does not to improve use security, rather than giving microsoft money to get their approval/signature.
I don’t think you understand. UEFI allows for booting off of drives larger than 2TB, and allows for more than 4 primary partitions on a drive, and a whole host of other improvements that BIOS simply doesn’t have a concept of. UEFI is not the enemy here. And UEFI Secure Boot in theory isn’t the enemy, it’s the onerous and draconian measures required and the system currently in place to get signed to be allowed to boot on a Secure Boot machine.
He understands, alright. The question is “Do you?”.
What he is saying, and what I also agree with, is that the price Microsoft is forcing Linux users to pay is TOO HIGH.
Microsoft controlling your every use of your hardware, and who can say that they won’t change the terms after most distros have jumped on board, is not a condition that the FOSS community should even be considering. Bottomly’s experience only confirms that.
There are hundreds of Linux distros that would evaporate in the UEFI environment because they could never get their binaries signed. Those many distros, often ridiculed by opponents of Linux and FOSS, are the seed beds of improvements in Linux. The “LiveCD” is one such example, and it is singularly responsible for enabling Joe and Sally Sixpack to easily install Linux on a box that came with Windows pre-installed. Without it Linux would not be a major force that it now is on PCs and servers. And, of what value would the source code be to Joe Q. Developer if he has to step through Microsoft’s hoops in order to get a modified binary re-signed? If Bottomly and the LF are having these problems what influence would the smaller distros have?
The pretense of EUFI was supposedly to block the ability of the bad guys to put vectors to Trojans in the MBR or the recovery partition on Windows boxes. There is no proof that it will prevent the bad guys from doing so anyway, but there is now plenty of proof that it is very good at blocking the installation of Linux on the majority of devices running Win8. Considering the history of Microsoft’s scoff-law, anti-competitive attitude and actions, those Penguins who think the continued uptake of Linux by the masses won’t be severely hindered by UEFI are living in a fools paradise.
Right now, with Black Friday sales, it would be a good time to stock up on two or three Win7 laptops, store their batteries in the refrigerator, and wrap them up in plastic to insure the availability of a Linux compatible box in the near future. Then, become part of the political action to remove Microsoft’s monopolistic grip from the PC OEMs and bring them to justice for all the crap they have done since the DOJ trial.
UEFI is not a requirement for 4 primary partitions. That’s Gui Partition Table (GPT) and it does not depend on UEFI.
Pingback: Delays beset the Linux Foundation’s Secure Boot workaround | Printing Service Ft Myers
Pingback: Delays beset the Linux Foundation’s Secure Boot workaround - International News
Pingback: Delays beset the Linux Foundation’s Secure Boot workaround | Daily News!
Pingback: Microsoft Holding Keys To Linux Foundation’s Secure Boot Solution | Up to the hour news
Pingback: Wisst ihr, was noch schwerer ist, als bei BASE zu kündigen? · D. Kriesel
Fuck M$.
Pingback: Linux Foundation kämpft mit Microsofts Secure-Boot-Signierservice | virtualfiles.net
Pingback: Delays beset the Linux Foundation’s Secure Boot workaround | technewsforyou.com
Why don’t you wrap the UEFI binary in windows?
Instead of using lcab and osslsigncode you the “right” microsoft tools.
I bet signing works then. I assume lcab and osslsigncode are not 100% compatible for the signing process.
Since you only need the signature to proceed with the bootloader I see no reason not to create it with native windows tools.
Actually, I didn’t say, but the first time, I did use all the MS tools. That was the submission that got stuck in the signing process. The second submission which was done with the open source tools is the one that succeeded (at least it gave me back a signed binary even if the signature was with the wrong key).
I don’t think there are any material differences between the tools because both the cab format and the signing process are published standards.
The main reason for not using windows tools is that I’m used to openssl. Additionally, although I think openssl has a rather confusing interface, the Microsoft tools make it look slick by comparison.
It’s pretty annoying and disturbing that you have to depend on a 3rd party software developer company (yes, I mean Microsoft) when you want to run your own operating system on your own purchased hardware. Actually, as someone having been around computers and software for 19 years [1], I find this very objectionable and totally unacceptable. Also, the way things are going right now regarding Microsoft’s signing procedure – based on the original blog post above – doesn’t exactly suggest that Microsoft wants to make others easy to get signed. And, unfortunately, history tells us you can’t always be optimistic regarding Microsoft’s self-proclaimed benevolence in such matters.
[1] I’m stating this because someone young and growing up in the constrained world that Apple and Microsoft are forcing on the rest of us, might just think this is an acceptable way of doing thigs, since it fits right into the picture. Well, not my picture.
Question: when all this is said and done, will there be ‘dummy-friendly’ instructions made available on how to change the UEFI keys so that a notebook with Secure Boot can run a distro of our choice?
I have read your earlier articles about updating the keys but I still can’t seem to wrap my head around the proper procedures. As for the key that you are generating, is it a signature (ie, one of those db.x.cer) file? Am i right to asuume that the signing service will not generate any KEKs, only signature keys?
Also, what would end-users need to do? Let’s say I want to install Distro XYZ on a Secure Boot notebook, how do i enrol the signature key into the UEFI Secure Boot firmware? Using the distro’s LiveCD, or within Windows?
Any idiot-friendly, step-by-step breakdown /instructions will be greatly appreciated.
This explains how to create the keys for at least the tianocore key manager to install. I also produced a set of uefi programs to do this programmatically as explained here
It’s not for novice users, but it’s certainly possible (I’ve done it). If you don’t want to risk your actual hardware until you’re sure you know what you’re doing, I’d play with these in the OVMF qemu environment first.
they are using the uefi secure boot to block linux from working on pcs not to make windows more secure
Wrong….(or should I say the spec is so flexible that this cannot be proven)….how many “browsing-only” friends do you have? How many of those run OSes other than Windows or Apple? Secure-boot was meant for them, to reduce malwares, rootkits etc (note: reduce…not eliminate). On systems already with Windows installed (or iOS, but they don’t work with OEMs).
The experienced users know how to handle malware and they will not call MS tech support for it. But those are the users hurt by secure-boot. And not because MS requires it, but because OEMs don’t bother with anything other than MS. UEFI Secure Boot spec allows for user control, but again, OEMs don’t bother. It’s like ESP on cars….laws require it, so it’s there, but some manufacturers allow disabling it, others just allow it down to minimum, so track days are a pain for those that really can drive fast and are hindered by ESP.
This is probably the most sane, mature, reasonable and objective answer ever given in this discussion.
Which is a far cry from those who have become part of the ‘OMG-UEFI-AND-SECURE-BOOT-ARE-EVIL’ peanut gallery.
The spec on its own is reasonable, sane and potentially very useful. Only the implementation is borked. And borked implementations can (eventually) be fixed. Which is much better than specifications that were already borked right from the design stage.
Well, MS knew darn well that many or most OEMs wouldn’t bother implementing MS’s “Secure Boot” requirements properly and sensibly, if MS didn’t require them to, and that left to themselves these OEMs would generally implement Secure Boot only partially (at least for consumer hardware) — in other words just well enough to boot Windows 8 and thus meet MS’s needs and requirements (too bad for everybody else). MS coyly insisted that this was nothing to do with themselves (and of course, MS’s history of backroom deals, behind the scenes pressure and outright dirty-tricks was blandly ignored and denied).
After enough fuss was made, MS updated the official requirements for Windows 8 Certification and the Windows 8 Logo program, to also require the ability to turn off “Secure Boot” and to require some sort of user-controlled key management.
But only for PCs — for ARM devices (including but not limited to MS’s own Surface RT) to qualify for Windows 8 Certification or Logo, the ability for users (aka “owners”) to disable “Secure Boot” or manage their own boot keys is actually, explicitly forbidden.
You FOSS people have always hated MS with a passion, so why do you even CARE that you cannot disable SB on a Surface?
Devices shipped with ARM hardware are appliances, NOT computers. Just because they function like one does not mean that they should be classified as one.
Linux users are sitting on Microsoft’s tree, and this tree includes Microsoft’s hardware partners who have been contracted to make hardware for Windows. Be prepared to be the first to fall off the tree in the most spectacular manner whenever Microsoft goes pruning or simply gives it a kick.
If you don’t want to fall off this tree, get the whole FOSS community to grow their own tree complete with OEM support. Apple had grown their own tree to huge success.
After 2 decades, where is the FOSS / Linux tree? Not even planted yet. All the community wants is to pluck the fruits from Microsoft’s tree. Now that Microsoft has sprayed pesticides on the fruits, you’re complaining that you’re getting harmed by the pesticides.
Pingback: Uitstel voor Linux-sleutel in bootslot Windows 8 | Tech-nieuws
Pingback: Microsoft tenta boicotar o Linux mais uma vez com o Secure Boot | Blog Seja Livre
Pingback: Организация Linux Foundation столкнулась с трудностями заверения UEFI-загрузчика ключом Microsoft : Записки начинающего линуксоида
Pingback: News Linux na maszynie z „bezpiecznym startem”? Nie tak prędko…
Pingback: История о том, как Джеймс Боттомли из Linux Foundation пытался подписать в Microsoft загрузчик для UEFI secure boot | BSFZone
Pingback: Microsoft Proves Techrights Right by Screwing UEFI ‘Partners’ | Techrights
Pingback: Microsoft dragging its feet on Linux Secure Boot fix :: WES Computing
http://www.iheartubuntu.com/2012/11/ppa-for-netflix-desktop-app.html
There has been some work to make siverlight work in wine.
Next is big question. http://en.wikipedia.org/wiki/Microsoft_Silverlight
Silverlight is to be come a disconuined product this year. So why in heck are we required to use it to get signed boot loaders or anything else signed.
I wish that the Linux Foundation, with its hundreds of industry members, would work to reverse the ridiculous “secure” boot requirement for Win8 certified hardware, and push hard for open hardware. How is this not illegal collusion, just like all of MS’ anti-competitive baloney? Not that any government regulators care.
Pingback: Microsoft dragging its feet on Linux Secure Boot fix | Linux eGuides
Pingback: История о том, как Джеймс Боттомли из Linux Foundation пытался подписать в Microsoft загрузчик для UEFI secure boot | Социальные новости
Pingback: Linux Foundation luta por assinatura do Microsoft Secure Boot | Nerdices.com.br
Pingback: <° Linux | Las Aventuras en el Firmado UEFI de Microsoft
Pingback: Где мой гранатомет?! | zhevak
Pingback: El porqué del retraso del Secure Boot de la Linux Foundation
Pingback: El porqué del retraso del Secure Boot de la Linux Foundation | Ayuda Linux
Pingback: Microsoft Screwing The Linux Foundation - Linux Rants
Pingback: Linux Foundation: problemi con le firme UEFI di Microsoft | oneOpenSource
Pingback: "Delays beset the Linux Foundation's Secure Boot workaround"
Pingback: Linux Foundation UEFI Secure Boot key for Windows 8 PCs delays explained
Pingback: Linux Foundation UEFI Secure Boot key for Windows 8 PCs delays explained | Up to the hour news
Pingback: Linux Foundation UEFI Secure Boot key for Windows 8 PCs delays explained | My Blog
Actually, a opportunist hardware OEM might have a massive opening here if they work with some of the major Linux & BSD distros.
The only thing that ‘opportunistic’ OEM needs to do is to ship machines with UEFI firmware that always defaults Secure Boot to ‘setup’ mode instead of ‘user’ mode.
Not going UEFI is a major mistake and being short-sighted: the traditional 24-bit BIOS can only support HDDs with a maximum size of 2TB. 64-bit UEFI firmware remove this hardware limitation big time.
System76 is not going to cut it: based on emails circulated around in June this year they are still insisting on the traditional BIOS, and I believe ZaReason is no better.
Pingback: Microsoft dragging its feet on Linux Secure Boot fix
I think it is time you sue MS and a few PC makers. This is an unacceptable situation.
Those OEMs came into the business with the sole intention of being WINDOWS (and Microsoft) partners.
You have no grounds for a lawsuit: this is Microsoft’s tree you are sitting on. Microsoft grew this tree purely for itself and its partners to live in. You want in, you play by their rules.
Otherwise, go grow your own FOSS tree complete with hardware OEMs that ship systems with UEFI that default to ‘setup’ mode instead of ‘user’ mode.
Stop buying Windows hardware. Buy hardware from companies that sell Linux hardware.
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs « Whats-Hots.com | What Hots News and Trends in The World
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | allcom.se
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | The Worlds Tech Blog
Pingback: Tech Gadget Reviews » Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs ← techtings
Pingback: » Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs » webaligns
Pingback: | Got2.Me
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | GabsGroup
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | My Daily Feeds
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | |
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | Appyummy
Pingback: Free Warez at putraidomandiri.com » Blog Archive » Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs
I am completely confused by the bit about having to wrap the bootloader into a Windows Cabinet File in order to get it signed.
What on earth is the point of that?
Isn’t it a totally unnecessary and arbitrary complication?
I’m pretty sure (I’m not an IT guy) that UEFI doesn’t require cab files.
Surely EUFI can boot non cab files?
And how do you end up with a signed bootloader, unless MS unwraps the cab file, signs the contents, re-wrapps the binary and presumably signs that, too?
This strikes me as somewhat ludicrous. Rube Goldberg would be impressed.
Pingback: Pctwix.com – Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | Pctwix – Technical News never delivered
Pingback: Technable | Making you Technically Able
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | Price Gadget Reviews
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | i-Newz
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs – Nieuws over Gadgets en elektronica
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | 1v8 NET
Pingback: Tech Buzz » Blog Archive » Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | Tech...Meets...Blog
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | BroadwayAllDay : ENTERTAINMENT x TECH x CULTURE
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | Electronics & computer accessories
Pingback: | swanksocial | Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs |
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | eMagility :: defining mobile agility
Pingback: La Fundación Linux se demora en la obtención de una llave UEFI firmada por Microsoft debido a problemas técnicos - Radio Lógica FM 91.7 Mhz
Ok, so getting an MS-signed key is a short-to-(hopefully not)-medium term solution.
But are people working on a long term solution to this problem?
In a single move not only did MS release an unpleasant OS that will probably push more people to move to or at least try Linux, but also locked next generation of (secure) hardware only to its own OS.
Yes, in the long term, the distributions are working on solutions to take advantage of UEFI secure boot with the purpose of enhancing Linux security. The main projects are Matthew Garrett’s shim and SUSE’s MOK with all signs being they’ll actually produce a single joint solution.
I’ve just send this email to the Linux Foundation in the hope that they’ll pick up the idea if possible:
Regarding this whole issue of why we need some OS provider to grant other OS providers access to secure boot is really beyond me.
But Has the Linux Foundation tried to establish, like Microsoft did, it’s own
OEM relationship ? This will place the Linux Foundation key also into UEFI.
The way it is done right now by MS and the OEM’s can be seen by the European Union as Illegal because of it’s possibility, if desired by MS, to block access for other OS’s and thus falls into Cartel forming/illegal practices.
You as the Linux Foundation can directly address this concern to our well known Miss Nelie Smit Kroes, Vice-President of the European Commission, her department has dealt with Microsoft before.
I can guarantee the LF that she’ll be very interested in this issue !
She can force the OEM’s to incorporate the LF key into UEFI !
http://ec.europa.eu/commission_2010-2014/kroes/index_en.htm
Pingback: Linux Foundation vet explains setbacks in getting a Secure Boot key for Windows 8 PCs | AIVAnet
Pingback: Linux Foundation UEFI Secure Boot key for Windows 8 PCs delays explained | Linux eGuides
Parece que los organismos antimonopolio, estén distraidos, aunque lo más probable es que estén amordazados en algún sótano.
Esta desvergüenza por parte de Microsoft, tampoco es para sorprenderse, como si fuera la primera vez que los de Redmon, se lian a patear la ética.
Ya sabemos que a Microsoft no se le da bien el manejo de la ética ( y a Apple menos), y creo que el del programario tampoco.
Ya hace tiempo que decidí negarme a pagar y usar su bugware. Pero esto del “Unsecure boot” es el acicate que necesitaba, para lanzarme en brazos del hardware libre.
Aún no sé como lo haré, si con Arduino o similares o por otras vías. Pero lo que tengo claro, es que no quiero que esos zanguanganos vean un sólo céntimo de mi dinero.
Al menos hasta que sus múltiples gadgets a la venta, incorporen el factor ética. Y como creo que eso es algo que yo, ya no veré.
Por mi, ya se pueden ir confintado sus Xcajas, Kinects e iMierdas, e írselas introduciendo por el recto, hasta llegar a la nuca.
Todo esto, dicho desde el cariño y el respeto. Exactamente en la misma proporción del que Microsoft gasta con sus usuarios. Y ahora, del que intenta gastar, con quienes no lo somos.
Pingback: Old Click » Linux Foundation UEFI Secure Boot key for Windows 8 PCs delays explained
Pingback: Enterprise Efficiency - Sara Peters - Prepping for Secure Boot in Windows 8
Pingback: Linux (slowly) comes to Windows 8 PCs with UEFI secure boot | Up to the hour news
Pingback: Old Click » Linux (slowly) comes to Windows 8 PCs with UEFI secure boot
Pingback: Linux (slowly) comes to Windows 8 PCs with UEFI secure boot | Linux eGuides
Pingback: Linux (slowly) comes to Windows 8 PCs with UEFI secure boot | Padroni.net
Pingback: Linux and Windows 8 UEFI secure boot issues | Up to the hour news
Pingback: Linux (slowly) comes to Windows 8 PCs with UEFI secure boot « DMTassinari Associates
Pingback: La Fundación Linux se demora en la obtención de una llave UEFI firmada por Microsoft debido a problemas técnicos
seems to me that specifically not allowing GPL and other similar licenses is the death of open source….. time to let the lawyers out of their cages…..
Pingback: UEFI Secure Boot Resources | Tom's Blog
Pingback: I am still not buying the “new open source-friendly Microsoft” bullshit – Nudged Elastic Band is my band name