OK, But What Should They Do?

Story: Red Hat Drinks the Microsoft Kool-AidTotal Replies: 52
Author Content
joncr

Jun 07, 2012
1:02 PM EDT
Secure Boot is going to happen, so the real question is what Linux should do about it?

Complaining about Microsoft won't get Linux booting on new hardware. Neither will all the RMS-tinged rants Garrett's post has prompted this week. Maybe the world should be different. But, it isn't, and it isn't likely to be.

I think Garrett made a convincing case that Fedora/Red Hat have chosen the only viable option. I expect Suse and Canonical to do the same thing.

At this point, Microsoft doesn't need to bully or threaten vendors. They could say Windows 8 won't run on new hardware unless it's covered in pink polkadots and vendors would do exactly that.

If Secure Boot was opt-in, not opt-out, life would be better. Windows could check its status and refuse to boot if it was not enabled.

Onr thing intrigues me, though. What are the chances that Windows 8 users running with Secure Boot enabled will run into problems trying to use "legacy" hardware and peripherals? If someone buys new hardware and plugs an old external drive into it, what happens? What happens if they want to boot off it?

caitlyn

Jun 07, 2012
1:39 PM EDT
@joncr: WIndows 8 won't run on older hardware. Microsoft and Intel have been trying to force obsolescence for years. This is just a new method of doing that.

If you've read my post in the other threads you know I agree with what you wrote. No point in repeating it here.
CFWhitman

Jun 07, 2012
4:40 PM EDT
For now Windows 8 will run on older hardware (retail versions will anyway, which is the same way it is now with Windows 7). However, when Windows 9 comes out, though it may still run on older hardware (because there will probably still be component motherboards sold without Secure Boot), there is no guarantee that it will run on Secure Boot enabled systems made for Windows 8.
MagnusMs

Jun 07, 2012
5:10 PM EDT
There is really a problem with the boot sector that no operating system can check.

The really nasty viruses install themself as the VM controller. The OS will then run as a virtual machine. All anti-virus calls will be returned correctly.

Signing the boot loader is a good method to make it harder for these viruses.

Linux systems can also be cracked and will benefit from this "feature".

The question is just how long will the signing keys remain a Microsoft secret? All game consoles have had their signing keys published
Ridcully

Jun 07, 2012
6:09 PM EDT
I note the post of MagnusMs above and it fits in perfectly with the words I want to add.

Somewhere recently I read a delightful mediaeval crime story involving a "treasure chest" constructed so that to open it, the procedure required three separate keys, each held by a different person. Nevertheless the chest was opened and the contents stolen. The person responsible was ultimately a locksmith, but his statement on being confronted with the problem is a classic: "What one man locks, another can unlock !"

We have a whole "illegal industry" now devoted to marketing copying software designed to copy "locked dvds, whether standard or blu-ray".....we unlock dvd players from their stupidly imposed zone controls by getting the keys from web sites.......and if anyone locks software out of computers others will find ways to not only unlock the process but remove it altogether and my bet is that "certified boot process software" produced by Microsoft will be cracked completely and the "work arounds" made public over the internet.

Microsoft can do what it likes, but it is facing a whole universe of people who do NOT like being told what they should or should not do. The certificate procedure will be hacked and probably has already been hacked by those who wish to do so. And the procedure becomes as inane as the media moguls continuous attempts to lock dvd disks - another merry-go-round of futility begins its pointless circling. "What one man locks, another can unlock !"

I still remain convinced that consumer pressure will ultimately force Microsoft to retreat on this one and for a very simple reason: Win8 just isn't (as far as I am able to ascertain from articles that analyse it) the game changer that Microsoft believes it to be. Microsoft is trying to make secure an operating system that was never designed with security in mind; it's too late. UEFI will make not the slightest difference; Windows will still be attacked as easily as ever: "What one man locks, another can unlock !" - but then, Windows was never designed with any locks.

BernardSwiss

Jun 07, 2012
10:07 PM EDT
I think that one of the most aggravating aspects is how Microsoft appears to have co-opted the terminology, managing to re-frame the issue, successfully labelling sensible, full, managed-key UEFI implementations as "Custom Mode" (Say What!?) and the single-use Windows-only Secure Boot implementations as "Standard Mode".

Perhaps it would be an effective tactic to refuse this framing -- pointing out if necessary the biased re-labelling that Microsoft has been so cleverly pushing -- and consistently call them by more sensible terms, instead,

For example: we could refer to "User Mode" or "Managed Mode",

versus

"Microsoft Mode" or "Custom Microsoft Mode", or "Microsoft 'Default' Mode...

- - -

If big successful corporations like Red Hat feel compelled to spin this loss so cheerily, we need another approach to highlight just how unfair, sneaky and abusive this MS monopoly-power manoeuvring really is...
Scott_Ruecker

Jun 08, 2012
2:14 PM EDT
Quoting:Microsoft can do what it likes, but it is facing a whole universe of people who do NOT like being told what they should or should not do. The certificate procedure will be hacked and probably has already been hacked by those who wish to do so. And the procedure becomes as inane as the media moguls continuous attempts to lock dvd disks - another merry-go-round of futility begins its pointless circling. "What one man locks, another can unlock !"

I still remain convinced that consumer pressure will ultimately force Microsoft to retreat on this one and for a very simple reason: Win8 just isn't (as far as I am able to ascertain from articles that analyse it) the game changer that Microsoft believes it to be. Microsoft is trying to make secure an operating system that was never designed with security in mind; it's too late. UEFI will make not the slightest difference; Windows will still be attacked as easily as ever: "What one man locks, another can unlock !" - but then, Windows was never designed with any locks.


Again my friend Tony hits the nail on the head..in a short amount of time all this will be irrelevant and we will (thanks to the true hackers out there) be able to do as we please no matter the hardware platform.

caitlyn

Jun 08, 2012
4:29 PM EDT
Quoting:Again my friend Tony hits the nail on the head..in a short amount of time all this will be irrelevant and we will (thanks to the true hackers out there) be able to do as we please no matter the hardware platform.
That's fine for you and me as individuals, Scott, and I do expect that Tony is right. Having said that, it isn't an acceptable way for businesses or government to work. Bringing this back to the original article, Red Hat had to come up with some way to insure their OS would work on servers and desktops/laptops alike in an enterprise environment. They did what they had to do. It's just unfortunate that they had to go down this road at all.
flufferbeer

Jun 08, 2012
4:41 PM EDT
@Scott Ruecker

"Again my friend Tony hits the nail on the head..in a short amount of time all this will be irrelevant and we will (thanks to the true hackers out there) be able to do as we please no matter the hardware platform."

Couldn't agree more myself. Tony's point hits it right on that "....consumer pressure will ultimately force Microsoft to retreat on this one and for a very simple reason: Win8 just isn't (as far as I am able to ascertain from articles that analyse it) the game changer that Microsoft believes it to be." This would definitely put the pressure right back onto M$ where it belongs to *REALLY* listen to the needs of their customers instead of imposing their will unilaterally onto the same. This will continue to cause small businesses to better adapt to ever-changing technologies such as unlocking dvd disks and the hardware hacks for transcending M$ Secure Boot. And this is a matter of WHEN, not IF!!! Naturally, big businesses and government will eventually be YET AGAIN forced to play catch up here.

2c
caitlyn

Jun 08, 2012
4:44 PM EDT
Quoting:I think this will definitely put the pressure right back onto M$ where it belongs to *REALLY* listen to the needs of their customers instead of imposing their will unilaterally onto the same.
A leopard doesn't change it's spots. I think Microsoft will listen to consumers when many squadrons of pigs fly over the frozen-over h#ll. I just don't see it happening. Blackmail and brute force have been their modus operandi for way too long.
Fettoosh

Jun 08, 2012
5:22 PM EDT
Quoting:A leopard doesn't change it's spots. I think Microsoft will listen to consumers when many squadrons of pigs fly over the frozen-over h#ll.


Agreed, but do you think going along with MS is a better route to take in the long run? I don't think so. No at all.

The more one gives a monster monopoly, the hungrier it gets. Red Hat, and other Linux Distros for that matter, are never going to be safe from MS and no matter what they do. The only way to stop MS is to fight it, even if it is going to kill you, because the results are the same if one cooperates with it. But the chances are, one has a better chance of surviving by fighting back.

I don't thing people are condemning RH itself, on the contrary, they are condemning what it is trying to sell us. We already knowwhat MS is and capable of doing. There is a long history that can be forgotten.

So why is RH trying to throw itself in MS hands? Have it learned Novell's lesson?

May be they should have thought about it before hand and came up with a better solution.

If entities like govs. and large corporations want such security, there should be no problem to work things out by implementing UEFI on its own or with other in the community and without MS involvement. You just don't give MS the keys for anything. It most definitely with rob you.

Again, I don't think anyone here is bashing RH, they all know whose side it is on. It's just the approach they have chosen that is being condemned & bashed.

jdixon

Jun 08, 2012
10:38 PM EDT
> .but do you think going along with MS is a better route to take in the long run?

What makes you think this is Red Hat's long run solution? This is a bandaid. We know it. They know it.
gus3

Jun 08, 2012
10:58 PM EDT
An adhesive bandage[*], or a tourniquet[**]?

[*] Since "Band-Aid" is a registered trademark of Johnson & Johnson Consumer Companies, Inc.

[**] Applied to the neck, of course.
jdixon

Jun 08, 2012
11:05 PM EDT
> An adhesive bandage[*], or a tourniquet[**]?

That depends on the extent of the bleeding, gus3. And I'm not in a position to know how bad that is.

You'd think my 15 shares of RHAT would count for more, wouldn't you? I should be consulted on things like this. :)

> Since "Band-Aid" is a registered trademark of Johnson & Johnson Consumer Companies, Inc.

Yeah, That's why I used the common misspelling.
Fettoosh

Jun 08, 2012
11:09 PM EDT
Quoting:What makes you think this is Red Hat's long run solution?


May be it is not. But the way they were justifying & defending it sounded like they will go along if others find it to be reasonable to be used for all Distro, even Linux created by individuals.

And, like I said in a different thread, may be Red Hat is trying to smooth relations with MS to get on their Azure and avoid being isolated.

Ridcully

Jun 09, 2012
12:50 AM EDT
@Fettoosh, jdixon, gus3 and caitlyn......I will 'fess up straight away, I don't know the USA situation but over this last year, my perception would be that RedHat is just about **the** biggest Linux company in the USA with respect to sales of Linux packages and the service contracts that go with them. Additionally, I strongly suspect (and I'm open to correction here) that Linux forms the basis of a very, very large percentage of all business software installations in the USA - and that sector is where RedHat gets its income. Also, from what I see here, business would be very "disconcerted" if their Linux-Windows stacks suddenly ground to a halt.

Given those assumptions are correct, then Red Hat would definitely be concerned to make certain its software continues to run under all circumstances and since I don't think $99 for a key is going to hurt RedHat's dividend, I am not surprised really that they took this step to ensure their standing and good name in the business world was not injured. It might be jumping the gun a bit, but already their business customers KNOW that any future RedHat "combos" with Windows versions requiring UEFI will work smoothly, and that is what business wants: a reliable and certain future as regards budgetary planning. I could never believe that RedHat's action is a "wet fish in the face" for Linux; I think it is purely a business move to ensure RedHat's future viability, and in my opinion it does NOT in any way indicate that RedHat is cozying up to Microsoft even though RedHat is probably USA business' first choice when constructing a dual system stack with Linux.

As I indicated above, I think UEFI is eventually going to crash out together with Win8 ......so that all of this is likely to be a non-event in about 5 years - or until Microsoft thinks of another PR scheme which pretends that Windows is sooooooo secure. I don't particularly like what RedHat has done, but my hard pragmatic view would be that RedHat is doing the right thing by its stockholders, the company survival and most importantly, its customers.
gus3

Jun 09, 2012
7:18 AM EDT
@Ridcully, well-put and well-considered. I hope that is the way things will turn in the long run. I, OTOH, have nothing but pessimism when I see the name "Microsoft." Some may call me a "basher" for it but so far I have history on my side.

My vision of how UEFI will play out:

On Microsoft's side, it'll be the usual media blitz like we're already seeing, with Rob Enderle and his ilk writing their encomia about how finally we're getting the Microsoft world we've always needed and just didn't know it. Follow that with a few lawsuits here and there, maybe a Federal Trade Commission or EU investigation that won't go anywhere once Redmond figures out whose palm to cross with a coin (probably by donating a few thousand UEFI-based machines to schools... sound familiar?). Then when the next version launches ("Windows Ultra-Violate"), it'll run on both BIOS-based and UEFI-based hardware; people with the new, crippled systems will buy it, hoping it will fix what UEFI broke. And Microsoft laughs all the way to the bank.

On the FOSS side, entities with Red Hat's resources (Oracle, maybe Canonical, and maybe Mandriva, but not Debian, Slackware, OpenSUSE, or the BSD's) will enter negotiations with Microsoft to obtain keys allowing third-party OS installs. Their justification will be the inertia begun by Red Hat, and required by Microsoft for their entire business model at this point. Some may get keys, most will not. The effort to circumvent UEFI will be thwarted by DMCA threats. Someone will ride to the rescue, a la Jon Johansen, and the matter will become not worth fighting on the scale needed for Microsoft, but only after a lot of resources have been spent by both those complying and those fighting UEFI's "security."

But here's the most salient point of all: Projects which have no access to UEFI keys and code will be stuck developing for older hardware only. And, true to form, Microsoft still hinders the development of computer software as part of their unstated business model. Formerly, such hindrance was observable only in retrospect, and measurable only in speculation. This time, such hindrance will be observable and measurable in real-time.

I can allow myself the optimism that UEFI as a mechanism to block FOSS will be thwarted. But at this point, I think any such victory for FOSS will have some asking if the victory was Pyrrhic. And you will see that question asked right here on this site, in these threads.
Ridcully

Jun 09, 2012
7:48 AM EDT
@gus3....thankyou for your nice words. And may I say that I found your argument/hypothesis equally interesting and compelling. And that I suspect is the saddest part of the whole thing. Microsoft has never changed its shorts, as they say, and anything it does is designed to do two things: first, continue its monopoly; and second, destroy any serious competition. I think we can reasonably guess RedHat knows this only too well and will be looking to the experience of SUSE. The word "Microsoft" to me means nothing but greed, monopoly, destruction of business rivals, tainted ethics and lousy software - then throw in lack of security and stability, over complexity and always "apparent innovation for the sake of profit".

There is a light on the horizon however: Android, pads and smartphones. They represent a paradigm shift and so far Redmond has no answer - and I believe it is getting additionally desperate.

Even more sadly though, I think you are absolutely correct as to Microsoft's destructive influence in the computer programming area. In my down-under "backwater", I see only ripples of the enormous battle that is taking place, but enough filters through to get the general picture. Just as you indicate, I too believe that Windows is now one of the biggest hindrances to really great software development in the USA. It will probably still take some time, but the wheel will turn and I think that in 50 or so years, Microsoft will then be generally recognised for what it has now become: one of the most destructive influences on USA software innovation for the past two decades.
jdixon

Jun 09, 2012
8:48 AM EDT
> ...but my hard pragmatic view would be that RedHat is doing the right thing by its stockholders, the company survival and most importantly, its customers.

In the short term, yes. Tying your fortunes to a proven backstabbing liar isn't conducive to your long term health, however. So I certainly hope they're looking for more long term solutions.

I'm mostly buying older equipment at this point, so it doesn't really affect me immediately, and by the time it does a hack to bypass UEFI will almost certainly be available. But it's still frustrating to see hardware manufacturers lining up to act against their customer's best interests in this way.
Ridcully

Jun 09, 2012
9:02 AM EDT
You know what is one of THE most annoying things about LXer ? Just as all you blokes and ladies with really interesting responses or posts to put into the thread all turn up - I have to head off to bed or be a ruined heap in the morning. However, as regards your comment jdixon, I don't think it will be just hardware that is kept running. My bet is that not only will WinXP be kept going (even without Redmond support) but Win7 will also be kept going for as long as possible. I see UEFI as a complete annoyance and hindrance to Redmond's customers, not a help and while it might (repeat "might") plug one hole in the leaky security sieve that is a Windows OS, virus attacks on Windows will continue just as merrily as ever. Night all.
Fettoosh

Jun 09, 2012
9:30 AM EDT
@gus3 & @Ridcully,

You both described the issue so eloquently I can't add much more. The only thing I want to say is I am a little more optimistic than @gus3. The way I see it developing is RH will find a better way to implement UEFI without having to be dependent or reliant on MS. My concern is RH getting so isolated which eventually leads to its end as a FOSS company.

I personally consider Red Hat to be the most sincere commercial business that supports FOSS. But my gripe is about how they are handling the adoption of UEFI. And after seeing how MS is inviting/enticing other Linux Server distributors into their Azure and keeping RH out, I am concerned just like RH is is, especially the way the Ubuntu business weasel is behaving to compete against RH. He is following the same path as Novell and will end up facing the same fate. I have no doubt that, when he has the chance, he won't hesitate to sell his business just like he did with his previous company where he made all his money. In my opinion, it is better for RH to fight this isolation than cooperating with MS to end up having the same demise like Novell did.

The UEFI has to be implemented because it gives governments and businesses some sense of security. In my opinion, it really doesn't do much because, to my knowledge, it still doesn't handle application security within the OS. May be that will come later because it impacts users quite a lot and MS is trying to avoid it. Can you imagine how bad it would be to have keys for every application users use! it is impractical at this time but, to have full security, it has to be done eventually in the future. I believe, if RH can do that practically now and make it open, it would preempt UEFI because if an application can't run within the OS, it can't corrupt to hack the Boot Loader. Just dreaming.

In terms of IT in the US, I believe it is going to be dwindling down gradually to eventually become an import just like what happened with semiconductors and electronics manufacturing. It is sad and it is of our own doing.



gus3

Jun 09, 2012
7:35 PM EDT
Quoting:Can you imagine how bad it would be to have keys for every application users use!
They tried, with Windows Vista. And we all know how that turned out. It wasn't even "every application" but it still managed to make a right mess of things.

I just had a crazy thought: Could GRUB version N be made to work with UEFI? Then the boot sequence could go something like this:

UEFI => GRUB => any OS you want => Bob's your uncle!
BernardSwiss

Jun 09, 2012
8:23 PM EDT
Matthew Garrett described that option.

Quoting: http://mjg59.dreamwidth.org/12897.html

But ok, you're willing to do that and you obtain a signing key and you sign some malware. You'll infect some number of machines. But eventually you'll be noticed, and then Microsoft produce a key revocation blob and vendors push it out via their OS update mechanisms. If your malware was basically harmless then that's probably the end of it, but if you were using it as the basis for an attack on people's banking details then a lot of people are suddenly going to be very interested in the person who bought that key, and also your malware isn't going to be able to infect any more machines.


and more detail in this earlier post:

Quoting: http://mjg59.dreamwidth.org/12368.html

Secure boot is designed to protect against malware code running before the operating system. This isn't a hypothetical threat. Pre-boot malware exists in the wild, and some of it is nastier than you expect. So obviously bootloaders need to be signed, since otherwise you'd just replace the signed bootloader with an unsigned one that installed malware and booted your OS.

But what about the kernel? The kernel is just code. If I take a signed Linux bootloader and then use it to boot something that looks like an unsigned Linux kernel, I've instead potentially just booted a piece of malware. And if that malware can attack Windows then the signed Linux bootloader is no longer just a signed Linux bootloader, it's a signed Windows malware launcher and that's the kind of thing that results in that bootloader being added to the list of blacklisted binaries and suddenly your signed Linux bootloader isn't even a signed Linux bootloader. So kernels need to be signed.


He also offers a rational that it will be harder to get around Secure Boot than some other locking mechanisms.

Ridcully

Jun 09, 2012
8:24 PM EDT
@gus3.......Sounds like a plan to me. But in any event, I am absolutely certain UEFI will be rapidly hacked and a legal option (as well as numerous illegal ones) will be found to totally circumvent Microsoft's latest efforts to control the desktop/laptop area. Because ultimately, that's all it is, coupled with clever PR that says that at last, Windows with UEFI is secure, totally, absolutely, affirmatively, you have our word on it, and you always always believe our statements because they have all been true in the past !! Yeah..right. Amazing what the gullible will swallow isn't it ?
gus3

Jun 09, 2012
8:38 PM EDT
@BernardSwiss:

Something that doesn't work, that's one thing. I'll never be able to boot an x86 kernel on an ARM machine without some kind of emulator.

Something that does work, but then suddenly doesn't after an update, that's something quite different. How bad was the damage to Sony's reputation after they disabled OtherOS in the PS3?

Furthermore, designating the Linux kernel universally as "Windows-attacking malware" is just asking for trouble, especially on systems where Windows has been removed. That would be a new low for Microsoft (and that's saying something).
Ridcully

Jun 09, 2012
9:55 PM EDT
@BernardSwiss......your two quotes above make fascinating reading from both the software and ethical stances. It is beginning to make me wonder if this UEFI business may in fact backfire dreadfully on Microsoft. I think it is going to annoy business enormously and I don't care what Microsoft itself says, I personally believe that UEFI will be hacked and very quickly.

Gus3, your take above with respect to UEFI then becoming "Windows-attacking malware" is a logical extension of what Microsoft is doing. I hadn't thought of it in that way, but it's a pretty valid hypothesis. Again, I think consumers are the key. They had a mass revolt over both the Sony root kit and the disabling of the PS3..Perhaps it will be time for a quiet rebellion against Microsoft's attempts at control ? Apart from the usual rave reviews by dyed in the wool Microsoft supporters like Bott, I don't think UEFI is going to be welcomed with open arms once its ramifications are fully understood.
Fettoosh

Jun 09, 2012
10:12 PM EDT
Quoting:They tried, with Windows Vista. And we all know how that turned out.


I didn't know about that. What I vaguely remember is Vista users had to confirm many of the operation before they get executed. Is that what you referring to? If it is, then that is different than what I am thinking of.

My thought is to have a database that would contain all authorised/CAed application. Before the OS launches an application, it verifies that the application is authorised. If it is not, reject the request with a warning. It will slow launching application tiny bit but that would be the cost of security. On Debian, it should be easy to do since it already has the APT database. If the user installs the application, then there would be a way to easily add it in.

I run KDE 4 and if I create an application link on the desktop or in a folder view, the first time I launch that application using the link, it ask me to confirm. That is done only once and never asks again for that link.

I think something similar can be done for application security in Linux.

Quoting:UEFI => GRUB => any OS you want => Bob's your uncle!


That sounds good except it doesn't address Application Secure Launch within the OS.

Fettoosh

Jun 09, 2012
10:44 PM EDT
Quoting:I personally believe that UEFI will be hacked and very quickly.


@Ridcully,

Very good point and what is worse is, hackers don't need to do any hacking to render a system with UEFI totally useless. All they need is to corrupt the list of keys and you have a system that no longer can boot.

UEFI does NOT protect against virus or Trojan horses, and we all know how secure is Windows. So corrupting the list of keys is a real possible and not impossible.

gus3

Jun 09, 2012
11:02 PM EDT
@Fettoosh, I don't think UEFI is concerned with securing applications. That's the job of the kernel.

I just took a quick read over Wikipedia, and guess what I found: Running a 32-bit OS on a 64-bit CPU is not supported by UEFI.

I think it's time for a new acronym: Universal Engineering Failure Initiative. Really, how many kinds of fail can one project incorporate?
Fettoosh

Jun 09, 2012
11:46 PM EDT
Quoting:Running a 32-bit OS on a 64-bit CPU is not supported by UEFI.


That enforces @Ridcully's point "I don't think UEFI is going to be welcomed with open arms once its ramifications are fully understood".

who knows what else is there still to be discovered?

Fettoosh

Jun 10, 2012
12:12 AM EDT
Quoting:I don't think UEFI is concerned with securing applications. That's the job of the kernel.


True, but the kernel will execute any code flagged as executable and requested by a user with root privileges. So, if the user is duped into running a virus unknowingly, the kernel can't protect the system.

What I am suggesting is to make a list for the kernel to only execute code that is authorized in a database. I am not saying Linux needs it as much as Windows, but it is some thing that could convince the uninformed and counter the perception about UEFI being so magical and important.

The sense of security created by UEFI is bogus since it doesn't have or protect against Malware within the OS.



Ridcully

Jun 10, 2012
3:31 AM EDT
@Fettoosh....
Quoting:The sense of security created by UEFI is bogus since it doesn't have or protect against Malware within the OS.


I couldn't have put it better. I look on Windows (any version) as similar to a sieve - the kitchen device with a thousand tiny holes used for straining liquids. All UEFI does is **try** to plug one hole, and I don't think it will last more than a few months before the virus writers are all over it........But that still leaves the rest and they are just as vulnerable as ever to all the various Win viruses and trojans that infest the internet. Win users can have UEFI, but it will not stop the need to have antiviral software. UEFI is a horrible PR exercise designed to make a defective package look good.

Microsoft will never do it of course, but I think that there are only two options for Microsoft if it wants to produce software that has a reasonable security level.

1. Rewrite the entire code base of Windows while applying the Unix standards of security; or

2. Pick up a Linux distribution and modify it to give "Winlux".

For the first, too expensive and Redmond would have to eat crow; and there is the enormous problem of getting Windows software running on the new OS and making it available to previous consumers. In this sense, Microsoft has given itself enormous "lock-in".

For the second, an enormous "eat crow".......which would fly in the face of everything Redmond has produced.

Neither option is really palatable, so I think Redmond will continue to market its defective software and rely on its PR machine to sell something that, if it was a normal consumer item, would have been drummed out of the market a decade ago.
Fettoosh

Jun 10, 2012
9:41 AM EDT
@Ridcully,

Actually Red Hat should have spent their effort to fight MS Implementation of UEFI instead by exposing the shortcomings and weaknesses you are citing.

But if fairness, we don't know why they decided to go along. It could to avoid isolation after realizing that Ubuntu is taking advantage of MS invitation to join in on Azure, or realized it is not worth starting a battle against MS, which could be more damaging to RH.

May be we are being too harsh on Ref Hat and we should be directing our bashing more towards Ubuntu. But then again, I personally never considered Canonical/Ubuntu to be a sincere member of the community and its objectives were always to establish its business by taking advantage of what FOSS offers.



jdixon

Jun 10, 2012
10:21 AM EDT
> Rewrite the entire code base of Windows while applying the Unix standards of security; or

They claim to have a done a full security code audit on the code back in the XP days. Then some months later they found a security hole that went all the way back to Windows 3.11.

From memory, which is somewhat faulty anymore, they've claimed to have done a complete rewrite with security in mind at least 3 times now. The only time they came close was with Vista. How did that work out?
tuxchick

Jun 10, 2012
1:19 PM EDT
In the the Linux world "complete rewrite" means throwing away old code and starting over. In Windowsland it means piling new code on top of the old code. 15+ GB of mystery lard that delivers 500MB of functionality is not a rewrite, but a fertile compost pile of malware cultivation.
gus3

Jun 10, 2012
4:25 PM EDT
Quoting:In the the Linux world "complete rewrite" means throwing away old code and starting over. In Windowsland it means piling new code on top of the old code.
Given what has happened with "complete rewrites" in KDE and GNOME recently, I'm not sure I'd consider that a bragging point.
BernardSwiss

Jun 10, 2012
5:47 PM EDT
I'm still not entirely sure I understand this: I have two questions.

As I understand it:

0) If this Secure Boot stuff is too much trouble, one can (on traditional x86-based PCs) turn off "Secure Boot" mode.

1) the UEFI motherboard, in Secure Boot mode, verifies the boot-loader against a (the?) key in the firmware -- if the boot-loader doesn't pass, Game Over

2) the signed, verified boot-loader verifies the kernel -- if the kernel doesn't pass, Game Over

3) the kernel verifies drivers, modules, etc, are signed with a valid (ie. recognized) key -- if these don't pass, Game Over.

SO: Fedora is breaking (2) down into a two step process. The boot loader is divided into a MS-key signed "shim" that hands off to a Fedora-signed "full" GRUB boot-loader. This full boot-loader will recognize any keys you manage to load into the firmware (free, if the motherboard allows you to manage UEFI Secure Boot keys), or a shim you've compiled (with Fedora supplied tools) and signed yourself (if you've paid $99 for access to the MX/Verizon signing service -- you're basically jumping through the exact same hoops that Fedora does, to make their kernel "MS Boot"-compatible).

FINAL RESULT: "Bad Guys" can't install roots kits that alter or swap out the trusted kernel and/or the trusted boot-loader -- more precisely, they can, but they won't boot.

- - - - + - - - - + - - - - + - - - - -

Question #1: If I understand this correctly, the entire "Secure Boot" concept is utterly dependent on the UEFI/BIOS being inaccessible from the OS -- (I have re-flashed a BIOS, and I recall it was a "special" process that ran off a specially created floppy). Why is the inaccessible? Is this intrinsic to the hardware design? is it actually realistic to depend on this?

Question #2: How difficult will it be to create FOSS tools for accessing and modifying UEFI firmware and keys? (is there some reason to believe these will be immutably burned-in (as I assume TiVo does it, and ARM Win8 will do it) or would this be so stupid that not even OEMs will do it that way).?

Ridcully

Jun 10, 2012
8:44 PM EDT
@BernardSwiss......I read your notes above and decided to see if I could get any further, and went straight to the "horses mouth":

http://www.uefi.org/about/

What interested me most was the second last Q/A paragraph which I duplicate below:

Q: Does UEFI increase security risks from viruses and the like? A: Any firmware implementation has to take care to address security. UEFI does not change that for better or worse.

So......what on earth are we playing at here. Microsoft is telling us that UEFI will dramatically improve security, but in fact, the UEFI specs appear to be neutral with respect to security. If I read things correctly, it is not UEFI as such but the Microsoft firmware version that is the problem ?? I'd like some comments on this one as it's getting a bit too deep for me.....software engineer I am not !!!!!!!
tuxchick

Jun 10, 2012
9:20 PM EDT
Anything that gets in the way of user control is going to be a fiasco, and it won't improve winderz security one bit.
jdixon

Jun 10, 2012
9:27 PM EDT
> I'd like some comments on this one as it's getting a bit too deep for me.....software engineer I am not !

OK. I haven't read the spec, and this is purely my understand from reading what others have written, but others will undoubtedly correct me if I'm wrong.

UEFI allows for a secure boot option. This may be turned on or off by default, at the manufacturers discretion.

If the secure boot option is enabled, the boot loader and kernel (including the modules loaded at boot time) must be signed with a key which matches the key stored in firmware. At the manufacturer's option, this key may be preloaded or supplied by the user.

The concern is that manufacturers will choose to enable secure boot and force you to use the preloaded key (which will be for Windows, of course) with no other option. That is, they will not allow you to either disable secure boot or supply your own key.

If they allow you to turn of the secure boot option, then all is well for the average user, as any distro can be installed and work. If they allow you to provide your own key, then the dsitro can provide a key at install time and walk you through installing it. If they do neither, and the distro doesn't pay for Microsoft's key, you can't boot your installation.

And no, it doesn't protect against viruses much at all. It does protect (in theory) against rootkits, but that's a fairly small subset of viruses (though a bothersome one, I've had to remove a number of TDSS infections and other variants over the past 18 months). As someone else has pointed out, and my understanding here is really shaky, it's theoretically possible for a virus to infect the hypervisor on the machine, and in that case all bets are off, as even the UEFi check can be spoofed.

Does that answer your questions?
BernardSwiss

Jun 10, 2012
9:45 PM EDT
I'd like to add that even if the OEM "lets you" disable Secure Boot, this will be a hassle for dual-booters, because they will either have to fiddle the UEFI/BIOS settings between boots, or leave their Windows 8 installation without a subset of the security it badly needs.

(And I wouldn't be surprised if Win 8 has more than its usual share of security issues, simply because of the awkward cobbling together of the new Metro environment with the legacy one.)
gus3

Jun 10, 2012
9:48 PM EDT
@Ridcully, thanks for finding that tidbit. It's interesting, and I think very telling, that the question asks about increasing the risk of viruses, when UEFI is being touted by Microsoft et al. as being a tool to decrease said risk. As in, "UEFI means you can trust that Windows is secure." It's a real mental leap, but one that the PR flacks hope the unwashed masses will make.
BernardSwiss

Jun 10, 2012
9:51 PM EDT
Oh, and the problem is not UEFI itself, but deficient, incomplete OEM implementations designed to do no more than absolutely required to boot Windows 8 and satisfy Microsoft's specifications to qualify for Microsoft's certified logo program.

(and considering Microsoft's history, there are grounds to doubt this problem is an "unforeseen consequence" or free of covert encouragement)
Fettoosh

Jun 10, 2012
9:59 PM EDT
Quoting:(is there some reason to believe these will be immutably burned-in (as I assume TiVo does it, and ARM Win8 will do it) or would this be so stupid that not even OEMs will do it that way).?


Quoting:If I read things correctly, it is not UEFI as such but the Microsoft firmware version that is the problem


That is it, these two statements should clarify everything.

UEFI doesn't enhance system security and the only think it does is implement a scheme very similar to Tivo's. It is nothing but Tivoization controlled by MS & company.

The board of directors are all commercial companies and there is no representative of FOSS like there is one for MS & Apple. That speaks volume.

In the members list, Canonical is a contributor & Red Hat just have a "Center of Information Architecture Research"

The UEFi is nothing but a scheme, a ploy to contain and control FOSS.

I am just waiting to hear what RMS is going to say about this whole shenanigan.



Ridcully

Jun 10, 2012
10:55 PM EDT
@Everybody who contributed after my last posting above. Many thanks all round. It's pretty much crystallised my concepts. They weren't pleasant to begin with, but having got all the above under my belt, I have the following concepts:

1. UEFI of itself is neutral with respect to virus protection, so the guff pumped out by Redmond and others is simply mischief making in order to fool the consumers. It is possible that the certification process might block root kits at first.....I give it 30 days.

2. The problem is the Firmware also included at the behest of Microsoft, and that is designed to limit the use of any computer (that has this Microsoft tampered UEFI) to being a Windows locked machine.......UNLESS........

3. UNLESS, the OEM's provide a mechanism to turn the Microsoft firmware off.

4. I now consider the Microsoft version of UEFI a very deliberate attempt to smash FOSS once and for all or if not, then to control it to Microsoft's satisfaction.

At the moment, the best simple hope on the horizon is consumer resistance and I think it will come from the business community. However, when you look at the above facts, I begin to wonder if there might just be a monopoly matter in the legal circles, because item 2 above spells out the Redmond intentions (as I see them) very clearly. Unless this corruption of UEFI by Microsoft is stopped, or the switch is included, then all computers apart from the Apple brand, might just as well be shipped as Microsoft branded devices.....unless a way is provided to reflash the bios chip and I am not sure we know about that as yet.
BernardSwiss

Jun 10, 2012
11:22 PM EDT
The way Microsoft has set it up, they can deny all responsibility, as in theory the decision of precisely how to implement Secure Boot is entirely up to each individual OEM.
gus3

Jun 10, 2012
11:40 PM EDT
...with "assistance" from Microsoft, of course.
Ridcully

Jun 11, 2012
3:07 AM EDT
Here is Linus Torvalds' take on UEFI:

http://www.zdnet.com/blog/open-source/linus-torvalds-on-wind...

Ultimately, it looks like he agrees with my concept that hacking of the certified UEFI is going to occur and very quickly. So, pointless ?
gus3

Jun 11, 2012
7:35 AM EDT
Just, not too quickly. We don't want to give them a chance to fix what we've broken. ;-)
flufferbeer

Jun 11, 2012
8:09 PM EDT
@Ridcully,

I'm greatly with tuxchick and Fettoosh on this one too. While UEFI hacking will occur quickly enough, there IS a good point to mention this fact. As much short-sighted sense as RedHat and now Canonical had in making the dirty deal with Macro$uck$, they can absolutely EXPECT to suffer some sort of negative consequences in the long-run. I just don't think these CURRENTLY large players shoulda rushed into this as quickly as they did. Both these large players DID drink the pleasnt-tasting poison from the evermore desperate M$.

Of course you logically disagree with this as well as well as with some of Fettoosh's major points above. So be it....

2c
Ridcully

Jun 11, 2012
8:29 PM EDT
@flufferbeer. Actually, I do NOT disagree with you or Fettoosh or tuxchick. I refer you to a post I made up at the top of this thread where I said this:

Quoting:I don't particularly like what RedHat has done, but my hard pragmatic view would be that RedHat is doing the right thing by its stockholders, the company survival and most importantly, its customers.


If you follow my series of posts down, you will see that Fettoosh has actually used some of my posts to give what he says is an ideal summary of the situation. I can see exactly why RedHat has moved, and I explained why in one of my posts, but personally, I don't like it much at all. I thought I had made that pretty clear from the start.
flufferbeer

Jun 11, 2012
9:05 PM EDT
@ridcully,

You wrote: "Ultimately, it looks like he agrees with my concept that hacking of the certified UEFI is going to occur and very quickly. So, pointless ?"

I thought I had just made it clear that the quick-enough but inevitable hacking of UEFI ISN'T pointless and IS well-worth emphasizing. THIS is what you seemed to disagree with in your question rather than liking or not liking Red Hat & Canonical's logical need to drink the M$ Kool-Aid. At least that's my own perception of this. Capiche?

-fb

Ridcully

Jun 11, 2012
11:14 PM EDT
@flufferbeer.........aaaah.....Now I see what you are understanding by what I wrote - it's again a classic of what one person writes in a particular way when not taking meticulous care, another interprets quite differently. Again, if you look up the lists of postings I have made on this thread, you'll find one which compares UEFI to the stupid merry-go-round situation in which as soon as the media moguls put a new lock onto the dvds, the various unlock people break the lock and it is all back to normal illegal copying. What I meant to imply was that this whole implementation of UEFI as a security measure (which is how it is being marketed by Microsoft) is pointless as it is going to be hacked almost immediately. That's all. I didn't really write it well.......I should have said: So implementation of UEFI is pointless !........without a question mark; at the time I was feeling cynical.

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!