LinuxBIOS and Win2K

[Mike Shields]

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:[e-mail] http://www.yarcom.com

"Mike Shields" <mshields(a)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

[Richard Smith]

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.

[Adam Sulmicki]

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(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios

Adam Sulmicki <adam(a)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

[Richard Smith]

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(a)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