Writing an End to the Bio of BIOS?
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."
I wonder if this new BIOS replacement will be designed based on the assumption that everybody is running the most current version of Windows.
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 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?
Javascript + Nintendo DSi = DSiCade
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: 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.
In the future, I would want to not be isolated from my friends in the Space Station.
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.
"It is a greater offense to steal men's labor, than their clothes"
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.
"Anything is possible with enough programmers, time and pizza." (Substitute caffeine for time as needed.)
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.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
EFI sucks. Even Linus says so.
:wq
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.
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?
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.
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.
Manipulate the moderator system! Mod someone as "overrated" today.
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.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
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.
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.
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.
Javascript + Nintendo DSi = DSiCade
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.
Without mentioning my previous employer by name, I spent most of 2003 working extensively with EFI.
h tm
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.
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.
The Internet has no garbage collection
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.
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.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.