[OpenBIOS]: Pros & Cons

[Paananen Osmo]

> Let's start with the benefits of BIOS16:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> G1) It's supported by all PC OSes.
> G2) It's supported by the hardware manufacturers.
> Think of: your VGA card providing its own BIOS, think of your newly bought
> SCSI controller: You plug them in, and at least you (a) see a picture on
> the screen and (b) can boot an operating system from it (of course, you
> need a driver to use it under the operating system as well). 

Can we use any of this code which is in these cards for BIOS16 
support?  It would easen up the memory requirements.

> G4) The BIOS is standalone.
> You don't need any data on a media to boot.

This sounds like an OpenBIOS feature :-)
We could create somekind  interface for adding custom modules.
Some programs might fit directly to same EEPROM with OpenBIOS.  

> So, what's OpenBIOS for (AKA feature list)?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> F1) input/output/intermediate/control device flexibility.
> input device: harddisk, network, parallel port ZIP, ...
> output device: VGA, HGC, serial, network, ...

What is HGC?

> F3) Support for "intelligent devices".
> There's a main difference between devices storing data and devices able to
> compute or interact in any other way. From the BIOS point of view, this
> dynamic way of communication (for example, authentication, remote boot,
> remote administration) and the appropriate way of implementation could be
> a main feature of OpenBIOS. 
> F4) Authentication (user).

This would also open possibilities for user profiles.  Instead of just
returning "user authenticated", the server could say "User ok. Please
boot from network image <server:filename:params>".
It might also be usefull if the authentication could be passed to
the operating system underneath.

> F5) Authentication (boot block).
> This mechanism could be used in other way, too: A non-"intelligent
> device", i.e. the boot block itself (block device), could have to
> authenticate itself TO THE BIOS. I don't know whether one can get this
> bullett-proof (think of the turing machine and the related axiom), but
> the idea is great, I think.

Why limit this to just boot block?  I think that at least the file (kernel)
should be authenticated.
One rather bullet-proof method could be using md5 checksums stored in NVRAM.
checksum matches -> boot loader will be allowed to continue.

This would enable one to boot from insecure media (like floppy disk) in 
a public area and still be rather secure.  It would also be usable when 
booting from net.

> F6) Compression. 
> Not a main detail, but interesting in any way.

Might be usable when booting from serial line :-)

> F7) Encryption.
> A main topic as security becomes relevant more and more. Of course,
> related to (F4) and (F5). Needed for any media which can be harmed by
> someone and for any media where the transmission of data can be (a)
> listened to and (b) modified (or even faked).

Not  true with b) since it's possible to detect modifications using 
authentication.

> F8) Flexible and hierarchically selectable boot device selection.
> A typical IDE boot control file could look like:
> -----------------
> Boot:=PCI(0,3):ISA:Legacy_IDE(0,UDMA):Partition(1):BootLoader(Linux_OpenBIOS)
> -----------------

Could you explain this format a bit?


It would be nice to be able to pass parameteres to boot loader. Boot loader
would then pass them to the kernel which is beeing loaded.

If we want to replace entire boot loader (like LILO) then we would need a way
to boot from different files.  This might be possible to implement without 
including file system support in BIOS.  

It could be done using utility which would run under the operating system.
The utility would store the starting point and the length of the boot image
(kernel) in NVRAM.  


Sun's OpenBoot has some neat features. One of them is dev-aliases.

Here is an example:

boot /iommu at f,e0000000/sbus at f,e0001000/espdma at f,4000/esp at f,80000/sd at 3,0

Quite long, isn't it.  
I'm not certain what t /iommu is, but I think that it
refers to the motherboard itself since as I understand it some sparc
architectures allow multiple motherboards (with 2 or 4 cpu's / board).
Sbus refers to the expansion bus, esp refers to scsi-controller and
sd to scsi disk, @3,0 refers to scsi id 3 and lun 0.

I think that we should think something as configurable as that.

OpenBoot allows this to be written as:

boot /iommu/sbus/espdma/esp/sd at 3,0
and I think that if you have only one disk, you can use command:
boot /iommu/sbus/espdma/esp/sd

You need the longer version only if you happen to have multiple 
SCSI-controllers or SBUS'es etc.  


Since that's quite hard to remember, OpenBoot allows you to define alias
for that device and then you can use commands like
boot disk
boot disk1 
boot net
boot tape

or even the feared:
boot floppy


> In addition, we would have a system control file, like: 
> -----------------
> InputDevice:=PCI(0,2):ISA:Legacy_8042:AT102(german,ISO-8859-1)
> Monitor(my_19_inch_cube):=Table(Monitordata,Samsung_900p)
> OutputDevice:=Duplicate(OutputDevice_2):PCI(0,5):RivaTNT(my_19_inch_cube,text,100,43):TermOut(ISO-8859-1)
> OutputDevice_2:=PCI(0,3):ISA:Legacy_16550(0,9600,8N1):TermOut(US-ASCII)
> -----------------

Aarghh! Yet another place to configure your monitor.  
But you are right, BIOS would seem to be the correct place to do it.
This would allow us to use fixed-frequency monitors more easily, but
it could also create problems.  But to be really useful this information
should be made possible to obtain while running some OS.  

I'm beginning to see that there is some need for bios after the kernel 
has booted.  I can almost see the light :-)
 
> If the EEPROM is large enough, we could implement something
> like a boot device selection browser to help us search for bootable
> devices. Of course, this is just the idea of an idea :-) and will need a
> large BIOS because all relevant modules would have to be in it.

I don't think this to be a problem.  We just need multiple user interfaces,
one basic which is as small as possible and then really fancy for those of us
who have enough EEPROM available.

> But how should OpenBIOS deal with the advantages of BIOS16?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> D2) Support by hardware manufacturers.
> Of course, we could try to be compatible to BIOS16 not only to provide DOS
> etc. to boot, but also to let hardware prividing BIOS16 BIOS to get a
> place in our structure. Of course, this would blow up code and make our
> BIOS like Win9x using both 32bit and legacy BIOS drivers.

I don't think that we should mix bios16 stuff with the rest of the OpenBIOS.
I'd say that bios16 should be as separate as possible from the "real stuff"
so that it wouldn't ruin the design.  I'm not at all certain wether
this kind of separation is possible, so please comment.

> D3) BIOS extensions.
> > Well, They should be possible, I think. More: We could use BIOS chips
> located in VGA or SCSI cards to contain the appropriate OpenBIOS drivers
> (of course, this would make them incompatible to BIOS16) instead of the
> BIOS16 code.

In future all devices will have OpenBIOS drivers in their BIOS chips :-)
Definetly worth supporting.  Perhaps somekind of model for dual support
might be nice so that a device could have both: OpenBIOS code and bios16
code.

> D4) The BIOS is standalone. 
> Of course, this could (and will) be a main problem (and is discussed
> already heavily). Either we try to make it standalone and take the risk of
> having the OpenBIOS not to fit into EEPROM, or we remove more and more
> benefits of OpenBIOS to reach the goal. To have main BIOS functionality on
> harddisk is dangerous in any way. Harddrive defect, new hard drive, virus,
> security, diskless workstations, etc.

I don't think that removing features from OpenBIOS only because we need bios16 
support is an option.  I think that we should make OpenBIOS modular and make 
it _support_ module loading from hd.  Since we already decided (?) to have 
somekind of authentication for bootblock why coudn't we use authentication for
modules as well?

If bios16 would be seperate module, it wouldn't be vital to have it in order
to get the system boot.  It would be required only if the user wishes to
run OS which doesn't support OpenBIOS. 
I wouldn't recommend storing modules in HD.  I think that this is much better 
way than not beeing able to use bios16 at all.

In addition I think that Bios16 might not be needed on older machines since
you can't run w95/nt with them.  More likely old 486's are used as servers
which run linux or some other free unix.

> >For legacy OS's (Dos, Windows) that
> > require a BIOS, the Boot Loader can load a BIOS from the boot device
> > directly into Shadow Ram and execute it as if it where copied from EEPROM
> > to Shadow Ram.
> Thought of that: Then we have a problem using the CMOS for our purposes

Another tought: how much NVRAM we have to store our data? Encryption keys and 
boot loader configuration take some space..

> > A couple of you have mentioned Open Boot. 
> I found something on the SUN server I think. Search there for it. I think
> it's of no use for us at least because the sources are not free.

Even if there is no source to be copied we might want to copy some ideas from 
OpenBoot.  I think that we should compare BIOS/bootloader features used in 
other systems before deciding what to include in OpenBIOS.

Comments, anyone?

-- 
  Osmo Paananen <odie at cs.tut.fi>          http://www.cs.tut.fi/~odie