Slashdot Mirror
Intel To Release Next-Gen BIOS Code Under CPL
An anonymous reader writes "Intel said today that it plans to release the 'Foundation code' of its next-generation firmware technology -- a successor to the PC BIOS -- under the Common Public License (CPL), an open source license, later this year. More than 20 years old, the BIOS (Basic Input-Output System) is the oldest software technology in PC platforms. Intel says its firmware Foundation code, a result of a project codenamed Tiano, 'provides that the successor to the BIOS will be based on up-to-date software technology.' The Foundation code is designed to be extended with new features and services, such as improved platform manageability, serviceability, and administrative interfaces which are too complex to implement in the old BIOS environment, according to Intel."
Sorry, but right now Intel isn't a viable option for servers, at least multi-processor ones. The front side bus speed and it being shared kills the performance of the otherwise great Xeon. Opterons are at a decent price range now for 2-4 x42-x46, and they are great performers as well as being 64bit compatiable. Also, the Xeon platform is most likely going to be replaced by whatever Intel's answer to AMD64 is, so upgrading is not too good. On the other hand, the Opteron is here to stay.
thisnukes4u.net
I never had a problem with Intel's processor ID. Every networked computer already has a unique MAC address. What is the difference?
MAC addresses can be changed by swapping out a $15 part and in some cases can be changed in firmware, so they're not an effective tracking/identification tool. Processor IDs are hardcoded and unique. Thankfully, they can also be turned off.
If a job's not worth doing, it's not worth doing right.
So, it wasn't the fact that the computer had a uniquely identifiable number (ip address/mac address/whatever), its the fact that you didn't have control over the use of that number.
I can deny you access to my ip address (I just don't connect to your server/use a proxy). I can also deny you access to my mac address (spoofing/proxies/whatnot). The rebellion people had was they couldn't deny programs access to your PID. Now, there wasn't any particular reason to deny programs access to a PID yet but it isn't too hard to think of a few.
Anyway, enough rambling. It was the removal of choice that set people off. We didn't have a choice to not use the feature - Assuming we stuck with Intel processors.
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
More information is in a similar article over at News.com.
They mention that proprietary BIOS's is one of the key obstacles to implementing proper power management (ie hibernation) under Linux.
- Neil Wehneman
My legal education, in nifty podcast format
One more advantage of RISC systems: OpenFirmware is a real standard, while Intel just wants us to believe it has an 'open architecture standard' and an 'SIG' instead of conforming to an already existing, real open standard.
One more instance of the proprietary lock-in game.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Why not open boot? Because the "open" means only "open spec".
Open Boot is not Open Source Have you ever wondered why nobody ports it to lots of things? Or why http://www.openbios.org exists? Simple. Open Boot is a marketing name.
Again, Open Boot is NOT Open Source. It's just a cute name that seems to fool lots of people.
But go ahead, prove me wrong: point to the Open Source site for Open Boot.
It's the ability to flash the BIOS that will make it happen. At some point, Microsoft will have to trust a piece of hardware. If they trust the software, it's merely a matter of time to find out where the branch is that says "yes this is trustworthy", and change the binary so that branch always takes "trustworthy" choice. Just like if I have access to your GPG binary, I can say that a message I sent you is in fact signed by Microsoft (the element of trust everone forgets is that you have to trust the binary sources, in this case, Microsoft can't, as I can fiddle with them). This is an arms race that Microsoft will always lose, it's just a fact of life.
So they must trust a piece of hardware at some point. That hardware must be untamperable, with no way for me to interject myself between it and the Microsoft hardware. As soon as I can interject myself between Microsoft and that piece of hardware, I've won. If I have access to the BIOS, all I have to do is setup some type of virtualization software (Think VMware). At this point, all I have to do is emulate the piece of hardware, and jigger it to always say: "Trustworthy" (essentially a MITM).
If you don't believe that type of attack is plausible, then remember also, I control the client, at some point, I can attack the PKI system. I have access to the PKI portion. At some point, you must have absolute trust of the PKI system, I have the client, what would it take to beat that system? Does Microsoft keep it's list of keys someplace around (it has to, I can subvert that)? That's like giving me access to the root cert's for your Web Browser. You'll trust my hacker sites if I can insert my key into your list of "trustworthy certs". At some point, if I have access to the boot sequence, I can break the system.
The only way it could be secure is to have the hardware have the list of trustworthy keys and have the hardware never give up control to anything that is considered untrusted.
How does Microsoft check that they are running on such a trusted? At some point, they either have to trust the hardware implicitly (which I can fake), or they have it in software that I can modify. At that point, it's either making an untrustworthy piece of hardware (or emulating one), or fiddling the bits of the software. In the end, DRM is a losing proposition. All DRM systems will be broken.
Microsoft might be able to encrypt the software, and only allow it to be decrypted by modules hardware that has the public key embedded inside. However, somebody will just tear the thing apart, or use an X-ray machine to just extract the public key (which at this point is merely a secret piece of data, not really a public key).
Kirby