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."
Will this end the fear of DRM'd BIOS? With the source available then any additions added to the bios can be reversed. I wonder if Intel is countering something in regards to statements made by Microsoft and Sun saying that hardware will be free?
Seems the CPL is popular these days. Even Microsoft uses it for their opensource projects (WiX and WTL). Not to mention IBM who is the CPL author.
Intel has been slowly losing credibility in my (and possibly others) eyes for some time now. Processor ID's sucked. However, they 'did the right thing' and got rid of them. Their implimentation of 64-bit computing sucked (or was ahead of its time) but they 'did the right thing' and swiped AMD's :). I used to be a Intel fanatic (yes, I owned several bunny people) and dismissed AMD's processors because of thier floating point performance. AMD wised up and finally gave chase to Intel on all performance matters to the point where I'm now running a AMD processor. I've always been concerened that Microsoft and Intel are a little too friendly, especially in regards to 64-bit windows versions and Microsoft/Intel's chip/release timing.
Anyway, the BIG concern for me on the horizon is the upcoming DRM-from-the-bios-to-the-speaker-cone mentality that some unnamed people are trying to push. If Intel wants to score major bonus points in my book, opening up the bios (or whatever they feel like calling it) could definately do it.
If I know that I can always depend on my computer to do what I tell it to and not what Intel/Microsoft/Belken tell it to do, I will go that route.
Also, to Intel... I'm buying a new server next month. I had decided on AMD. I'm now considering Intel as an option. Now everyone in the marketing department go tell the engineering department to go impliment this!
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
While the source may be available, that won't mean it can't contain DRM. After all, any good secure system should be secure wether or not the source is visible or not.
:P
Think about it, the fact that you can see the source code to Linux doesn't mean that a regular user has any greater ability to gain root. That's exactly how these new DRM systems work, by taking a way a user's right to be root on their own machine.
Flash your own Tiano BIOS, and on DRM certified mobo's it simply won't run unless its signed by Microsoft or someone.
So this wont help with DRM, but it's still a good thing
autopr0n is like, down and stuff.
"Microsoft is continuing its commitment to open industry standards by adding EFI boot support to all versions of the Longhorn generation of Windows products," said Tony Pierce, Technical Evangelist of Microsoft's Windows Hardware Innovation Group. "Participation in the collaborative community effort around the Foundation code that Intel is announcing today will help systems manufacturers and firmware companies deliver new and exciting platform innovations to their customers."
I wonder if this is going to be like Microsoft's "support" for Java...
Having an open-source bios wont prevent DRM any more then having an open-source OS will prevent file permission restrictions. The source to Linux wont do you any good without the root password, and the source to the BIOS won't do you any good without a signing certificate on a DRM-enabled motherboard.
autopr0n is like, down and stuff.
the LinuxBios project? I would think little, if at all, since the core goals of the LinuxBios project are so specific (providing instant control of a cluster node), but maybe I am wrong? Perhaps some innovations can flow both ways.
Either way, kudos to Intel.
bash: rtfm: command not found
Seems to me like a bad case of "Not Invented Here" syndrome.
wow, this is actually pretty cool. Imagine being able to download a bios patch off the 'net that would let you boot the machine directly into Linux, or hell... put a webserver right into the bios chip.
In the future I can see the ultimate "geek" motherboard having a memory-stick or CF card slot for the bios, rather then using chips that aren't often used by consumers. You'd be able to walk down to best buy or Wal-Mart and buy a new bios chip to play around with.
autopr0n is like, down and stuff.
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;
... sounds exactly like hype that is bound to be turned into something you do not want, in actuality.
Like the original intent of cookies and the actuality of spyware use...
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
Actually they could NEVER be turned off all the way. The BIOS patches just disabled them during startup, and Windows didn't turn it back on. But if you knew the correct sequence and a little assembly you could reactivate the PID 'feature' and query the number. I don't think there was ever a real program that did this but there were a few demo pieces that were enough proof of concept to show that it was possible.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Ron on the LinuxBIOS list put this best earlier today:
You are not going to get the hardware startup code in Tiano. You're going to get the code that runs on top of the hardware startup code, and gives you a DOS-like startup system.
Don't expect to suddenly see northbridge code on the intel web site. Part of the goal of Tiano/EFI is to make the release of such information unneeded. There is a silver lining. Supposedly, the interfaces from the hidden hardware code to Tiano will be public. This means you can conceivably chuck Tiano and put your own thing in its place, which could be
This is how Linux NetWorx built the Alpha LinuxBIOS:
- hidden hardware
code (Alpha SROM) [ not changed, left in place]
- LinuxBIOS [with Alpha support, minus memory setup code]
- Linux
Worked fine, should work for Tiano platforms. In other words, the binary support code for Tiano could solve some problems for us:
- if we don't get the specs for the Intel chips (likely), then we can just leave the "hidden hardware code" in place, and flash over Tiano,
replacing Tiano with LinuxBIOS. I believe Linux Labs did something like this for their ClearWater port 2 years or so ago.
- Makes porting to other Intel mobos easier.
Why the CPL, not the GPL?
So that 3rd party vendors can add incompatibilities -- err, value --
and charge you for it.
Put another way, Tiano could be a linuxbios payload. I don't have much
use for a Tiano/EFI payload, however. Tiano/EFI is very complex and if
I'm going to put a complex thing like that into flash I'd much rather
it be linux. I don't want something that's most of the work of an OS
but not much of the capability, which pretty much describes Tiano/EFI.
I'm intrigued that they are open sourcing it. I had for years only
heard that it would be available under a type of NDA. I think LinuxBIOS
is part of the push for open sourcing this type of software. But I
doubt you're going to see Phoenix et. al. open source their
'value-added' Tiano, which means a source fork is built into the model.
That's trouble for us as customers -- we already suffer daily with all
these BIOS extensions and undocumented, hidden gotchas. We already say
this once: there was supposed to be a standard "hand off" on IA64 for
startup. I found out that this "standard" handoff was modified by
several vendors: it was no longer standard.
Let's hope the "hidden
hardware code" to Tiano interface remains standard. Also, if this code
is anything like the EFI code, it won't build under Linux, only builds
under Windows. It won't "just work" for us.
All that said, I think Intel is doing a good thing by open sourcing the Tiano system, and I congratulate them on doing so.
Quidquid latine dictum sit altum viditur
Intel better not release BIOS under a CPL because it is obvious that SCO owns this. Look out Intel, you are now in the viewfinder of SCO.
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
Data sharing is literally essential - computers are only marginally useful if their only info exchange is via keyboard/mouse/monitor. DRM is a tech implementation of the human activity of trust. Proprietary DRM schemes, like M$ Passport, or any other vertical integration, are bad trust models. They fetishize others of the same breeding, trusting identical platforms more than different ones. That kind of model is like feeding cattle the remains of their unsold brethren, a monoculture that amplifies platform weaknesses like mad cow, which incubate in a species and even threaten others. The diversity of open trust standards, like PGP webs of trust, or public SSL CAs, combined with open, mutual audits, keep the ecosystem healthy. Before we build a rickety infrastructure based on flawed models and self-defeating principles, we must get to the right way to manage these systems - then automate them. An open source BIOS, which interoperates with the rest of the Internet ecosystem, at least preserves the options to do that, without passing the point of no return on the wrong path.
--
make install -not war
I remember in the late 80's seeing a bound, printed version of the IBM XT BIOS source code (ASM of course). It belonged to a friend and probably dated from the early 80's. IIRC, he sent IBM a check for $50 and they sent it to him.
Not Open Source, but invaluable when we were developing device drivers, TSRs, and other low-level software.
OpenFirmware is the most amazingly awsome BIOS ever. Mostly because it's written in Forth which is one of the most amazingly awsome languages ever. I learned Forth specifically so I could hack on my PowerMac 7500's OpenFirmware. It's too bad Apple's old OF implementations were a bit buggy, but the newer PowerMacs' OF is super.
For those who aren't familiar with Forth: Forth is a very powerful and easy to learn language. It's hardware requirements are very light and it is completely portable. Except for the most fundamental procedures, Forth is written in Forth and is completely modifiable and extensable. Forth programs are written as extensions of Forth itself. Forth is an interpreted language, and can be used from a Forth shell, much like BASIC. However, it is almost as fast as C, and equally powerful. Forth is an ideal language for embedded computer systems.
For those of you that aren't familiar with OpenFirmware: OF is written in Forth and is very powerful because it can be manipulated from the Forth shell. This makes it very straightforward for an intelligent user to modify his BIOS as he sees fit, write BIOS scripts, modify settings, etc. The OF Forth shell gives you all the power of a normal PC BIOS and GRUB and then some. It even has a rudimentary edlin like text editor. Anyway if you own a Mac, look up some info on OF and play around with it a bit, it's pretty freakin cool.
-73, de n1ywb
www.n1ywb.com
Maybe its just me, but don't you think that this is just a way of intel trying to get free and fast bugfixes and improvement for their bios?
[sarcasm] Yeah, there were real virus problems w/ BIOS back when it was non-flashable. Those pesky viruses would pop my BIOS chip out and install a new one before I knew it.[/sarcasm]
Extra or additional drivers and code functions can be stored on the hard drive and accessed there.
Seems like this would increase the vulnerability of the BIOS.
Other than this problem and maybe not being able to control some of the OEM preboot (an odd word when you think of it) "features" (DRM, etc.), this doesn't sound too bad of a plan. Sounds like we're on the way to having the OS run off a FLASH disk or some type of firmware. It'd be ironic if, because of advanced DRM technology, we have to go back to the oldest mod trick - yank out the old chip and solder in the new, as was once done to upgrade BIOS.
I've discovered a remarkable proof, but this margin is too small to contain it...