Forgot your password?
typodupeerror
Hardware

Writing an End to the Bio of BIOS? 511

Posted by CmdrTaco
from the ami-phoenix-award-oh-my dept.
An anonymous reader writes "Intel and Microsoft are gearing up to move toward the first major overhaul of the innermost workings of the personal computer. The companies will begin promoting a technology specification called EFI (Extensible Firmware Interface) as a new system for starting up a PC's hardware before its operating system begins loading."
This discussion has been archived. No new comments can be posted.

Writing an End to the Bio of BIOS?

Comments Filter:
  • by Hej (626547) on Tuesday December 30, 2003 @10:53AM (#7834817)
    I wonder if this new BIOS replacement will be designed based on the assumption that everybody is running the most current version of Windows.
  • by Anonymous Coward on Tuesday December 30, 2003 @10:54AM (#7834836)
    One thing I've always hated about the standard PC BIOS is that you need a keyboard, video and mouse (kvm) to configure the thing.

    It'd be great if EFI initialised a serial console if detected that there was no KVM attached to the system. It'd be great for custom-made PC routers and servers on generic hardware running Linux or xBSD.
  • OpenFirmware (Score:5, Interesting)

    by AKAImBatman (238306) <akaimbatman@gmai[ ]om ['l.c' in gap]> on Tuesday December 30, 2003 @10:56AM (#7834866) Homepage Journal
    OpenFirmware [openfirmware.com] is older than the hills, well tested, loved by all, and used on just about every machine EXCEPT Intel. Is anyone getting a sense of NIH syndrome?

  • Why? (Score:5, Interesting)

    by mekkab (133181) * on Tuesday December 30, 2003 @10:57AM (#7834875) Homepage Journal
    The excuse "WEll, current BIOS systems is just patch written upon patch written upon patch. ITs a mess."

    But it works. Is an EFI system going to be markedly faster? When you tell me you are loading device drivers at the BIOS level, that tells me "No"- you are creeping the OS lower.

    So whats the deal?
    from Intel's EFI web site [intel.com]: Together, these provide a standard environment for booting an operating system and running pre-boot applications.

    AHhhh! Running PRE-BOOT operations! This sounds like a lame way to shoe-horn in DRM or something similar onto my machine before it loads up.

    Maybe I'm acting paranoid, but the slowest thing on my windows computer is WINDOWS, not the bios- that runs pretty fast.
  • Microsoft Logic (Score:4, Interesting)

    by Alien54 (180860) on Tuesday December 30, 2003 @11:00AM (#7834896) Journal
    Because then Microsoft could not get it's Digital Rights management technology implemented into the hardware, and thereby lock out Open Source systems to one degree or another.

    There's been lots of worry about this sort of thing, given MS busines practices in the past.

    Freedom is a hard concept for some folks to deal with

    I hope that this turns into a financial disaster for them.

  • by cybermancer (99420) on Tuesday December 30, 2003 @11:01AM (#7834923) Homepage
    I noticed that the first PC to use EFI was a Gateway "Media Center" desktop. For those who do not know, Media Center is Microsoft's first attempt at highly integration of DRM (Digital Rights Management) into the core functionality of the OS. Knowing the agenda for Palladiam and so called "Trusted Computing" (Who do you trust today?) I would really think twice before letting the likes of Microsoft and Intel (remember the P4 CPU ID?) rewrite my PC at the BIOS level.

    The "competition" between Pheonix BIOS and EFI could be the beginning of the split between closed platform "Trusted" PC's and open platform PC's. I would not be surprised if EFI has provisions (at some future point) to require the OS is signed. That rules out Linux, BSD, etc.

    Naturally they are doing all this for our best interests.
  • by dido (9125) <dido@i[ ]rium.ph ['mpe' in gap]> on Tuesday December 30, 2003 @11:04AM (#7834942)

    The original PC BIOS has incredibly remained basically unchanged since the days of the IBM PC, more than twenty years ago. We have all that legacy stuff in our PC's firmware that harks back to the days of MS-DOS and its limitations are being stretched to the breaking point by hacks and kluges (e.g. the disk size limits imposed by the real-mode BIOS calls). It would be nice to see it all go away for good.

    On the other hand, it's Microsoft and Intel working together on this. This could very well be the next step towards the groundwork for Palladium, and more ugly DRM embedded into the lowest levels of PC hardware, that may well prevent anyone from running any operating system on commodity PC hardware besides that of Microsoft, among other baneful things. I'm not willing to bet that this new specification doesn't lay this type of groundwork in any way.

  • Re:EFI sucks (Score:5, Interesting)

    by zdzichu (100333) <zdzichu@irc.COWpl minus herbivore> on Tuesday December 30, 2003 @11:09AM (#7834984) Homepage Journal
    EFI sucks. Even Linus says so [kerneltraffic.org].
  • by 3lb4rt0 (736495) on Tuesday December 30, 2003 @11:09AM (#7834988) Homepage Journal
    Quoting the Phoenix article linked to in the body of the main article

    "Future versions will take aim at servers, blades, desktops and embedded systems such as consumer electronics, with plans to introduce digital rights management (DRM) and more closely integrate the BIOS with Windows."

    Gonna end up between a rock and a hard place as far as DRM is concerned.

    Those media co.s have to try and squeeze every penny.
  • by Anonymous Coward on Tuesday December 30, 2003 @11:11AM (#7835006)
    Take ACPI, for example. If you take out the P of ACPI, and stick to the configuration features, you end up with something very similar to (some parts of) OF. A device name tree? OF has it. An intermediate language for device initialization? OF has it.

    OF has only one difference to ACPI: OF works. Devices are made with valid machine-language drivers, so that the OS doesn't have to patch it upon boot, etc, etc, etc. Don't take me wrong, I really believed that ACPI would be great, but when people started implementing it, we saw what mess it became. It was one of the reasons I moved away of the x86 platform. It is just a bunch of hacks.

    So why Intel created ACPI? Because while ACPI is also "open", Intel can control it. And Intel knows that while it keeps the power of defining standards, it will be the leading chip manufacturer: it helps to keep it top of mind in terms of consumer ICs.

    For those who don't know what OF is, take a look at this [firmworks.com].
  • by Negative Response (650136) on Tuesday December 30, 2003 @11:16AM (#7835035)
    Hmm, I am not too sure. Intel is not the problem, Microsoft is. If they give AMD an choice between complete compliance or no Windows support for their hardwares, what would AMD choose?
  • by Anonymous Coward on Tuesday December 30, 2003 @11:19AM (#7835059)
    Now the bios will have to be patched as frequently as windows because they'll mess it up the first 38 times. New types of security vulnerabilities, new viruses, new exploits. Normally I don't jump on the "hate microsoft/linux fanboy" shit nor the "I just saw the matrix so I believe in saying choice/freedom a lot" shit, but this is where things can get bad. The beauty of the 20 year old bios is that its stable in that it lacks any real features and most people don't use it unless they have to enable bootable CDs, recieving an email in OE won't kill it. Hopefully someone will tell the joe sixpacks of america that this is bad and he wants to buy a computer from a source that doesn't include this. I mean microsoft can't require this to install, can they? My hope is that a big stink will be created and a company like dell will bitch and use another bios. Or apple could use this and take some converts. Or every slashdotter's wet dream will come true and everyone's grandmother will be recompiling kernels.
  • by t0ny (590331) on Tuesday December 30, 2003 @11:32AM (#7835141)
    So in other words, since its not specifically good for Linux it shouldnt be done? Everybody needs to understand a few things about PCs and the BIOS as well-

    This stuff runs essentially the same as it did in the 80s. Sure, it uses more memory, bigger hard drives, etc, but its all just built from the same thing. Which leads into #2-

    The solutions which were created to deal with things (such as the BIOS) were only intended, by their creators, to be temporary solutions until somebody designed something better. However, the IBM PC became a standard, and everything since then been built upon that foundation.

    So, for the first time in decades, people are looking at the PC and trying to make it better. Why cant we have computers which boot up in seconds, rather than minutes? Why cant we have power saving which actually works? Those features, and many more, will only be possible with a redesign. The old way of doing things carries too much baggage.

    Its sad, because I had always thought computer people always look for the best way to do things. Unfortunately, computer people are just like everyone else, and all too willing to accept the status quo.

  • What lock-in? (Score:3, Interesting)

    by Valdrax (32670) on Tuesday December 30, 2003 @11:35AM (#7835160)
    Someone above has posted a link from Kernel Traffic which explains quite nicely the fact that Linux already has early support for EFI as part of the IA-64 port (which has been backported to IA-32) and has a nice lenghty explanation from Intel about why they made certain design decisions that they did.

    It all ends with a statement by an Intel person that none of what they're pushing as a standard is patented so that it can be as openly and widely adopted as possible. I'm pretty sure that no vendor lock-in will happen here.
  • by PygmySurfer (442860) on Tuesday December 30, 2003 @11:37AM (#7835170)
    Imagine the horror of having to patch a system by swapping out chips. I think I recall some old time viruses that basically screwed up the bios royally, and which were not easily cleanable, to one degree or another.

    Haven't BIOSes been using Flash memory for years now? Couldn't we just download the latest BIOS, and flash the chip? You know, kinda like we do now to fix bugs/add features.
  • by cybermancer (99420) on Tuesday December 30, 2003 @11:54AM (#7835317) Homepage
    . . .but unless I need this DRM'ed crap to get on the internet. . .

    It is only a matter of time before there are two Internet's co-existing. One that is only accessible to those with DRM, and one that is only accessible to everyone. Eventually with time (unless the tides are turned) all the commercial content will migrate to the DRM network, and DRM enabled PC's will no longer be able to access the non DRM one because it is too "Dangerous".

    If lobbiests get their way then it will soon be illegal to provide content (web page, music, software, etc.) not controlled by DRM. Anyone who wants true freedom will need two PC's in their home, one with DRM, one without. And they will be even more incompatible then PC and MAC or Windows and Linux.
  • by fingusernames (695699) on Tuesday December 30, 2003 @11:58AM (#7835356) Homepage
    Why doesn't the computer boot in seconds? Well, my latest Windows PC gets past the BIOS in a couple seconds. It then starts loading the OS. With Windows, the hard drive grinds and grinds and grinds, and then grinds some more, as it loads who knows what. It takes much, much longer to get Windows into memory and operating than the BIOS. Seems Windows might be the candidate for the complete re-write if fast bootup is your goal.

    What I would like to see in the default standard PC BIOS is remote control via ethernet. Be able to reboot a machine remotely and get console access from the moment the machine powers up, without an add-in board.

    Larry
  • by Anonymous Coward on Tuesday December 30, 2003 @12:02PM (#7835387)
    We do look for the best way. Unfortunately, be certain that this approach from M$ will be proprietary and linked *directly* into their old "Palladium" project, designed to take control of "licensing" hardware in order to operate.

    This is critical to companies concerned about copying CD's and DVD's with desktop hardware, but also provides BIOS-restricted rather than OS-restricted control for using any hardware. How.... "surprising" if such control is used to prevent open source tools from even being able to boot the hard drive.

    M$ and Intel will resist, fiercely, the ability to load your own tools in EFI.
  • by PalmKiller (174161) on Tuesday December 30, 2003 @12:26PM (#7835605) Homepage
    Nothing to fear I think, Remember the bootloader for alpha processors that microsoft required to be flashed to boot NT? Basically it was nt bootloader instead of the alpha console. Well it was supposed to only boot windows, but with some engineering it booted milo, which booted linux. this mostly stemed from alpha having a console that set up hardware for booting unix style, someone also made a bootloader for linux for that firmware, I think it was called aboot or something like that for the console boot. Actually alpha had a much cooler way of handling hardware than a bios, it could actually set up and control hardware in intesting ways, so I am all for it if this is what they are going for.
  • by Tim C (15259) on Tuesday December 30, 2003 @12:26PM (#7835606)
    remember the P4 CPU ID?

    Yes, I remember the P3's CPU ID. I remember turning it off in the BIOS on first boot of my (then) brand new P3 700, and I remember it staying off and having absolutely no effect on me at all.

    I also remember not reading about any invasions of privacy involving the CPU ID. To be honest, I'm surprised that you mentioned it, given that nothing much really came of it. Sure, perhaps they had designs on something nefarious or underhand - but it came to nothing. That may well be a good indication of what will happen if they try anything similar this time round...
  • by AKAImBatman (238306) <akaimbatman@gmai[ ]om ['l.c' in gap]> on Tuesday December 30, 2003 @12:44PM (#7835775) Homepage Journal
    My apologies. Unfortunately, your post came across a bit trollish, so I responded as such.

    I liked Sun's pre-boot shell just fine...but I haven't had much use for it in the past decade. I welcome more sophisticated pre-boot console systems, but I do NOT welcome entry points for hackers and virus writers to screw with my system before my OS has a chance to get started.

    In the many years that OpenBoot/OpenFirmware has existed, it has generally proved itself to be secure except in situations of physical compromise (a damning situation anyway). This makes it a far more ideal choice than a new firmware standard that has not yet withstood a trial by fire.

    Question is, what's the OF crowd doing about automated registration (and qualification against "certified" model/versions) of DMA and PCI bus device controllers? If I decide, at some point, that I no longer "trust" Intel intelligent network interface cards (because their firmware isn't using a GPL-friendly version of S/WAN in it's integrated IPSEC implementation), what will OF do to tell me / warn me that a "tainted" device has been added to a system I'm trying to trust (ASP hosted Apache server, or whatever)?

    I'm not really sure this is a necessary feature. You (as the admin of your box) have made a decision to add a piece of hardware. Relying on the firmware to warn you that you may be crossing the barrier of your ideals, is out of scope for such technology.

    Most "driver signing" to date, has been implemented by Microsoft as an attempt to improve their image. With computers other than PCs, users would never dream of installing hardware that wasn't first approved by the vendor. Microsoft however, is a software only company and thus by default has very little control over hardware. So Microsoft set to the task of adding signed drivers to their OS to prevent non-Microsoft hardware from being installed.

    Now I won't argue that OpenFirmware on Intel wouldn't run into the same problem as Microsoft. However, it would be relatively simple to add signature support to an Intel implementation to accomplish the same goal as Microsoft.

  • by Anonymous Coward on Tuesday December 30, 2003 @01:16PM (#7836134)
    M$ could have another agenda besides the age-old Linux conspiracy. If a new BIOS spec is hashed out, it could be an opportunity for Bill to force users to upgrade to the next version of Windows. If you upgrade your motherboard or buy a new PC, you will once again have to pony up for the M$ tax.
  • by Anonymous Coward on Tuesday December 30, 2003 @01:42PM (#7836459)
    EFI will never REQUIRE a signed OS to operate.

    CONTENT will REQUIRE signed OS.

    New versions of Quicktime, Real Media, WMA... will need a signed OS to allow it to be played. Just like any XBOX game looks for a signed OS. You want to play that new trailer for The Hobbit, well that's copyrighted content and quicktime is forced to make it a signed media file (if they want to continue to host trailers for the MPAA).

    Don't get me wrong this isn't a good thing, but there is a difference between not being allowed to run Linux and not allowed to run DRM content.

    Your copy of Linux will need to be a SIGNED "Trustworthy" client to run applications that require it. You can bet this won't be an open source part of your kernel.

    This is the catch that will keep Intel and Microsoft from looking like monopoly's outright. Makes Linux users look like paranoids. Which we are for good reason, but lets see it for what it is.

    On longhorn you will get a popup window that says this software is not "trustworthy" do you want to run it? If it's a virus that will destroy the system MS will say you accepted un-trustworthy software so it's not our fault there was a security hole. Good scapegoat eh? Computing will not be any safer because people will have tons of unsigned software anyway. Face it end-users don't read warnings about spyware now, they won't in the future.

    It all depends on how well Longhorn is accepted.

    BTW, the new Phoenix "core" bios has a version of TCPA/DRM as well. Evidently their team is scared of a "non-trustworthy" solution. Longhorn would in essence make any non-efi bios "unsigned", "untrustworthy" the same as linux, bsd... Just because it's not Intel making the bios doesn't make it your friend.

  • by Abraxis (180472) on Tuesday December 30, 2003 @01:45PM (#7836494)
    Without mentioning my previous employer by name, I spent most of 2003 working extensively with EFI.

    I really don't think it's the terror people are making it out to be, despite MS's involvement.

    EFI is essentially taking the higher level driver stuff and pushing it down into the system firmware. I think this could have cool benefits for Linux (and any other operating system, or anybody coding an OS).

    For example:
    If EFI becomes widespread, in theory you may never have to worry about installing a hardware driver again (for Linux or any other OS). EFI has an interpreter for EBC (EFI byte code). EBC drivers can be stored in the firmware of a pci/pcix card. When the system boots EFI interprets the EBC driver on the card, and presto! the new hardware is working on whatever EFI platform you are running it on. And since EFI provides a standard way to interface the hardware, the OS could operate without the need for further device drivers.

    By the way, if you want to know more about EFI, you can score the specs here:
    http://www.intel.com/technology/efi/agree.h tm
  • EFI is useful (Score:5, Interesting)

    by dlapine (131282) <dlapine @ n c s a .uiuc.edu> on Tuesday December 30, 2003 @01:59PM (#7836678) Homepage
    If you run ia64 (all 5 of us :) ) you already run EFI. For some of you out there who may not have actually seen EFI in action, I'd thought I provide some small examples of what it looks like.

    EFI does a running check of the hardware that it understands, drivers for which were provided by the Motherboard maker.

    Here's a snapshot of the EFI SCAN on my INTEL Tiger4 system.:

    EFI version 1.10 [14.61] Build flags: EFI64 Running on Intel(R) Itanium(R) 2 processor EFI_DEBUG
    EFI IA-64 SDV/FDK (BIOS CallBacks) [Wed Jan 1 23:33:30 2003] - INTEL
    Cache Enabled. This image MainEntry is at address 000000007FA02000
    Searching for EFI 1.1 SCSI driver....
    Scsi(Pun0,Lun0) MAXTOR ATLASU320_18_SCAB120 (320 MBytes/sec)
    Scsi(Pun1,Lun0) MAXTOR ATLASU320_73_SCAB120 (320 MBytes/sec)
    Scsi(Pun2,Lun0) MAXTOR ATLASU320_73_SCAB120 (320 MBytes/sec)
    Scsi(Pun6,Lun0) ESG-SHV
    Invoking PxeDhcp4 protocol to obtain IP address.

    At the end of this, I get a menu that I can manually select from (cursor up and down), or let it automatically try the options(which can be modified to suit the user's needs). Here's a snapsnot:

    EFI Boot Manager ver 1.10 [14.61]

    Please select a boot option

    Network Boot/Pci(1|0|0)/Mac(0007E9D8147A)
    Linux
    Floppy/Pci(1F|1)/Ata(Primary,Slave)
    CD/DVD ROM/Pci(1F|1)/Ata(Primary,Master)
    EFI Shell [Built-in]
    Boot option maintenance menu

    Use ^ and v to change option(s). Use Enter to select an option

    As you can see, EFI has detected the network card, a bootable linux partition, the floppy (LS240 in this case), and the cdrom drive. Anything you can detect, you can boot off from.

    The EFI shell option brings you into a shell. Once in the shell, you can easily switch to another filesystem by executing a changefilesystem command, similar to msdos:

    fs1:

    The shell prompt (for filesystem 0, which is the first filesystem EFI finds, whether its on a floppy, a cdrom, a harddrive, usb key, whatever)

    fs0:\>

    The shell looks like a dos shell, but runs commands that the motherboard manufacturer includes, such as "edit" "ls" "cat" "cp" "mount" and others. These commands live in ROM.

    EFI understands the FAT32 filesystem and can perform operations on files living there including editing. EFI can access any FAT32 on any device EFI has a built-in driver for, and any device that the user can obtain an EFI driver for.

    Another nice feature is that you can create a partition on the disk that efi will use to hold more commands, or updated commands, or drivers for newer hardware. These extra commands when then be available to you at boot time.

    To the user, EFI looks almost like an built-in mini OS that understands enough of the hardware to give you several boot options, as well as the ability to manipulate files on the devices it sees.

    I've seen no evidence of DRM support, or OS lock-in, but that certainly doesn't rule out the possibility. The thing is, EFI is enough of a standard that the user might have the possibility of replacing the stock EFI with some other version to meet their personal needs. This would certainly put us ahead of where we are with current vendor lockin on motherboard bios.

  • by Tackhead (54550) on Tuesday December 30, 2003 @02:51PM (#7837269)
    > I wouldn't risk moving a chip into a motherboard that is already up and running. I'd be worried about damaging that motherboard and ending up with two dead systems.

    If the OS isn't using BIOS, this is actually safe, with two caveats:

    1) The OS shouldn't be making BIOS calls. Last thing you want is to be in the middle of a hard drive write operation when you yank the chip. (This risk is negligible for modern OSes)

    2) Use a proper PLCC extractor for the chip. Shorting out contacts or breaking the socket with a screwdriver is bad. Pulling the chip properly is safe. You're just cutting/restoring power to the voltage, ground, and signal leads of the chip within milliseconds of each other -- the same way you are every time you power the machine up or down.

    For the record, yes, YMMV, but yes, I've done this, and yes, it worked. (I was an I-Opener h4x0r; this was an PC masquerading as an embedded system that lacked a floppy, and for which later versions of the BIOS wouldn't boot from a hard drive. The "hot flash" was needed under those circumstances - boot a machine with a hard drive and a "good" BIOS, remove "good" chip while system powered up. Insert "bad" BIOS chip extracted from a nonbootable unit into empty socket of powered-up "good" machine. Reflash "bad" BIOS chip with data extracted from "good" BIOS chip. Power down. Insert "good" chip into your machine. Insert reflashed chip into formerly-nonbootable machine.)

    I wouldn't recommend it as standard procedure, but if you don't have an EPROM/EEPROM burner, hot-swapping BIOS chips between live machines is a viable field expedient.

  • Re:Of course... (Score:3, Interesting)

    by Alsee (515537) on Wednesday December 31, 2003 @12:06AM (#7842471) Homepage
    but then SB can just as well tell their Taiwan factory to produce two versions

    Nope.

    The way Trusted Computing works is that it checks for a cryptographic signature. If you don't have that signature then that software/hardware won't work at all in Trusted mode. You can only get that signature from the group holding the Root private key. They will simply refuse to give you a signature unless you sign 42 million contracts.

    If you ever do make a non-restricted version that can undetectably pass for the "secure version" then the first thing that do is throw your key on a revokation list and all of the hardware/software linked to your key that you've ever produced instantly drops dead in Trusted mode. The second thing they do is sue you for violating the 42 millions contracts you signed.

    It is specificlly done in that order - if you release something that can break the DRM Trust system that is an "Emergency Response Situation". Their first priority is to is damage control and to seal the breach. They don't care if they cause 5 million computers to drop dead so long as the breach is sealed. They can sue you at leisure.

    So no, it will be impossible to import a non-restricted version that will work in Trusted mode. If it doesn't enforce DRM then it will not work in Trusted mode.

    -

For every bloke who makes his mark, there's half a dozen waiting to rub it out. -- Andy Capp

Working...