Writing an End to the Bio of BIOS? 511
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."
"Before loading your operating system" (Score:5, Interesting)
can interact with EFI on a serial console? (Score:5, Interesting)
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)
Why? (Score:5, Interesting)
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)
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.
Palladium and trusted computing (Score:5, Interesting)
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.
A change is really needed (Score:5, Interesting)
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)
Re:Palladium and trusted computing (Score:2, Interesting)
"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.
Intel would never adopt OF (Score:5, Interesting)
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].
Re:What about AMD and Linux (Score:2, Interesting)
Now we'll be patching our bios' as much as windows (Score:1, Interesting)
No progress for ANYBODY!!!! (Score:5, Interesting)
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)
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.
Re:Coming: The Year of the Infected Bios (Score:2, Interesting)
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.
Re:Palladium and trusted computing (Score:2, Interesting)
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.
Re:No progress for ANYBODY!!!! (Score:3, Interesting)
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
Re:No progress for ANYBODY!!!! (Score:1, Interesting)
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.
Sounds like something alphas had way back when (Score:2, Interesting)
Re:Palladium and trusted computing (Score:3, Interesting)
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...
Re:OF is based on Forth? (Score:3, Interesting)
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.
Re:Well if Microsoft's involved.... (Score:1, Interesting)
Re:Palladium and trusted computing (Score:1, Interesting)
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.
Good things about EFI... (Score:2, Interesting)
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.
EFI is useful (Score:5, Interesting)
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.
Re:How did you do that? (Score:4, Interesting)
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)
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.
-