Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Intel Software

Intel To Release Next-Gen BIOS Code Under CPL 224

Posted by timothy from the old-texas-town-of-el-paso dept.
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."
This discussion has been archived. No new comments can be posted.

Intel To Release Next-Gen BIOS Code Under CPL More

Intel To Release Next-Gen BIOS Code Under CPL

Comments Filter:

  • An ode to DRM FUD (Score:5, Interesting)

    by stecoop ( 759508 ) on Tuesday June 01, 2004 @10:13PM (#9311068) Journal
    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?

    • Re:An ode to DRM FUD (Score:5, Funny)

      by k4_pacific ( 736911 ) <`moc.oohay' `ta' `cificap_4k'> on Tuesday June 01, 2004 @10:18PM (#9311096) Homepage Journal
      Chances are, flashing your PC with this BIOS instead of the MS approved DRM one will prevent your PC from sharing data with DRMed Windows PCs. So, DRMed if you do, DRMed if you don't...

      • Re:An ode to DRM FUD (Score:4, Insightful)

        by Anonymous Coward on Tuesday June 01, 2004 @10:28PM (#9311153)
        Data sharing is important, and I understand your point completely. How then do we counter this? If nothing else, we're somehow assured (presumably) that we can at least run non-drm software. From there, it'll still be a matter of reverse-engineering any DRM scheme...kind of like a more extensive MS Word compatibility layer.

        I do have confidence in the Open Source hacker army, though, and that if there's a way, they'll figure it out.

        • Get our minds right first and last. (Score:5, Insightful)

          by Doc Ruby ( 173196 ) on Tuesday June 01, 2004 @11:00PM (#9311344) Homepage Journal
          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.

      • Re:An ode to DRM FUD (Score:5, Insightful)

        by Amiga Lover ( 708890 ) on Tuesday June 01, 2004 @10:44PM (#9311248)
        Chances are, flashing your PC with this BIOS instead of the MS approved DRM one will prevent your PC from sharing data with DRMed Windows PCs. So, DRMed if you do, DRMed if you don't..

        If it works that way it'll also prevent a DRMd PC from sharing data with those linux servers becoming all so common nowadays. Works both ways.

        In the end all depends on who ends up worse off.
        • The general idea is that Microsoft wants to use it to prevent those Linux servers from becoming common.

          In fact, that's why people are opposed to MS DRM in particular - they dislike losing their property rights, and especially dislike losing them in the name of corporate profit!
      • I'm really not that sure about that. If you want to make sure your iTunes, or other DRMed music downloads still work, granted, it might be a problem. But open formats are open and always will be. Swapping the OS or BIOS to a non drmed one will still let you transfer files in an open and free way. JPGs for instance, should still transfer between DRMed and non-DRMed PCs through FTP for example. I just don't see how a DRM bios could affect this functionality. TCP/IP itself is designed to be platform independan
        • A "DRM-extreme" Bios could deny any transfer without an explicit authorisation, making the reading of a jpg file an illegal instruction. Granted TCPA isn't expected that bad, but nothingsays it can't be that bad either... In fact, many laws work in this exact way, and legal advice usually goes "If you're not explicitely sure you can, don't." That you have to justify your ownership of files to your computers when restoring a 3 year old backup of hundreds of thousands of files might become problematic.
        • I'm sure many ./ers and other would pay good money to have a properly designed system with modern components that is DRM free.

          Of course untill the **AA's use there bought congress critters to pass a law stating that anyone who uses a DRM free machine is violating the law.

    • Not really (Score:5, Interesting)

      by autopr0n ( 534291 ) on Tuesday June 01, 2004 @10:20PM (#9311110) Homepage Journal
      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.

      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 :P

      • Comment removed (Score:5, Insightful)

        by account_deleted ( 4530225 ) on Tuesday June 01, 2004 @10:42PM (#9311236)
        Comment removed based on user account deletion
        • All security is security by obscurity. That's the dumbest phrase going. Too bad it rhymes.

          • Re:Not really (Score:3, Insightful)

            by Anonymous Coward
            No.

            Good security is well known. The techniques and procedures studied by thousands of expert math and cypher experts.

            Now, the private key does have to remain private... this is the secret _you_ keep. This is a secret that _can_ be kept, with safes and locks and armed guards and attack dogs and mine fields and phospate hand gernades and tanks and air craft.

            What DRM is trying to do is have a private key that _you_ do not have. _You_ the owner of the computer and all the bits on it are having a secret kep

      • Re:Not really (Score:3, Interesting)

        by MBCook ( 132727 )
        But it CAN be. Because you have the source, you can build a version in which you've stripped out the DRM stuff that you don't want. And THAT would remove the DRM worries.

        Of course, as you mentioned, all they have to do is require that the BIOS is signed to prevent the end user from doing that, which would be unfortunate. This also assumes that the open source part is functionally complete (i.e. not a layer ontop of the layer that drives the hardware, which could be closed source so nothing you made could b

        • Re:Not really (Score:5, Interesting)

          by YrWrstNtmr ( 564987 ) on Tuesday June 01, 2004 @11:06PM (#9311369)
          Would you buy a car you're not allowed to fix yourself and still retain the warranty? You can drive it all you want, just don't screw with it.

          And that's what most people do with their PC. Drive it. Not muck around under the hood and tweak the fuel injectors, or adjust the slope of the ABS initiation.

          • Re:Not really (Score:5, Insightful)

            by prockcore ( 543967 ) on Wednesday June 02, 2004 @12:06AM (#9311633)
            And that's what most people do with their PC. Drive it. Not muck around under the hood and tweak the fuel injectors, or adjust the slope of the ABS initiation.

            Ironically, Congress is forcing auto makers to reveal their "precious precious IP" because your average mechanic can't read the chips in your car. Basically auto makers were trying to get you to take your car into the dealer to get an oil change. Congress stepped up and said "that's unfair trade practice".

          • It's worse than that. (Score:4, Insightful)

            by BiggerIsBetter ( 682164 ) on Wednesday June 02, 2004 @01:43AM (#9312114)
            Would you buy a car if you're not allowed to reverse engineer the ECU to reset the Service Due light after changing the oil yourself? Oh, and if you do that anyway, you'll be charged under the DMCA and sent to PITA prison.

      • Re:Not really (Score:3, Insightful)

        by John Hurliman ( 152784 )
        But you can modify the Linux kernel to allow any user to gain root privileges. That's the point of the source code, anyone can rewrite/recompile/reinstall and remove any offending "features" while adding their own modifications.

        • Re:Not really (Score:5, Interesting)

          by Alsee ( 515537 ) on Wednesday June 02, 2004 @12:27AM (#9311737) Homepage
          the point of the source code, anyone can rewrite/recompile/reinstall and remove any offending "features" while adding their own modifications

          Nope.

          The entire purpose of the new system is to prevent exactly that. Sure you can change the code, but then the firmware chip (trust chip)then reports a "currupted" boot value. The new trusted software will refuse to install. The new trusted files will be encrypted and unreadable. The new websites will give you error messages and be unviewable.

          With Trusted Computing the source code becomes useless. The system defeats the GPL.

          But to top it all off, Cisco has announced a line of Network Admission Control routers that will deny you any internet access at all. It is billed as "blocking viruses", but what it really does is refuse you a connection unless you are running a Trusted computer and approved software. If you try to use to source to make any chages the hardware reports a "currupted" boot value. As far as the ISP's router is concered you are either infected with a virus or at least vulnerable to a virus.

          All new computers sold computers will start shipping with Trust chips installed by default within a year. After 4 years or so essentially all PC's will have been routinely replaced as obsolete. I figure such routers could be generally deployed by ISPs in approximately 2008.

          -
      • Think about it, the fact that you can see the source code to Linux doesnt 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.

        But the thing is that the way linux prevents a user from being root is by having someone else manually change the password to something that is not in the source code. There is important data being witheld from the user, that will unlock the system. As DRM syst

      • Re:Not really (Score:5, Informative)

        by ComputerSlicer23 ( 516509 ) on Wednesday June 02, 2004 @12:17AM (#9311679)
        I don't think you are correct. If I can control the POST sequence, and I have the Microsoft Software, the system can be broken. Period.

        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

    • 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?

      Err, that just meant that the end user wouldn't be paying directly for the hardware, just indirectly. Someone will still be writing a check to Intel for all of their components. I can't see how Intel would look on that other than favorably. That would actually m

  • CPL (Score:5, Insightful)

    by devinoni ( 13244 ) on Tuesday June 01, 2004 @10:14PM (#9311080)
    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.
    • I suspect its popular because it has most of the good elements of other open source licences like GPL but at the same time it doesnt have all the "politics" associated with FSF.

      • Re:CPL (Score:2, Interesting)

        by Whyzzi ( 319263 )
        Ok. So then, what is the big difference between the CPL and the BSD license?

        • Re:CPL (Score:3, Interesting)

          by Anonymous Coward
          So then, what is the big difference between the CPL and the BSD license?
          Copyleft, and a "we license our patents only if you don't sue us with yours" clause.

        • Re:CPL (Score:3, Informative)

          by geminidomino ( 614729 )
          From the license:
          When the Program is made available in source code form:

          a) it must be made available under this Agreement; and

          b) a copy of this Agreement must be included with each copy of the Program.


          And:


          A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that:

          a) it complies with the terms and conditions of this Agreement; and

          b) its license agreement: ...

          iv) states that source code for the Program is available from

          • Re:CPL (Score:3, Interesting)

            by HokieJP ( 741860 )
            If I understand the license correctly, there is a key difference that you're missing:

            In the first passage you cite, it need only be made available under the CPL if released in source code form. So, you could distribute binaries of the code under any license you want. The satement that the new license "complies with the terms and conditions of this Agreement" isn't the same as saying you have to release it under the same license. It just means you can't violate any of the conditions of that license (say,

  • Credibility for Intel (Score:5, Interesting)

    by SeanTobin ( 138474 ) * <<byrdhuntr> <at> <hotmail.com>> on Tuesday June 01, 2004 @10:15PM (#9311084)
    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 [microsoft.com] 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!

    • Not again... (Score:4, Interesting)

      by vwjeff ( 709903 ) on Tuesday June 01, 2004 @10:21PM (#9311113)
      Processor ID's sucked

      I never had a problem with Intel's processor ID. Every networked computer already has a unique MAC address. What is the difference?

      • Re:Not again... (Score:5, Informative)

        by Dun Malg ( 230075 ) on Tuesday June 01, 2004 @10:27PM (#9311149) Homepage
        Processor ID's sucked

        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.

        • You can also change your MAC address at will... something like:

          ifconfig eth0 hw ether 00:DE:AD:BE:EF:00

          might not be totatally right... man ifconfig!

        • 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.
          That's a silly argument -- the CPU can be swapped out too, and in modern machines it's not so expensive anyway.

      • Re:Not again... (Score:5, Informative)

        by SeanTobin ( 138474 ) * <<byrdhuntr> <at> <hotmail.com>> on Tuesday June 01, 2004 @10:27PM (#9311150)
        I never had a problem with Intel's processor ID. Every networked computer already has a unique MAC address. What is the difference?
        The big problem that many people had with the processor ID's initially was that you couldn't turn them off. Any program running localy could query your PID and send it off to god knows where. It wasn't until later that they released bios updates that allowed you to turn the feature off.

        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.

        • Re:Not again... (Score:5, Interesting)

          by afidel ( 530433 ) on Tuesday June 01, 2004 @10:52PM (#9311285)
          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.

        • I'm pretty sure that almost immediately after Intel released that "feature", the next Linux kernel was patched to disable it on boot.

          On the one occasion I've left it on in my BIOS ( a number of years ago now), in the Linux kernel boot log was a statement that the PID was being disabled.

      • Uhhh, I don't know, the fact that you can override your MAC address a little easier than you could override your processor ID number?

        I don't agree with processor IDs, but that was a stupid question to be modded so high.

      • Re:Not again... (Score:4, Insightful)

        by 222 ( 551054 ) <stormseeker@nOsPAm.gmail.com> on Tuesday June 01, 2004 @10:41PM (#9311224) Homepage
        It should also be noted that MAC addresses actually provide required functionality, modern day networking is built around them... For the life of me, i cannot think of any productive use for cpu id's.
      • MAC addresses can trivially (in both $ & time) be changed by changing your network card. Compare that to changing your processor/mobo.

        Also, MAC addresses can (at least theoretically, I may be wrong here) be masked/transformed at the router level (thereby perserving anonymity to the rest of the world/internet).

    • 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.

    • Open bios code wont do you any good. (Score:5, Insightful)

      by autopr0n ( 534291 ) on Tuesday June 01, 2004 @10:23PM (#9311125) Homepage Journal
      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.
      • Having an open-source bios wont prevent DRM any more then having an open-source OS will prevent file permission restrictions.

        With an Open Source OS, I can hack away those file permissions while retaining full compatiblity with the orginal. Nothing difficult about it. The only reason it hasn't been done, is because file permissions are beneficial to the owner of the system.

        If there's DRM in the BIOS that isn't beneficial to the owner, he'll get rid of it if he can. He might not be able to do it himself, b

    • Re:Credibility for Intel (Score:2, Funny)

      by Anonymous Coward
      I have a box full of Bunnypeople that, one summer, will end up strapped to my car's wheels. For how long, who knows...

      I took a couple of them, did that, and after enough miles at high enough speeds, the beans started transferring to the extremities, then pieces invariably went bouncing down the road. As I recall, it took around 100mph.

      BTW, I have relatively thick 5-spoke alloys, and 4 of them got either a leg or an arm, and since the weight was mostly centered on on the wheel the vibration was minimal.

      Oh

    • Re:Credibility for Intel (Score:4, Insightful)

      by Alsee ( 515537 ) on Wednesday June 02, 2004 @12:57AM (#9311916) Homepage
      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.

      It is a trick. They are publishing the source code, but that source code is USELESS.

      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.

      Then you need to make sure NEVER to let this crap touch your computer! This system is EXACTLY designed to make it impossible to control your own computer. If you change so much as a single instruction then the Trust chip generates a different hash value. With a different hash value the Trust chip cannot decrypt anything. Ultimately you may be denied any internet access at all.

      I had decided on AMD. I'm now considering Intel as an option.

      Unfortunately AMD is on board with this crap as well. So are Motorola, Transmeta, and even ARM. There's really no good-guys to turn to at this point, but if you want to boycott someone then Intel definitely tops the list. AMD is just following along because they will up and die if the next version of Windows refuses to run on an AMD chip.

      -

  • Microsoft Support? (Score:5, Insightful)

    by 3) profit!!! ( 773340 ) on Tuesday June 01, 2004 @10:22PM (#9311118) Homepage
    "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...
    • Not really. EFI is used on Itanium machines, so Intel 64 bit Windows already uses it pretty well.

    • Re:Microsoft Support? (Score:5, Insightful)

      by Alsee ( 515537 ) on Wednesday June 02, 2004 @01:06AM (#9311962) Homepage
      I wonder if this is going to be like Microsoft's "support" for Java

      No, it's more like Microsoft support for Palladium.

      As a matter of fact this *is* Microsoft support for Palladium.

      Central elements of the system were designed by Microsoft + Intel + the rest of the Trusted Computing Group. This new "Foundation code" *is* the Palladium replacement for BIOS. It is the Trusted Computing foundation.

      -

  • Wonder how it will affect (Score:5, Interesting)

    by ErichTheWebGuy ( 745925 ) on Tuesday June 01, 2004 @10:25PM (#9311133) Homepage
    the LinuxBios [linuxbios.org] 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.

  • OpenBoot? (Score:5, Insightful)

    by Anonymous Coward on Tuesday June 01, 2004 @10:26PM (#9311143)
    What, dare I ask, is wrong with OpenBoot? It's an open standard; it's been around for a long time; and it's used in at least two [sun.com] manufacturers' [apple.com] systems that I can think of. I've also heard reports that some (obscure, probably now defunct) Intel-based PC manufacturers used it in their systems.

    Seems to me like a bad case of "Not Invented Here" syndrome.

    • Re:OpenBoot? (Score:5, Interesting)

      by afidel ( 530433 ) on Tuesday June 01, 2004 @10:55PM (#9311311)
      That's EXACTLY what I was thinking when I read about this project several years ago. OpenBoot is Free/free and proven. Not only that but it's hard to imagine a more flexible system since it includes a Turing Complete programming language at its heart =) After you've used OpenBoot the PC BIOS seems so limiting and mundane.

    • Re:OpenBoot? (Score:5, Insightful)

      by RickHunter ( 103108 ) on Tuesday June 01, 2004 @11:00PM (#9311336)

      What's wrong with it? No DRM support (thus, no Microsoft support) and it wasn't invented by Intel. (Thus, no Intel support) It is, however, a far superior system, and yet another reason to get a Mac. (YARTGAM)

    • Re:OpenBoot? (Score:3, Informative)

      by pavon ( 30274 )
      One of the big features of this new bios is that it is completely backwards compatible (as far as the OS is concerned) with the current BIOS. I don't think that switching OpenFirmware would be quite as seamless of a transistion.

    • Re:OpenBoot? (Score:4, Informative)

      by ronaldgminnich ( 567142 ) on Wednesday June 02, 2004 @12:06AM (#9311631)
      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.

      • Re:OpenBoot? (Score:2, Interesting)

        by znu ( 31198 )
        Uh, it's an open standard, like TCP/IP or HTTP. Some implementations are open source, some are not. I don't see any conspiracy here.

  • Great! (Score:5, Interesting)

    by autopr0n ( 534291 ) on Tuesday June 01, 2004 @10:26PM (#9311145) Homepage Journal
    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.

  • Sounds good.... but... (Score:5, Insightful)

    by 3seas ( 184403 ) on Tuesday June 01, 2004 @10:28PM (#9311152) Homepage Journal
    ... 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...

  • One of the best ways, (Score:2, Insightful)

    by Anonymous Coward
    it almost seems, to ensure you can write open source software and still make money is to make absolutely certain that your open source software is written in such a way it isn't of any use to anyone unless they buy your expensive hardware to operate with it...

  • More Info / Linux Power Management (Score:5, Informative)

    by Landaras ( 159892 ) <neil@@@wehneman...com> on Tuesday June 01, 2004 @10:51PM (#9311283) Homepage
    More information is in a similar article [com.com] 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

  • From the LinuxBIOS mail list earlier today: (Score:5, Interesting)

    by LuxuryYacht ( 229372 ) on Tuesday June 01, 2004 @10:52PM (#9311286) Homepage


    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 ... a Linux kernel! You might need a small shim from the hidden hardware code to Linux, which could in turn be ... LinuxBIOS!

    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.

  • Hey, they can't do that! (Score:4, Funny)

    by Anonymous Coward on Tuesday June 01, 2004 @10:54PM (#9311305)
    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.

  • OpenFirmware (Score:5, Informative)

    by leandrod ( 17766 ) <{gro.sartud} {ta} {l}> on Tuesday June 01, 2004 @10:58PM (#9311329) Homepage Journal
    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.

    • Re:OpenFirmware (Score:3, Interesting)

      by AKAImBatman ( 238306 )
      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.

      Not to mention that it's much cooler. You've got to love how easy it is to tell a Solaris machine to boot from ANYTHING without even an OS on the system! Boot from network? Never have to touch the machine. Boot from USB? A two line command? CDROM? Same! Boot from next years wizzigig? Done.

      It's also great for saving a sys

    • OpenFirmware rules (Score:5, Interesting)

      by n1ywb ( 555767 ) on Tuesday June 01, 2004 @11:24PM (#9311440) Homepage Journal
      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.
      • 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.

        If you think that's good, you should try Sun's OpenBoot on a SPARC machine some time. Not only does it have the powers you've come to expect from OpenFirmware, but it's got purdy scalable fonts, graphics, and iis far less buggy than Mac's OF. Besides, my Mac makes me squint, and I like pure white instead of off-white. ;-)

      • Re:OpenFirmware rules (Score:3, Interesting)

        by Domini ( 103836 )
        The coolest thing about the OpenFirmware on my iBook is the fact that you can run a telnet server in it! (Google is your friend!)

        Great for when your Firmware stuffs up your display!

        Not to mention being able to solve towers of Hanoi problems! ;)

    • Re:OpenFirmware (Score:5, Informative)

      by Etcetera ( 14711 ) * on Tuesday June 01, 2004 @11:25PM (#9311445) Homepage

      That's exactly what I was going to post :) So.... I'll post some useful links instead! For those that don't know, Open Firmware is a FORTH-based boottime environment that handles all Sun and Mac machines recently produced, and also was used in the PReP/CHRP boards. IBM may still use it in some areas, I'm not sure...

      The Firmworks stuff with Linux and OF looks particularly neat...



      And here's a cool example of things you can do with OF. Two-machine mode boot debugging [apple.com]

      • >

        Open Firmware is a FORTH-based boottime environment that handles all Sun and Mac machines recently produced, and also was used in the PReP/CHRP boards. IBM may still use it in some areas, I'm not sure...

        Unless I am severily mistaken, all POP systems (based on an IBM PowerPC reference design) being distributed by EyeTech and Genesi are also OpenFirmware.

        I have some idea that SGIs, including the Intel ones, were also OF, but I am probably wrong on this one as SGI was a member of the ARC.

  • Once upon a time, IBM released the BIOS source... (Score:5, Interesting)

    by monkeymanatwork ( 653088 ) on Tuesday June 01, 2004 @11:22PM (#9311430) Homepage
    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.
    • If memory serves correct, the ASM source for the BIOS was published as part of the original PC/XT Technical Reference Manual.
    • Not open source in what sense? By the capitalsation, I assume that you're equating "Open Source" to be more than just "access to the source code", but that's adding more to the definition than is present in the words themselves.

      You had the source of the program; I'd say it was open source. No, it wasn't GPL licensed (or BSD, or whatever), but it certainly wasn't "closed" either.

  • Free Programmers? (Score:4, Insightful)

    by timgoh0 ( 781057 ) on Tuesday June 01, 2004 @11:29PM (#9311468)
    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?

  • More Secure? (Score:5, Insightful)

    by niktesla ( 761443 ) on Tuesday June 01, 2004 @11:39PM (#9311524) Homepage
    It is stored in firmware, so it is more secure from viruses and other types of attack than past BIOSes
    [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.

  • Nothing to see here, move along (Score:4, Interesting)

    by jmorris42 ( 1458 ) * <jmorris&beau,org> on Wednesday June 02, 2004 @12:24AM (#9311714)
    Unless you are a motherboard maker you won't be using this source dump. All of the hardware level details will remain hidden away in vendor's source trees so an end user will never be able to link a complete copy.

    It might prove useful now and again to conpare documented behavior to actual, but that is about the extent of it.

  • You think worms are bad now... (Score:3, Interesting)

    by Uzik2 ( 679490 ) on Wednesday June 02, 2004 @09:56AM (#9314153)
    " 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."

    Did you notice the part about 'administrative interfaces'? This means your PC will have a remote control interface built right into the BIOS. Now anything that's turned on and connected to the network will be remotely exploitable. Even your Linux box, or your toaster will be worm fodder.

Slashdot Top Deals

Stellar rays prove fibbing never pays. Embezzlement is another matter.

Close