Columns D-EFI-nitely Maybe

http://www.bit-tech.net/columns/2007/06/09/definitely_maybe/1

A lot has changed over 26 years - so why hasn't the way our computers boot? Brett Thomas takes a look at motherboards, Microsoft and transportation in the future as he questions the continued presence of the BIOS.

 

The F1-del key dance made me smile, i do that too

Microsoft really need to start this thing off, once os support is in manufacturers can start experiementing. They wont try if there is no market.

 

The BIOS is actually deceptively easy to replace, costs about £2 for a new chip (+shipping to around £5) it normally comes pre-flashed and then all you have to do is use a toothpick to remove the old one and drop the new one in, just like a CPU.

Modern enthusiast motherboards use a CMOS reset button or have a hidden key combination (IIRC on an old ASUS board I had in the 90's is was to hold del when you press the power on), the same way that Windows installer has hidden advanced options to allow you to install on a faulty BIOS.

Yes, EFI looks a lot nicer and probably works easier, but with added complexity comes a higher risk of failure. How many motherboards that aren't overclocked actually have dead BIOS chips? Not knowing the actual numbers I'm willing to bet the answer is "Not a lot"

 

I don't like EFI because it seems like an excuse to thrust TPM down our throats and if you can actually use a BIOS is just a waste of resources.

As for high failure rate... only when your doing things it wasn't designed for. Booting on unstable settings (overclocking) and flashing it while running.

Anyway if you don't like the modern bios try one on a genuine old computer like a 1992 compaq.. for one of those you need to complie a bios boot floppy which has the GUI and software to change perameteres in. Then you press ctl+f10 to get into the bios... which looks very different to modern ones and if you make a mistake the CMOS reset is removing the battry and waiting overnight! :O

 

This article was great. I haven't even thought about all of this before!

For example, I remember some Nforce4 boards that wouldn't sometimes recognize some Maxtor drives at bootup, unless you reseted again. To solve this you needed to update the hdds firmware, which you couldn't do with the on-board SATA controller on the MB

Hopefully, if this technology spreads, all stupid problems like that one can be solved with a breeze!

 

Hmm, increased boot times anyone?? And wasnt there another try into a new BIOS? I seem to have forgotten the link but is somewhere on Bit.

 

"roads? where were going we dont need roads"

sorry had to add that....

i feel this sis something that would definitely be even more useful tied in with flash boot sectors on the HDs, and further down comeplete flash based drives. even now it seems like the BIOS takes longer then my OS to load. i think efficiency is something that is getting left behind. im not saying power efficiency but time. especially in software and certain OSs. i feel the same way about the BIOS as i do the windows registry. i think its time for a change in a few areas in computing.

 

I can't wait until EFI, because I believe that it's not programmed in Assemble but rather C. Therefore, we won't have to deal with buggy BIOS' anymore .

 

Yes, because programmers don't make mistakes when programming in C...

It's quite easy to see both sides of the story - MS & motherboard manufacturers don't want to jump because of the risks and costs involved (and the fact that MS will have to support both BIOS & EFI within the same OS), end-users want EFI now because of the increase in ease of use.

 

Assembler is wonderfull stuff for me its far easier to understand than higher level languages like c++ and especially when programming things like micros the differance in performance allows you to do things you would never be able to do in C.

 

Assembler rocks, but it is time to update to something new and better.... and the "In the future, who needs roads?" gave me some flashbacks of "back to the future"

 

I've tried laerning both C and Assembler, and for me I found Assembler a lot more fun and interesting (and also easier to understand). I eventyually gave up (of course), but I'd be interested if some modern tools came out for it.

 

love it

 

darn, you beat me to the obligatory BTTF quote


ahh well, i think EFI is a nice idea but it does just add alot of complexity to the motherboard and to be honest it sounds alot like giving some with multiple organ failure a tubi-grip. its true that the BIOS is ancient but instead of giving it a zimmer frame and helping it limp along would it not be more appropirate to come up with a system that incorpates the BIOS and EFI functionality in a more efficient package because it is true that the entire POST proceedure and the boot-up can take longer than the OS loading

 

If you have a fairly recent Intel mainboard, there is a chance it will have EFI on it. If you have an Intel server, the odds go up greatly, so it is in a few more places than you think.

This is going to be a long post, but EFI is not a simple topic. I want to present some of the technical details here, and hopefully present a better understanding of what it is.


Here is a quick comment concerning BIOS and EFI based on what I know.
Assembly presents it's own challenges. With BIOS, the first is, how to you write a program that has absolutely no main memory, and works withing the 16 bit instructions rules? Then there are lots of other issues to consider. Take graphics. The only thing there is a hardware spec on is VGA. There is VESA BIOS for some better video modes, but those methods tend to be slow and unwieldy. If BIOS were to use there higher resolution modes, it would need register level information from the graphics chip makers. This is not info they are handing out, and with them all being different, the BIOS would have to handle all possibilities.

USB is another area that has a lot of problems. The USB host controller is a fairly dumb piece of silicon in most PCs, it can't do anything on its own. It needs the CPU to take the data received from its buffers to process very shortly after it becomes available, and it needs the CPU to fill its buffers to transmit. All that magical USB stuff like support for USB mass storage devices is done by the CPU.
We have access to USB devices because of some trickery using interrupt 13h that makes legacy operating systems think they are talking to any other disk. But this also means features like hot plugging are unreliable at best.
Then there is all the legacy hardware that really needs to be on the system for BIOS to really work correctly in its environment. Legacy free PCs are actually incredibly hard to implement.
How does EFI deal with these problems?

Disclaimer:
Unless I'm talking about a specific spec, I'll simply call the tech EFI. I hope this doesn't cause too much confusion. I'm also no expert on the entire spec. This is from off the top of my head and I am human so there are likely to be mistakes in here. There are things I know better than others, but I think I can sufficiently field some comments and concerns. You have been warned

Memory
The first problem with any PC is that you are not guaranteed to have any memory. You do have x86 registers, but there are limits to those. The first goal of any PC firmware is to get memory. With BIOS, this means setting of the CPU bus, configuring the northbridge, and other hardware tasks to get out to main system memory. This is a lot of assembly code (like around 64K of it). A main goal of EFI is to use C, and C needs a stack. On the current PCs running EFI, we get stack by using the CPU cache in the current implementations.

But the memory woes don't end there. BIOS only gets a limited bit of memory to work with. This has been extended over the years, but the limits are still a problem. Originally, the BIOS had the F000 segment, the BIOS data area (much of which was already speced by IBM) and the interrupt vector table. It is important to note that the BIOS runs in 16 bit real mode and is limited to 1M or memory access without some tricks.
Later, more memory was put in use such as the e000 segment if needed, and a system was created called the extended BIOS data area. But there was still a need for more memory. So BIOS employed a trick known as flat mode, or big real mode. Eventually, a standard was written called the post memory manager to formalize the use of this for things other than BIOS. Finally, BIOS has something called the system management interrupt (SMI) which is a bit complicated, but while servicing an SMI, the system is actually in 32 bit protected mode allowing a full 4 gig of memory for data and code. And as we keep asking the BIOS to do more, it keeps needing more memory, but can't leave much of itself behind. If you every wanted to know what memory is being used by your BIOS, you can check the "e820 table" using int 15h function e820h under DOS. Sorry, I wasn't able to find a program to link to here.

EFI takes over the the memory management duties in a more robust fashion and it runs in 32 or 64 bit modes (varies depending on what the platform supports). None of the memory locations are fixed either so EFI can 'live' anywhere in the system removing ties to a specific memory model. Consider that EFI runs both Itanium and x86 systems. And we are not just talking Intel, a demo was done showing EFI on an AMD platform too. (the original link for that story is dead, I don't know how much longer that one will last). The running theme here is to abstract the hardware through software.

EFI drivers
I'll take my favorite example of video. Much like OpenGL, DirectDraw, and other graphics APIs don't care about the hardware underneath because graphics chipset manufacturer provides a layer of abstraction to create a software interface to programs, EFI has something similar.
In the EFI 1.10 spec, this was called the UGA (universal graphics adaptor) protocol, in UEFI 2.1, it is the GOP (graphics output protocol) in case anyone cares to go look them up.
In EFI we have these things called drivers and protocols. They work a lot like COMM. When the core loads an EFI driver, that driver will register what is called a protocol with the core. This is really nothing more than a structure with a bunch of function pointers and potentially some data, it looks a lot like a C++ object with all the functions visualized. (To repeat a quote I heard, EFI uses "C on crack" )
With UGA and GOP, this means that we can do all sorts of things with video that was simply impossible before. If you look back on on the IDF coverage, you can see a graphical setup utility. While an extreme example, it does demonstrate the power available once more hardware makers start supplying EFI drivers.

Quite a bit of the EFI spec is defining these protocols. So all a hardware maker has to do is present this interface to the system firmware. And, as long as the driver conforms to the EFI driver model, the people putting together the firmware for a board don't even need the source, they can get a binary from the company that made the hardware.

To rant for a moment, at least a portion of mainboard failures can be attributed to manufacturers tweaking their boards to look better on reviews. They are running the chips out of spec and the chance of failure suddenly becomes significantly higher than zero.
They may be tweaking registers that are marked as reserved in data sheets. They reverse engineer this based on a lump of very cryptic assembly code provided to initialize the chip. But the information is not complete so tweaking these things is a bit of a gamble, one they may make the user take without permission. This is also one source of cryptic names, especially considering the small teams doing the reverse engineering, and the high percentage of manufacturers based in Taiwan. The name may have made perfect sense to the engineer, it may have even made sense to someone who speaks the engineer's native tongue. But without a dedicated translator, the subsequent translation can be hard to fathom.
(end rant)

Intel decided the fix was to hide things better (a common attitude in the hardware industry as opposed to better disclosure). If that piece of assembly code could instead be delivered as an EFI binary conforming to the EFI driver model, then the firmware writers don't need to know anything beyond the basic data to use a driver. Since it is written in C, it is theoretically easier to maintain (assuming they are following good coding practices).

Using EFI drivers to do stuff
There is a whole lot other things EFI can do as well. Take the example of the bluetooth keyboard. To make it work under EFI you would need a driver for the bluetooth controller, then another that sits on top of that controller for a generic bluetooth keyboard driver that presents a SIMPLE_INPUT protocol to use it. Once you have the keyboard driver, you don't have to rewrite that, you can use it over and over. If the bluetooth controllers all conform closely enough together, you could use the same controller's driver as well. This goes beyond code recycling because we define standard, industry wide interfaces.

There are also plenty of other ways to string together drivers to create stacks for useful things. Say you want to run your system remotely. This isn't a problem under an OS, without certain hardware, it is pretty tough to use that same Ethernet connection to manage a system's POST. Most of the time you are running blind, and taking it on faith everything will work. But assume you need to actually manage your settings remotely as well. With BIOS, networking was not a requirement of the first PCs, so the BIOS is not aware of NICs. But under EFI, I can have a NIC driver...and a TCP/IP driver too. I can then have another driver that registers itself as a second UGA or GOP device, and a SIMPLE_IN device. It can then use the IP driver to redirect your console to a remote computer. all sorts of system services can get redirected this way.

Mass Storage
Disk access is another area that sees big changes under EFI. With BIOS, we use int 13h which assumes a hard drive with sectors, cylinders, heads, and tracks. Consider something like flash where such a definition is meaningless. EFI has this covered using the block IO protocol. Now data is just raw blocks, no need to worry about underlying media. LBA addressing is used, and the device specifies the block size. To complement the block IO driver, we also have disk IO, partition support and the ability to support file systems, though FAT is the only thing currently present in anything I've encountered outside of the structures and file systems specified for EFI.
But this give EFI the ability to use hard drives for storage and break out of the confines of the flash part. This is not so say the firmware will be jumping off the flash part, just that we can now store data that is impractical to store on the flash part.

EFI Booting
The disk and partition awareness is what leads to better boot device capabilities. They don't help with 'legacy' (non EFI) devices much because of the constraints of the BBS spec, but for things that can be launched by their device path, it is really slick. Boots no longer need to be tied to physical hardware or obfuscated by a controller to compensate for BIOS's shortcoming in this area. And, launching an EFI option no longer nees to be the point of no return. One feature is the idea that if an OS load fails, it can return to the BIOS to run diagnostics, or try a different OS. But the OS needs to support this, and currently, only the EFI shell can return you to setup on the platforms I've been able to work with.

EFI based Applications
If you are lucky enough to get your hands on an Intel server board, such as the one in the multi core sever article here on Bit (is that still around?), boot to the [EFI Shell] option and start playing around. If you grab the toolkit from tianocore.org, you can get a few applications to play with. Don't do this on a mission critical system though, not all of these play nice together. This is simply a reflection of the work in progress status of EFI though. Most of these were written purely as demonstrations, not as products.
Take a moment to consider the idea of applications without an OS on the computer. It is important to note that EFI is not intended as an OS, but the power there does really blur the line. Some important things consider though is that EFI is event driven and timing is not guaranteed so it is not suitable as a real time OS. It also has no multi threading support, everything runs on once CPU, and the 'multitasking' that is present is very, very spartan.

EFI Services
EFI does away with the interrupt vector table opting instead for a table of services provided by EFI. This table can be anywhere in memory so it doesn't limit the implementation. This table provides the functions needed for console I/O as well as containing the location of two ither tables, the boot services, and runtime services table. The runtime services table contains services that are meant through the cycle of boot, to OS, to shutdown. The boot services table provides a larger set of features, but the services are based on the EFI core being in control. But there is a neat trick that can be done here.
We have all experienced the problem of not having a driver for a piece of hardware. What the OS can do is, during the boot loader, it can use the boot services table to locate EFI drivers and protocols that it could use for itself. It can then relocate these drivers and make use of them during run time with a little bit of work.

TPM & Security
Concerning TPM, if you search for "TPM" or "Trusted" in either the EFI 1.10 or UEFI 2.1 specs, you will find absolutely nothing. What security there is in EFI is to sign drivers and check them for integrity. This is not to say this can't be abused, but the spec is not married to TPM or the idea of locking you out of your system. Because this is C code, using an open API and human being are not perfect, the firmware could now be opened for attack. The idea is to provide a means of making attacking the system firmware hard to do. With disk services, imagine a trojan that buried itself in your firmware and would periodically make sure its files were still infecting your OS, and if not, it restored that on every boot. BIOS is hard to attack because it is so archaic, cryptic, and tied so closely to hardware. The effort just isn't worth it now. But if it became easier to do, like with EFI, what could happen?
And with many manufactures moving away from socketed flash parts, popping the old one out may not be an option much longer (look at the MSI board from the IDF coverage).

EFI Boot Times
Boot times are hard to comment on, as tracking down two boards with one running BIOS, the other EFI and being similar enough to do the comparison on is tough. The issue is further complicated bu the fact that every production system I have seen running EFI is based on the Tiano core. This is not something that was written as a product, it was written as a demonstration so it is not exactly optimized. I don't think EFI will make thing necessarily faster, there is a certain amount of waiting around caused by the system's hardware.

End
Keep in mind EFI is not targeted just at PCs. It's origins on Itanium means it was not designed for traditional x86 PCs from the start. It has potential on a lot of other platforms too. It has the potential to speed development in embedded systems where the boot loader could be pieced together from drivers that are recompiled to run under the target platform's CPU ISA.

I'm sure there are topics I haven't it on, but I'll keep an eye on this thread and see if I can offer any more info as the need comes up.

 

But how does a BIOS that could only be changed by opening the box and changing the 8 little dip switches compare with those of today? I'd say the BIOS has come a long way too. Nonetheless, interesting article.

What could be bad about EFI:
1) How long until we see viruses / worms / trojans in the wild that reside in the firmware? (a quick web search shows that I'm not the first to think of this either)
2) Compatibility: This sounds like it could get way more complex and involved than the current BIOS. It also Might be easier to fix problems but what are the odds that any conflicts are always going to be "the other guy's fault"?
3) Will Creative Labs (for one example) update this as needed? - I doubt it.

What could be great (beyond what was already mentioned):
1) LinuxBIOS

Edit: thanks for all the info Splynncryth, though from what you said it looks like the LinuxBIOS idea won't work great in EFI either

 

Those tools have been around for decades. They're called compilers.

 

Again, the man complains with pin point accuracy.

 

Very good article, presents some real thought provoking issues..then what's been mentioned here in follow up to it do the same again!

I can't help but think it's a nessercery evil...

 

This a big concern of EFI. Because this is C, many attack vectors are now available to the system. At least with BIOS, many memory structures were hard coded and could change from board to board. But with so much being specified and the memory management in EFI, things like buffer overflows can be potential problems. To this end, section 26 of the UEFI 2.1 spec covers the security available for booting, and for EFI drivers. (Sorry for the lack of link to the spec, you need to fill out a form at UEFI.org to download it.)
Nothing is ever foolproof, but this should make it at least a bit inconvenient.

There is so much to say here. This happens much more frequently than you think now. But because all of this is so old, it isn't that hard for a manufacturer to pull 10-15 year old code out of their concurrent version system and recycle it. But this means we still need to support ideas that made sense for computers equipped with ISA buses and 1 meg or RAM or less.
Think of BIOS as linchpin that tries to keep everyone tied to the PC when the various parts of the PC industry try to go their own way. EFI provides a stricter rule book to follow, but it also takes lesions learned by modern operating systems to try and provide a reasonable set of rules for everyone.

Manufacturers are being drug into this kicking and screaming, it goes back to being able to recycle code. Learning EFI is not an easy thing, and not everyone sees value in training them (assuming they have the means to). This is one of the hang ups with MS delivering an EFI aware version of Visa, and my experiences with elilo have been underwhelming. Trying to find an EFI driver that is not a custom solution from a vendor is an exercise in futility at the moment, and trying to find one compiled into EFI byte code is pretty much impossible. But EFI is in the future specs and it won't be too long when in order to be PCI compliant will mean being EFI compliant too.


Concerning Linux BIOS, I don't see anything fundamentally wrong with it, but it does seem to be another 'we wish the BIOS didn't exist' things Microsoft tried to kill BIOS with ACPI and we can see how well that worked.
Also remember that EFI is intended to boot more than just PCs. While it is not quite as simple as recompiling Tiano for IA64, x86, and x86-64 it is still a code base intended to handle all there, and it looks like it won't be too hard to build it to handle a MIPs based system, ARM system, etc. This may be trivial for an OS, but it is huge for a boot loader. Added to this is the idea of EFI byte code drivers. While bus standards such as PCI may be usable across platforms, often the associated hardware is not.

The other issue is that unless something very drastic happens, for Linux BIOS to be complete on a platform, they will need to have their own open CPU architecture, open chip set, etc. There are lots of 'magic bits' that only the hardware makers know and they aren't handing that info out.