Microsoft Windows 8 will fully embrace a computer security architecture that has been a very long time in the making: the Unified Extensible Firmware Interface (UEFI), created in the 1990s by Intel, and developed later by a consortium that also includes AMD and embedded processor developer ARM. Essentially, UEFI performs the functions that ordinary BIOS used to perform (getting the components of your computer up to speed), but rather than following a set agenda, UEFI works like more of an operating system in itself, making sure your Windows (or Linux, or whatever other) OS is accessible, intact and legitimate before booting it. As with most security changes, though, there are side effects - particularly when working with some dual- and multi-boot Windows 8 machines.
Microsoft has made several demonstrations of UEFI support since announcing Windows 8 last September. The most convincing demonstration involves a thumb drive. Many computers, especially in the office, are geared to look for the presence of operating systems on thumb drives before hard drives, especially for purposes of recovery. Malicious users can plug thumb drive-based OSes directly into victims' systems, and perhaps gain access to the entire office network. But that's only if the computer's BIOS clears the thumb drive's operating system. With UEFI installed on the motherboard, it won't.
Many newer PCs already have UEFI in their firmware, and there's a good chance you're using it now. But with Windows 8, you would begin using it for what it was built for in the first place: restricting the loading of OSes to those that can prove themselves legitimate and untampered with. Once you install Windows 8 (as our tests with the Windows 8 Consumer Preview confirm), the OS-clearing capability of UEFI kicks in. With some firmware, you can turn off this option. Yet with quite a few systems, once this feature has kicked in, OSes that can't sign themselves are locked out.
One example, ironically, is a copy of Windows XP that was installed on a hard drive attached to a non-UEFI system. With UEFI fully engaged, you cannot boot to that XP-based drive in a multiboot system. The photo above shows a UEFI screen (not Windows 8, but system firmware) from an Intel Core i5-based 3.3 GHz PC I built. Note the UEFI banner attached to the drive where I've installed Windows 8 Consumer Preview. On this particular PC, I cannot (successfully) disengage secure boot. So I cannot boot my Windows XP disk - a fact which gives me only minor trouble with respect to testing software.
What the Lockdown Means
Trusted computing is what the entire commercial computing industry wants... the keyword here being "commercial." Not all computing is accomplished by commercial entities; and many would argue that some of the most important advances in computing in the last 10 years have come from developers who shunned commercial interests. At any rate, there is a considerable plurality of free software and hardware developers (free as in "free"), many of whom are in the Linux community, all of whom are legitimate artisans. They build computers and systems because they can, and because it's fun.
Because their community is not centered around vendors or commercial interests, there is no nucleus of authority responsible for what they build. This is how the community wants it. But it becomes a problem when the hardware platforms they rely upon adopt a protocol that equates legitimacy with commercial responsibility. Put simply, if you're not a vendor, there's no way you can "sign" your operating system for UEFI. And that may mean you can't set up a dual-boot system that includes both Windows 8 and a free Linux distribution.
By "free Linux," I'm referring to any noncommercial distribution, and Red Hat and Canonical have warned their distros (Fedora and Ubuntu, respectively) may be among them (Intel disagrees with respect to Fedora). This is not exactly the swap-meet crowd we're talking about, but a sizable bunch of legitimate PC users.
In this 10-part series, 26-year veteran Windows tester Scott Fulton walks us through the best features, faculties and functions of Windows 8.No. 10 : Refresh and Reset
No. 9: File History
No. 8: Storage Spaces
No. 7: Client-side Hyper-V
As Red Hat mobile Linux developer Matthew Garrett first explained last September, "There is no centralised signing authority for these UEFI keys. If a vendor key is installed on a machine, the only way to get code signed with that key is to get the vendor to perform the signing. A machine may have several keys installed, but if you are unable to get any of them to sign your binary then it won't be installable."
Over the years, companies such as Microsoft and Intel have maintained that enthusiasts are free to build their systems using platforms that are not UEFI-enabled, and to install free Linux on them. This is becoming harder and harder, as the motherboard industry (Asus, MSI and Gigabyte, among others) has already embraced UEFI firmware. Almost by definition, a motherboard without UEFI is a cheap motherboard. Enthusiasts may like "free," but they abhor cheap.
More than once, Microsoft has reminded me of the relatively small size of the enthusiast community. But despite their numbers, they are an extraordinarily influential group. Commercial vendors that disrespect them are committing a blunder akin to a politician uttering a racial slur in front of a fellow with a cell phone camera.
Trust, UEFI and How We Got Here
At some point, Microsoft - now one of the co-architects of UEFI - had to take the plunge and support what's essentially its own work. The reason why concerns one of the most dreaded threats that every installed copy of Windows still faces.
In fact, for any computing device - be it a PC, a smartphone or a garage-door locking system - a malicious program could overwrite the contents of its operating system kernel, substituting what's come to be known as a rootkit. In this scenario, when you reboot your device, it isn't exactly what you think it is anymore. Just how easy it is to accomplish this was demonstrated at the RSA security conference a few months ago, by a team led by McAfee's former CTO.
When security problems are caused by software claiming to be something it's not, the solutions usually involve authentication - the implementation of some type of trust system. (Just the word "trust" sends up red flags among veteran IT workers.) In any chain of trust in a computer network, there must be some unimpeachable root that is capable of vouching for the authenticity of everything else. Operating systems are typically vulnerable, and thus serve as poor roots of trust. Engineers prefer the root to be inside the computer hardware, at a more tamper-proof level. Installing trust in any deep level has rarely been without controversy, mainly on the part of users who have learned from experience that, given the choice, both hardware and software vendors tend to trust themselves above a competitor.
The concept of building a root of trust in the BIOS traces back to 1998, with Intel's Extensible Firmware Interface created for its Itanium processor-based servers. The idea there was to build a more programmable shell that could effectively manage the system's transition between powering on and readying the main bus and peripherals, to launching the OS. When regulatory agencies' scrutiny of Intel began to intensify, Intel turned over EFI to an industry consortium including AMD Microsoft, and embedded processor maker ARM.
From the very beginning, the UEFI group had stated its intention to load operating systems other than Windows. And the first successful field implementation of secure booting with UEFI in consumer-grade equipment was in the first Intel-based Macs. UEFI is already a reality in PCs sold today, and especially in motherboards sold to enthusiasts and system builders (like me). So the issue isn't that Windows 7 doesn't already "support UEFI," or that UEFI by definition locks out Linux. The tools for Linux makers to adopt UEFI protocols are available openly today. So it's wrong to say UEFI is technically incompatible with Linux. Instead, there's a kind of "social gap" that the commercial vendors are not willing to help fill.
The Decision
The real question, of course, is does the UEFI flexibility tradeoff affect you? Specifically, does the disablement of your ability to have a dual- or multi-boot system that includes Windows 8 and one or more operating systems that do not support UEFI, impact your ability to work or use your computer the way you want?
- If you are a part-time Linux user and part-time Windows 7 user, the answer may be "yes." You may not want to upgrade to Windows 8 until you know for certain you can dual- or multi-boot to your preferred flavor of Linux as well as Windows 8.
- If you use Linux occasionally, perhaps for testing, then you might consider running Linux from a virtual machine instead of creating a dual-boot system. If you're testing Linux hardware reliability, though, a virtual implementation probably isn't a good solution for you. If you're just interested in the software or in the development tools available with Linux that have no counterpart in Windows yet, you may be perfectly comfortable running Linux from Oracle VirtualBox in Windows 8.
- If you use Windows XP, and you want to upgrade to a modern PC but keep your XP-based hard drive, the UEFI lockdown could affect your ability to work with XP. You'll be better off keeping your XP drive where it is, and running it from there.
For everyone else, though, UEFI brings an enormous benefit: the confidence that a rootkit will not be able to substantively change the kernel of the operating system, with the aim of enabling malicious software. In my opinion, for most users, the benefits far outweigh the tradeoffs.
Of course, I said that about UAC in Vista too, and I found my point of view caricatured in a legendary Apple ad campaign.
0 komentar:
Posting Komentar