On Fri, Sep 23, 2011 at 09:03:28AM -0700, Daniel Pittman wrote:
so the "solution" is to prevent installation of competing operating systems that don't have the security flaws that allow malware to compromise the kernel? or the BIOS.
Not really, no, given that nothing requires that as written. It *might* be a side-effect, or might not, depending on what the vendors implementing this do.
yeah, well, just because the Thought Police have a habit of locking people's heads in rat cages doesn't mean Winston Smith has anything to worry about when they want him to come in for a little chat. it would be wrong to attempt to predict future behaviour from past behaviour. there are two factors that strongly indicate that it will turn out to be as bad (or mostly as bad) as that: 1. the generic malice of corporations towards consumers and governments towards citizens. 2. laziness. it's easier to implement only the parts of the UEFI design that allow restriction by the computer manufacturers (and specific third parties such as Microsoft), without bothering to implement the parts that allow the purchaser to control the equipment they bought and own. both malice AND incompetence. both are pretty powerful inertial forces to overcome.
Also, unrealistic claims (like, oh, that Linux is immune to kernel level compromise, or that it prevents firmware updates) are not super convincing.
Our one item deep pool of evidence suggests that Linux is not *yet* subject to this attack, but as the saying goes, the attack never gets *worse*...
i never said that linux was immune. I said that it doesn't have the security flaws that allow such compromises. what we do have is over 20 years of history indicating that linux is quite safe and, more importantly, that linux devs (and free software devs in general) take security issues seriously. and that when a specific type of flaw is discovered that developers pro-actively look for instances where such exploitable code patterns exist and clean them up. and teach each other "don't do that". i.e. a practice and a culture that is highly resistant to malware. by way of contrast, we have about 10 or perhaps 15 years of history (counting from Win2K, or perhaps NT, the ancestors of current versions of Windows) of continuous and repeated security flaws, and a glaringly obvious indiference to security as anything but an afterthought - it's certainly less important to MS than "backwards compatibility". plus another 15 or 20 years of the same for Microsoft's prior products - MS-DOS, Win3.x, Win95, and Win98.
(IIRC, it was award that you could flash the bios of first; LinuxBIOS certainly have the tools.)
wonderful. makes perfect sense.
It is one possible outcome, but I don't think it is entirely likely. More probable, I think, is that many vendors will allow Linux in some way, while the "hardware bundle" system where you get, for example, a desktop with Windows "small business edition" for free will end up mostly locked down.
I suspect that (some/many/most) motherboards purchased separately will probably be fine. As will white-box clone systems as they're built from such off-the-shelf parts. it's brand name systems, made by Dell, HP, Lenovo, and others - and sold through (in .au) Harvey Norman, Myers, and other large department stores that will be Windows-only. amongst many other problems, this will make it impossible to suggest to friends, family, or the public in general that regardless of what OS they use for their day-to-day computer usage, it would be much safer for them to boot to a Linux USB stick or CD ROM to do their internet banking and similar security-sensitive tasks.
Will it be overall worse for Linux? Maybe, but I doubt it will be substantially worse than the current driver problems are. Having a second problem like that sucks,
not having a specific driver for a specific product is very different from not being able to install or run linux at all.
but it is hardly the breathless end-of-the-world you are suggesting.
sorry, you must be confusing me with someone else. craig -- craig sanders <cas@taz.net.au> BOFH excuse #363: Out of cards on drive D: