In-Depth Look At LinuxBIOS
DrSkwid writes "With PhoenixBIOS reading your email because of such inordinate boot up times for Windows and other OSs, it was remarked in #plan9 about our 5s boot times using LinuxBIOS. My friend f2f pasted an article from Linux Journal which looks at the basic structure of LinuxBIOS, the origins of LinuxBIOS and how it evolved to its current state. It also covers the platforms supported and the lessons they have learned about trying to marry a GPL project to some of the lowest-level, most heavily guarded secrets that vendors possess."
Will this have any chance of being taken up by a motherboard manuafacturer by default or is this a aftermarket project ? in which case without being installed by a manufacturer no-one is going to even contemplate wiping their "working" bios for an unknown 3rd party of no significant benefit to them
if it increased boot time significantly, it could be of great benefit--think of a webhosting company that guarantees less than a certain number of minutes of downtime each year. shaving off seconds on each reboot could save them $$$.
Well, for starters if my understanding of eXecute In Place is holding, it's completely different. The ROM chip holds a compressed kernel, that's decompressed on the fly and used to start the system. The only thing this skips is the need to do a startup seek for harddrives, and that whole step of initalizing slow hardware (ie, Hard Disk platters). eXecute In Place is intented to simply run the program natively, ie uncompressed kernel image sitting in ram, so it can just be thrown straight into the processor and executed. The difference is slight, but none-the-less important.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
I think it is really amazing how many people here on Slashdot are just so eager to post comments that they obviously don't even bother to read the actual article.
If some of you people had read the article, for example, you'd notice some important points being made, such as, "From what we can see, the two factors in our success were competition and the creation of a market. Competition gave us a wide variety of choices as to motherboard, chipset and CPU. Once there was a reasonable market, vendors were concerned about being left out."
I don't know about any of you, but I think the creation of an open source "market" is EXACTLY what has enabled the success of open source products like Linux in the first place.
It was also what enabled the success of the Wintel architecture, if you think about it. At the time the original IBM PC was released, it was virtually a foreign idea to IBM--many people at the time were asking the question, "how on EARTH could IBM possibly release a machine based on open specifications and parts with a straight face?" Let us not forget that at the time, IBM desperately needed to get ANY kind of microcomputer on the market ASAP, for fear that Apple and others might get firmly entrenched. Once that thinking took hold, IBM practically had no choice but to hope and pray that their Big Name would keep them at the forefront. As we know, companies like Compaq came along and proved them wrong, and the rest is history.
The point is, I wonder why things like chipsets are still so closely guarded secrets. Can you people imagine what the world would be like if Intel had made the x86 CPUs with a proprietary, closely-guarded SECRET ISA, that you could only program for if you signed an NDA? If Intel had done that, Linux probably wouldn't even exist!!
I sometimes have this feeling Microsoft would do ANYTHING to go back in history and try to get all the laws of our country re-written and the market changed so this kind of all-secret world I speak of could exist.
In the end, the markets for products, be it open OR closed, occur because someone created that market. I think it is high time someone created an "open source" chipset, myself. But that's just me. If you people want all things to be open, stop talking about it and complaining about closed-source, proprietary things, and DO SOMETHING about it.
Fuck grub, this is moving the whole kernel into flash-ram. This is to save the step of having to connect to the hard drive until when it's actually needed to run software, which can be done WHILE the system is booting the kernel, instead of before-hand. And as we know, in the computer world, multitasking is a good way of speeding up things.
;)
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
Heres a picture of linuxbios:
0001001010001000000100101001001000100100100100101
0010101001001000100100000100100101000100100100100
1001000100100100010000001001000100010000100110010
0101001001000100100100100101100100010000001010101
1000100100000100100000100101010010010010001001001
Finally, an admission that the hardware vendors claim of secret interfaces is often just BS:
One of the most common phrases we heard from chip vendors in the first few years was "we'll never tell you that." "That" being CPU information, chipset information, motherboard information or any combination of the three. The designs for these three systems constitute highly guarded secrets. It seems amazing, even now, that vendors are able to let us build a GPLed BIOS that by its nature exposes some of these secrets.
How was it possible for us to get this type of information? Simple, businesses are not charities. If there is no business case for releasing this information to us, they do not do it. If, however, there is a business case, then it happens?sometimes with astonishing speed.
Read that last paragraph again. The hardware vendors basically say "that's a secret" whether it really is or not. Unless you pay them, or show them that they are losing money, they won't even bother deciding if it's really something that has to be kept secret.
I was recently doing some research to get started working with LinuxBIOS. The first thing I have done is to order a BIOS Savior.. This is a little gadget that runs about 15 bucks. It puts a switch on the outside of your case allowing you to switch to an alternate BIOS. With it, you can happily screw up your LinuxBIOS image all you want and still be able to boot your computer from the original BIOS.
Some motherboards have a dual BIOS or similar arrangement; however, there is not always a foolproof way to switch to your backup if the primary BIOS is hosed..
Keep these things in mind if you want to start playing with LinuxBIOS
I read this article a couple months ago when my issue of Linux Journal arrived. I had a couple questions about it then, guess this is a good time to ask them. :)
As I see it, half the point of LinuxBIOS is to provide a fast, open-sourced BIOS for x86 machines. It gets extra cool points for being Linux.
But I have to ask, why not just use OpenFirmware? Or at least, give LinuxBIOS some of the features of OpenFirmware. As far as I know, there is no such thing as OpenFirmware for the x86. It's got lots of neat benefits, like booting your machine off of another one on your network, or debugging a non-bootable machine remotely. Serial console, anyone? It has other benefits as well, that I can't remember; my brain is shot for the week.
For those of you that haven't heard of OpenFirmware, it's basically the "BIOS" on Macs.
How it typically works is you develop a kernel with a small foot print. The LinuxBIOS guys are really sane about things, there is a few lines of assembly which is just about enough code to start running C code. After that the gist of it is C with some assembly macros. There isn't anything too complex, we're talking about outp mostly. There isn't anything too secret here, it's just that booting a PC is not documented really well. Some BIOS vendors have software that does runtime function with system managment interrupts. DRM will be something like that. Supposedly and there have been discussions about it on the LinuxBIOS list, Phoenix and company do some hardware error checking and such and that's why they are so slow but some of the LinuxBIOS folks think that they don't do that and that the code is so complex and has so much legacy that it does a bunch of extra crap that it doesn't need to.
That code does enough to turn on memory, it may do some checking now, when I looked at it last there wasn't a ton of integrity checking code. Light up a few other components, like VGA. Then copy a kernel from flash in to memory (think of it as a slightly tweaked bzImage) At that point you can pretty much jump to the start of the kernel and execute it. The kernel doesn't use BIOS for most device IO so it knows how to spin up drives and light up the rest of the hardware.
Now how we did it and understood the goal of LinuxBIOS to be was we had an initrd that the kernel from flash would load and execute. Said initrd would look at the drives, look at some other variables, authenticate the system, possibly do a fsck on the disks if needed and then locate a kernel on the disk. After locating that kernel it would use kexec, now called fastboot, and replace the kernel in memory. The idea was that we could upgrade kernels on disks without changing flash.
It works very well and has been incredibly reliable. We can get in to kernel space in a few seconds. Subsequently, if it's a settop box type device, it could download a brain from cable or satellite. It could rebuild itself if needed. You could have diagnostic code in there for manufacturing, etc, whatever you want. Pretty much only limited by flash size and memory.
I know that they now and do other things like boot windows and such, at which point LinuxBIOS is potentially a serious threat to Phoenix and company, the BIOS is an expensive piece of the computer.
I've been toying around with some linuxbios type projects. Since disk space is so insanely cheap and disks are so big anymore, you could set aside a backup partition, easily do a really quick backup daily and then weekly do a backup of that to long term media from "BIOS land" regardless of the operating system. Or you could have something like snapshots of your system, maybe a clean install, a configured system, a backup, a different OS or something like that and then all from "BIOS Space" pick them at boot time and have it restore them. Something like that, I have always wanted backup support at the BIOS level.
I see this exactly the way I see modern operating systems boot up. The BIOS goes to some place and reads 512 bytes. Those bytes load up a "real" bootloader. That bootloader loads up some darn thing, which loads up the kernel, which loads up a bunch of device drivers and other software, and after a minute of grinding the disk, you have a system waiting for input. Why all this fuss?
My idea, then, is that instead of having an operating system kernel on your hard drive, it and its bootloader should reside in a really friggen powerful BIOS chip. By powerful I mean that there should be a LOT of flash space and the BIOS itself should be a relatively powerful microprocessor. The software is started immediately upon the powerup of the computer. The BIOS Flash then looks like the root partition; it is mounted just like the hard drives and other devices are. All device drivers are present in the kernel, anyway, and since the BIOS is designed for the computer (by the factory) or configured (by a hacker who puts together his own system), there is nothing to detect or load. Furthermore, all software that starts at startup has a complete image "frozen" in the BIOS Flash, and is copied directly into RAM during the initial stages of startup. Therefore, if you have X, and an entire desktop environment, the entire computer goes from OFF to running X and your desktop software, and whatever else you want for that matter, in almost no time at all. Your monitor would probably take longer to warm up then it would take for your desktop to be ready for input.
This sounds a lot like un-suspending a computer that is in suspend mode, and yes, in effect, it's just like that. You have your system running the way you want it to start up, then you "freeze" it a la VMWare, put it in the BIOS Flash, and when you turn on the computer, the BIOS copies the image directly into RAM, with perhaps a few routines here and there that initialize hardware upon powerup, or set a few values throughout RAM, like time-sensitive things and whatnot... No matter how fast MS makes their OS load, it'll never come close to this kind of performance.
Take it a step further, and each user could have almost an entire operating system setup, as if the computer has multiple personalities from the bootloader up. The BIOS has some routine that lets you log in, and accordingly, selects the image that will get loaded. In this respect, you could completely power down the computer, and come back a week later, turn it on, and immediately it will return to where it was.
This will probably be the case in 10 years or so. (Hey, in the 90's we went from the 386 SX to the Pentium 3. Who knows what the hell will happen by 2015 or so.)
Didn't Microsoft want to do the same thing?
No, what Microsoft has ALREADY done, through pressure on Phoenix BIOS (submitted by yours truly) and on AMI BIOS (and probably every other BIOS maker), has far more sinister overtones.
The purpose of the new Microsoft-enabled BIOSes is to enable a new kind of "trusted" software and files that ARE UNUSABLE if the owner of the machine alters any of the "protected" elements of his computer.
Lets say you write some sort of upgrade for your computer, or you don't like something about how your computer runs and you want to change it (or someone else write such code and you want to install it). Code that changes the BIOS. What the new Trust system does is detect that you changed your computer and any "secure" software and data are unreadable. The music you downloaded will be unusable. The image processing software you had installed can no longer run. The spreadsheet you just bought can not install. Your favorite game can not connect to the server. The new "secure" e-mail Microsoft is advertizing will be unreadable.
But here's the REALLY scary part. Another slashdot story reported Cisco Working to Block Viruses at the Router. What the story missed was the fact that these new Cisco routers are based on Trusted Computing. That don't actually do anything to block viruses. What they can do is use Trusted Computing to verify that you have specific software installed, such as approved anti-virus software and an approved firewall. The way they "fight viruses" is by refusing to permit you an internet connection unless it verifies you are compliant. Well, if you changed your BIOS at all, or if you changed anything else about your computer, then the Trust chip in your computer reports a "failed" response. The router cannot verify that the approved anti-virus software and/or firewall are installed. You are therefore DENIED an internet connection.
The president's Cyber Security advisor gave a speech at an industry conference and he called on ISP's to install these routers and in effect to impose Trusted Computing compliance onto all of their customers as part of the terms of service for internet access.
If you try to change or control your system in any way then none of the new software will run, none of the new files will be readable, and ultimately you may be denied internet access. In effect you would no longer own your computer.
There is only one thing wrong with Trusted Computing - you are FORBIDDEN to know your own key that is secreted inside the Trust chip. When you don't know your own key then other people can turn your computer against you and lock you in or lock you out of anything. If you DID know this key you would be in full control of your computer.
When it comes to Trusted Computing simply demand to know your key. If they refuse to let you know your own key then tell them to go to hell.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.