Greetings,
Mike Shields here. I am new to the list and to LinuxBIOS in general. I have searched the list archives and have read Adam Agnew's (et al) paper on booting Win2K on top of the stackable Open Source BIOS, as well as several other papers by William Arbaugh and coauthors on secure booting and secure BIOS.
I am a consultant for SPAWAR (part of the US Navy) working on a project to make USN computers running windows more secure. I have been asked to give a short presentation to some SPAWAR and FNMOC people on June 29th as part of a project conference. The points I need to cover are the differences between current BIOS and LinuxBIOS and the advantages of the latter. We are trying to convince Dell (SPAWAR has a huge contract with Dell to supply computers to the navy) to give us the information to port LinuxBIOS to their systems. One misconception I must deal with is that many people think Windows won't load over LinuxBIOS (I have Adam's paper showing otherwise).
I know very little about LinuxBIOS other than what I have read on www.linuxbios.org, my scans of the archive, and a short paper form Nicholus Andrews at Linux Labs. I was hoping to get some success stories on booting windows on top of LinuxBIOS, or other information I could use in my short presentation.
Thanks, Mike Michael K. Shields, Ph.D. YarCom Inc. 350 S. Center St., Suite 500, Reno, NV 89501-2114 US v:336-783-0054 f:336-217-8227 c:336-407-2190 e:mshields@yarcom.com http://www.yarcom.com
"Mike Shields" mshields@yarcom.com writes:
Greetings,
Mike Shields here. I am new to the list and to LinuxBIOS in general. I have searched the list archives and have read Adam Agnew's (et al) paper on booting Win2K on top of the stackable Open Source BIOS, as well as several other papers by William Arbaugh and coauthors on secure booting and secure BIOS.
I am a consultant for SPAWAR (part of the US Navy) working on a project to make USN computers running windows more secure. I have been asked to give a short presentation to some SPAWAR and FNMOC people on June 29th as part of a project conference. The points I need to cover are the differences between current BIOS and LinuxBIOS and the advantages of the latter. We are trying to convince Dell (SPAWAR has a huge contract with Dell to supply computers to the navy) to give us the information to port LinuxBIOS to their systems. One misconception I must deal with is that many people think Windows won't load over LinuxBIOS (I have Adam's paper showing otherwise).
The simple proof is that ADLO uses the BIOS from bochs simply ported to real hardware, and bochs loads windows regularly.
You will also likely need to work with the cpu and chipset vendors to get the information needed to port LinuxBIOS. Usually motherboard vendors do not get beyond motherboard schematics information wise. Simply because they don't make the chips on the motherboards. At this time I don't have a clue how much overlap you will have with the current work.
If it makes any difference you can use the name freebios as that is an alias of LinuxBIOS, that is not quite so Linux centric :)
I know very little about LinuxBIOS other than what I have read on www.linuxbios.org, my scans of the archive, and a short paper form Nicholus Andrews at Linux Labs. I was hoping to get some success stories on booting windows on top of LinuxBIOS, or other information I could use in my short presentation.
There are a few rough edges with ADLO currently. (For some reason it has some motherboard specific code.) So in doing a production deployment you will be breaking ground.
So some advantages of an open source BIOS. 1) It is open source so you can implement any boot policy you choose, and can implement. 2) LinuxBIOS is open source so you don't have to worry about security through obscurity, the code can be and is peer reviewed. 3) The core of LinuxBIOS is simpler and at a higher level then a traditional BIOS so it is easier to port. Being in C it certainly widens the pool of people who can work on the project. 4) A security implementation in LinuxBIOS would be about security for the user, instead of about ensuring hardware is trusted. 5) As a research/prototype platform you have much more control of what ultimately is going on. 6) LinuxBIOS is the firmware of choice for supercomputers at top secret government labs, so we must be doing something right :) 7) If you were really creative with BIOS level controll you could run a monitor in System Management Mode that could keep an eye on Windows.
I have a very hard time seeing Windows and security as anything but an oxymoron. Not that Linux is much better. The old security study on MULTICs security is fascinating on that subject. I also don't see a major role of the firmware tightening up security. That being said I have no problems with booting Windows from LinuxBIOS.
Eric
Eric W. Biederman wrote:
There are a few rough edges with ADLO currently. (For some reason it has some motherboard specific code.) So in doing a production deployment you will be breaking ground.
The motherboard specific code is to enable and disable the shadowing control when ADLO copies itself and the vbios to RAM. So to do this in a generic manner LB would have to have to provide a payload with a method of doing this.
If you got any ideas I might be able to scratch up some time to implement them. It would be for V1 though I don't do V2 yet.
the idea we toyed with was a generic callback which would enable this specific feature... still it was somewhat tricky given that ADLO sometimes loads itself over the LinuxBIOS
On Mon, 28 Jun 2004, Richard Smith wrote:
Eric W. Biederman wrote:
There are a few rough edges with ADLO currently. (For some reason it has some motherboard specific code.) So in doing a production deployment you will be breaking ground.
The motherboard specific code is to enable and disable the shadowing control when ADLO copies itself and the vbios to RAM. So to do this in a generic manner LB would have to have to provide a payload with a method of doing this.
If you got any ideas I might be able to scratch up some time to implement them. It would be for V1 though I don't do V2 yet.
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Adam Sulmicki adam@cfar.umd.edu writes:
the idea we toyed with was a generic callback which would enable this specific feature... still it was somewhat tricky given that ADLO sometimes loads itself over the LinuxBIOS
For V2 every port I have done has simply left those areas enabled as RAM, which obviates the need for any call backs.
That code is not motherboard specific it is cpu/chipset specific, which is something else entirely.
On Mon, 28 Jun 2004, Richard Smith wrote:
Eric W. Biederman wrote:
There are a few rough edges with ADLO currently. (For some reason it has some motherboard specific code.) So in doing a production deployment you will be breaking ground.
The motherboard specific code is to enable and disable the shadowing control when ADLO copies itself and the vbios to RAM. So to do this in a generic manner LB would have to have to provide a payload with a method of doing this.
What I was thinking of was things like pirq tables. I seem to recall those still being hard coded.
If you got any ideas I might be able to scratch up some time to implement them. It would be for V1 though I don't do V2 yet.
Any significant changes like always leaving the shadow areas enabled, we can easily implement in both v1 and v2. And things like pirq tables can be copied from wherever LinuxBIOS puts them. If it would help we can place pointers to the information in the LinuxBIOS table to make things easier to deal with.
My basic point in all of this is that there were some rough area's but nothing that be overcome with time.
Eric
Eric W. Biederman wrote:
the idea we toyed with was a generic callback which would enable this specific feature... still it was somewhat tricky given that ADLO sometimes loads itself over the LinuxBIOS
For V2 every port I have done has simply left those areas enabled as RAM, which obviates the need for any call backs.
I don't think thats enough. You have to route reads to the bios area and writes to RAM and then when its done route reads back to RAM so ADLO has to mess with some registers.
That code is not motherboard specific it is cpu/chipset specific, which is something else entirely.
Yeah. motherboard was the wrong term. You used it first though. *grin*
Any significant changes like always leaving the shadow areas enabled, we can easily implement in both v1 and v2. And things like pirq tables can be copied from wherever LinuxBIOS puts them. If it would help we can place pointers to the information in the LinuxBIOS table to make things easier to deal with.
pointers to code that would enable/disable the various functions? or pointers to some data struct that would instruct the code how to do then enable/disable?
They can be pretty different. On the matsonic 7308e motherboard this was a simple out() to a location. With the 440bx chipset this is a config space write.
"Mike Shields" mshields@yarcom.com writes:
I know very little about LinuxBIOS other than what I have read on www.linuxbios.org, my scans of the archive, and a short paper form Nicholus Andrews at Linux Labs. I was hoping to get some success stories on booting windows on top of LinuxBIOS, or other information I could use in my short presentation.
Ok there is one big advantage I forgot to mention.
- Simplicity.
When auditing and verifing code simplicity is a huge plus. And the only really complicated part of LinuxBIOS loading windows would be the code that actually loads windows. All of those ugly BIOS callbacks.
Eric
-
Adam Sulmicki -
ebiederman＠lnxi.com -
Mike Shields -
Richard Smith