No Windows 8 Plot To Lock Out Linux

First time accepted submitter Bucky24 writes "ZDNet's Ed Bott decided to contact major PC makers to find out the truth about Windows 8 SecureBoot. The responses are encouraging for those of us who run third party operating systems. Dell plans to have a BIOS switch to allow SecureBoot to be disabled, and HP assures us that they will allow consumers to make their own choice as to what operating system to run, though they have not given details as to how."

Comments

Ed Bott

[bmo]

Ed Bott is nothing more than a Microsoft mouthpiece. Not going to RTFA and almost didn't RTFS because of his name. His hobbies are trolling and shilling for Microsoft.

The only difference between him and Robert Enderle is that Robert is a more honest whore.

--
BMO

Re:Ed Bott

[izomiac]

I read the article and regret it. The author called Dell and HP "spokespersons" and asked about their company's plans. One non-decision-making employee says Dell is currently planning to provide an option, and a similar HP employee has no idea what SecureBoot is, but can confirm that HP is not participating in a conspiracy (the stated question apparently).

So, after two phone calls and an e-mail, the author's fact-checking work is done, so the article moves on to mocking selected quotes by open source advocates. I'll try to remember Ed Bott's name, as he obviously has such high journalistic standards.

Re:Ed Bott

[sortius_nod]

anything on ZDNet is going to be a Microsoft shill piece.

Re:Ed Bott

[Zancarius]

Okay, I'll bite. Let's take this article as a fine example of his work:

Allow me to illustrate by turning the argument around in an equally cynical way, with an equally inflammatory rhetorical flourish:

People who make their living in the Linux ecosystem are demanding that Microsoft disable a key security feature planned for Windows 8 so that malware authors can continue to infect those PCs and drive their owners to alternate operating systems.

Oh, wait. Now that I think about it, thatâ(TM)s actually pretty close to the truth.

Bott takes a provocative approach by claiming to "turn the argument around" using "equally inflammatory rhetorical flourish"--then implicitly claims it's "close to the truth." In other words, he's essentially linking malware authors with people who are attempting to drive users toward alternative OSes like Linux. Is it a joke? Maybe, but his last statement leaves one wondering if he really does believe it.

He claims that UEFI will magically prevent rootkits from working simply because the BIOS will then be able to detect mangled files. I'm not sure Bott fully understands the purpose of a rootkit, but if one were well designed, UEFI will achieve nothing toward this goal. Indeed, unless UEFI contained signatures for all Windows system files, I'm quite certain that it would be fairly easy for an interested party to circumvent. After all, the objective of a rootkit is to hide the rootkit from examination, and running one under UEFI would simply require hooking into the OS at points that the UEFI does not check. But no, Bott seems to espouse this technology as magical!

Let's not stop there.

In this article, Bott's original post immediately presumes that the reports of MSE incorrectly flagging Chrome as malware were the fault of the users downloading compromised versions or installing on a compromised Windows install. It seems that it never occurred to him that it could have been a false positive in MSE until after it was confirmed with MS.

Now, before you tell me that I'm nitpicking, consider this: False positives are not at all unheard of with antivirus software. Avira, Avast, AVG, et al, have been known to flag valid, clean software as potentially dangerous, and most sensible people installing something from a known-good source that claims the source file is not compromised will immediately assume it's a false positive and submit it to the AV company. While Bott did the correct thing in submitting it, he dismissed it as the fault of users simply because he couldn't recreate the problem. Ah yes, not a chance that MS could do anything wrong...

Oh, and then there's this wonderful masterpiece in which Bott proudly declares Microsoft's victory. While this may be true--Linux on the desktop is unlikely to become a reality--you have to dig a bit to find that he concedes, quote, "On the server side, of course, Microsoft continues to acknowledge that Unix and Linux are strong competitors." You can tell he was salivating over the prospect, though, never mind that Android is, essentially, Linux under the hood.

And what about his article The Hidden Costs of Running Windows on a Mac? Not only does he go out of his way to point out that you have to buy licenses (hint to you, Mr Bott: you're still buying OEM Windows licenses when you buy a Dell), but he points out possible performance issues and the likes. Honestly, I think this is a true shill piece; if someone has decided that they want to run Windows on their

Re:Ed Bott

[bmo]

For many years, Ed was on the side of SCO. His typical characterizing the FOSS crowd as dirty unkempt, unwashed hippies over the same years, and his continual use of the word "freetard" was, and is, reprehensible. And yes, there is a lot of it, which is why I don't want to go diving in the filth.

Not reasonable in the least.

If you read the post I put up here that had the quote from Florian, Florian lists almost all the "paided" shills for Microsoft and calls them "smart" thus aligning himself against FOSS and with Microsoft. Ed Bott is one of them. He left out Paul Murphy, AKA Rudy de Haas.

And that's not ad-hominem.

There is a lot of animosity from people like me that people like them earned.

--
BMO

Re:Ed Bott

[benjymouse]

He claims that UEFI will magically prevent rootkits from working simply because the BIOS will then be able to detect mangled files. I'm not sure Bott fully understands the purpose of a rootkit, but if one were well designed, UEFI will achieve nothing toward this goal. Indeed, unless UEFI contained signatures for all Windows system files, I'm quite certain that it would be fairly easy for an interested party to circumvent.

Ed Bott is right and you are wrong. You believe "signatures" is hashes (because there is no code signing in Linux?). They are not hashes, code/file signing is based on asymmetric keys for integrity protection and is pretty solid (unless you let Debian developers modify the code for key generation). The UEFI firmware will have a table with approved public keys. Any bootloader and its data will have to be signed with one of the corresponding private keys if secure boot is switched on. The bootload'er vendor can update and distribute a new version as long as he signs the bootload'er. If it works anything like Windows kernel signing (but remember this is a industry UEFI standard not exclusively available to Windows) the signature will protect executable as well as config data etc.

After all, the objective of a rootkit is to hide the rootkit from examination, and running one under UEFI would simply require hooking into the OS at points that the UEFI does not check.

Wrong again. The UEFI secure boot is the last missing link in the secure Windows boot chain. Each step will validate the next one before relinquishing control to it (letting it execute): 1) The UEFI firmware validates the signature of the bootload'er. If the bootload'er has been tampered with UEFI will *not* execute the bootload'er 2) Bootload'er runs, loads OS boot definitions, checks (through signatures again) that they have not been tampered with. If the chosen OS is set to secure boot, the bootload'er checks the OS integrity (through signatures again) before launching the OS. 3) The OS gains control and before loading kernel executables and kernel mode drivers, it checks that they come from signed cabinet files. If they don't the kernel will refuse to load them.

Microsoft did not require that system vendors and motherboard vendors makes it impossible to switch off. Microsoft does not require that their public key is the only one in the system. In order to get the "Designed for Windows 8" sticker they *do* need to 1) enable secure boot by default, 2) pre-register Microsofts public secure boot key, 3) Not provide a programmable interface for switching secure boot on/off and not provide a programmable interface for changing the registered secure boot keys.

There is some FUD speculation about a conspiracy that Microsoft will secretly require the vendors to *enfore* secure boot with Microsofts key exclusively. That would prevent other bootload'ers from loading. This is despite the fact that Microsoft has publicly said that they prefer that vendors do not do this but that they cannot mandate this, as it is ultimately the vendors choice, not Microsofts. In fact, it would hurt Microsoft as it would exclude the enterprise and corporate sector from downgrading to non-secure boot aware OSes like Windows 7, Server 2008/R2 etc.

This issue had the wrong address from the start, and that is what Ed Bott is ranting about. This is about HW vendors, not Microsoft.

Windows 8 will not require secure boot, but will support it. Windows 8 will boot on any machine, secure boot or not. The issue is whether hardware/system vendors will provide the on/off switch *or* allow the key table to be updated by the user. So far not a single hardware vendor has said they will disable the on/off switch, if you disregard the very suspicious claim by Red Hat employees that they "know" one vendor who has "privately and anonymously" declared that they will disallow Linux. Several vendors (Dell, AMI) is now on record for saying that they will allow secure boot to be switched off while others has declared their intention to do so.

Re:Ed Bott

[makomk]

Microsoft created the tools that generated the broken BIOS code in the first place, and they designed them in such a way that they always generated broken, non-standards-compliant code - in fact there are reasons to believe this may have been deliberate.

Re:I doubt that Microsoft would try this

[Lando]

I may be way off base here, but though Microsoft was declared to be an illegal monopoly, wasn't their punishment settlement basically an agreement that gave them more control and profit than they had before? I'd have to go back and read through the documentation. That being the case, wouldn't it be in Microsoft's best interest to get in trouble again. Either way, it would be 10+ years before the case went to trial and by that time it would be the defacto standard .