etherboot-developers — Discussion of developer issues

Re: Re[4]: [Etherboot-developers] RFC: Safe booting concept

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >Problem is that SafeBoot also could make sense when etherboot is
> >loaded from harddisk (floppy even, in some circumstances).
> >I think when I'm so far, I will find a solution for that.
> 
> Which is why you want a conceptual layer in between to separate out how
> the key is fetched, it may not be with the image, e.g. it may be in a
> smart card. But that can come later.

Though if it is a public key it is safe to store it with etherboot,
which is a reasonable assertion.

Eric

Re: Re[4]: [Etherboot-developers] RFC: Safe booting concept

[<ebi...@ln...>]

Anselm Martin Hoffmeister <an...@ho...> writes:

> Hello Ken,
> 
> Saturday, April 26, 2003, 5:06:33 PM, you wrote:
> 
> > Eric already has code in 5.1 that will call the checksum routine on data
> > blocks as they are loaded. You only need to use those hooks.
> 
> I will have a look.

A couple of little nits.

The checksum is calculated just before the image is executed
not as it downloads.

The checksum is not calculated over the entire ELF image
instead it is calculated over the significant parts.
The ELF header
The ElF program header
The ELF PT_LOAD segments.

The note segment (where the checksum is kept) is deliberately
left out of the calculation.

This should help with the signing process as well.

> >>I'm not too sure (yet) how to specify something to be put in an
> >>"unused" portion of ROM, but I will have a look at it.
> >>Having a (lateron #ifdef'ed) call to safeboot_loadpublickey() would be
> >>what you want, right? Perhaps even something like keyboard-interactive
> >>as a fallback-method - I think I will initially only need /rom and
> >>/keyboard support.
> 
> > You should only need to modify the build rules that take a .zimg file to
> > a .zrom file. Maybe makerom can be modified to do the job. That way you
> > can change the key without having to recompile the source. You may need
> > to be able to read the ROM at the mapped address, not sure if this is
> > possible on all NICs.
> 
> Problem is that SafeBoot also could make sense when etherboot is
> loaded from harddisk (floppy even, in some circumstances).
> I think when I'm so far, I will find a solution for that.

One question worth looking into is how is IPsec supposed to work
for key distribution.

> > The motivation is weaker, you want to prevent the wrong clients from
> > running an image, as opposed to preventing the wrong server from
> > providing an image. That is, you indicate by keying the image to the
> > clients whether it's legal for those clients to run it. You could simply
> > not provide the wrong filename to the clients I suppose. I don't think
> > it's something important to have.
> 
> OK, skipping that client key stuff for now.

Yep one piece at a time.

Eric

Re: Re[4]: [Etherboot-developers] RFC: Safe booting concept

[<ke...@us...>]

>Problem is that SafeBoot also could make sense when etherboot is
>loaded from harddisk (floppy even, in some circumstances).
>I think when I'm so far, I will find a solution for that.

Which is why you want a conceptual layer in between to separate out how
the key is fetched, it may not be with the image, e.g. it may be in a
smart card. But that can come later.

Re: [Etherboot-developers] World domination, anyone?

[Marty C. <md...@et...>]

On Saturday, April 26, 2003, at 08:05  AM, Georg Baum wrote:
> Am Freitag, 25. April 2003 00:39 schrieb Timothy Legge:
>> The docs need work, especially the developer manual.  I am documenting
>> the process of porting a Linux driver as I go through the pcnet32 
>> port.
> A good starting point would be src/drivers/net/sis900.txt from Marty.
> Unfortunately it does not apply completely to 5.1 anymore.

Ah, an excuse to write a new driver... Which one... which one...? ;)

Marty

-- 
     Try: http://rom-o-matic.net/ to make Etherboot images instantly.

    Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827;
          Cambridge, MA 02139; USA
   Voice: (617) 491-6935; Fax: (617) 491-7046
   Email: md...@et...
     Web: http://www.etherboot.org/

Re[4]: [Etherboot-developers] RFC: Safe booting concept

[Anselm M. H. <an...@ho...>]

Hello Ken,

Saturday, April 26, 2003, 5:06:33 PM, you wrote:

> Eric already has code in 5.1 that will call the checksum routine on data
> blocks as they are loaded. You only need to use those hooks.

I will have a look.

>>I'm not too sure (yet) how to specify something to be put in an
>>"unused" portion of ROM, but I will have a look at it.
>>Having a (lateron #ifdef'ed) call to safeboot_loadpublickey() would be
>>what you want, right? Perhaps even something like keyboard-interactive
>>as a fallback-method - I think I will initially only need /rom and
>>/keyboard support.

> You should only need to modify the build rules that take a .zimg file to
> a .zrom file. Maybe makerom can be modified to do the job. That way you
> can change the key without having to recompile the source. You may need
> to be able to read the ROM at the mapped address, not sure if this is
> possible on all NICs.

Problem is that SafeBoot also could make sense when etherboot is
loaded from harddisk (floppy even, in some circumstances).
I think when I'm so far, I will find a solution for that.

> The motivation is weaker, you want to prevent the wrong clients from
> running an image, as opposed to preventing the wrong server from
> providing an image. That is, you indicate by keying the image to the
> clients whether it's legal for those clients to run it. You could simply
> not provide the wrong filename to the clients I suppose. I don't think
> it's something important to have.

OK, skipping that client key stuff for now.

Best regards,
 Anselm                            mailto:an...@ho...

Re: Re[2]: [Etherboot-developers] RFC: Safe booting concept

[<ke...@us...>]

>Problem of this is that the data has to be examined not only in
>checksum generation process (which is easy, with MG's md5.c from
>etherboot 5.0), but also more intense. I'll have a look into ELF
>format later.

Eric already has code in 5.1 that will call the checksum routine on data
blocks as they are loaded. You only need to use those hooks.

>I'm not too sure (yet) how to specify something to be put in an
>"unused" portion of ROM, but I will have a look at it.
>Having a (lateron #ifdef'ed) call to safeboot_loadpublickey() would be
>what you want, right? Perhaps even something like keyboard-interactive
>as a fallback-method - I think I will initially only need /rom and
>/keyboard support.

You should only need to modify the build rules that take a .zimg file to
a .zrom file. Maybe makerom can be modified to do the job. That way you
can change the key without having to recompile the source. You may need
to be able to read the ROM at the mapped address, not sure if this is
possible on all NICs.

>> The authentication the other way might be worth thinking about, how to
>> make sure that the appropriate clients are booting the image (not
>> reading, you can't stop clients from TFTPing the image). Perhaps a
>> client key (which might be a group key to reduce the number of distinct
>> keys) might be used to verify a different signed hash in the image. Not
>> sure if this is useful.

The motivation is weaker, you want to prevent the wrong clients from
running an image, as opposed to preventing the wrong server from
providing an image. That is, you indicate by keying the image to the
clients whether it's legal for those clients to run it. You could simply
not provide the wrong filename to the clients I suppose. I don't think
it's something important to have.

Re[2]: [Etherboot-developers] RFC: Safe booting concept

[Anselm M. H. <an...@ho...>]

Hello Ken,

Saturday, April 26, 2003, 4:25:04 PM, you wrote

- the first answer. Had been waiting in front of my monitor :-)

> Sounds reasonable for a first cut. Some comments.

>> - Files in /tftpboot on the server cannot be modified by an attacker

> You don't need to assume this. You only need to assume that it's
> infeasable for the attacker to modify it and yet pass the check.

OK. That's what I though about when finishing the mail (I wrote some
minutes on it, though along and forgot to remove that). Of course,
exchanging files can only break booting, but not safety. Stopping the
ability of people to interrupt booting is no aim of SafeBoot - that
could even be managed by pulling the network cable. So it doesn't
really touch us here, you're right.

> What you call server keys I would call publisher key. Multiple servers,
> sites sharing images etc.

Noticed.

> Rather than sending the signed hash in the DHCP reply, incorporate it in
> the image. That is, all files are signed, including menus. Eric has
> already used ELF note sections to hold a checksum.  You can define
> another type to hold a signed hash. Modifying dhcpd.conf is a hassle,
> you have to restart the server afterwards. One less service to worry
> about. Also no limit on hash length.

Problem of this is that the data has to be examined not only in
checksum generation process (which is easy, with MG's md5.c from
etherboot 5.0), but also more intense. I'll have a look into ELF
format later.
Could just prepending a 128-byte-block to any image (yet on harddisk)
be accepted? This would break compatibility to non-SafeBoot-clients,
but perhaps this would even be reasonable...

> It would be good if you could use existing GPG programs to manage the
> publisher keys, there are already facilities to protect the private keys
> with a passphrase. When building the image with mkelf-linux, the key
> would be unlocked to hash and sign the image in one go.

That was aimed at anyway. I was not yet so far to specify if PGP or
GPG or even openssl-based stuff, but YES, I want this. Good point
anyway, I could have said so right from the beginning.

> There may need to be a way to override the requirement for signed images
> from the client for some purposes, e.g. testing. An option that says ok,
> I will accept the risk of loading and running an unsigned image, because
> I'm servicing the machine.

OK, no problem. I had planned to have an (#ifdef'ed) call to
safeboot_verify(...) after tftp download finishes. In case the cerify
fails, it's at the coder's option (well, anyone of us could change it
as he wants) to have a prompt or just a "cryptography exception fault
[blue screen] - system has been halted" message.

> It would be preferable if the public key were not put in the body of the
> Ethernet code, but rather written into an unused part of the ROM. This
> allows the key in the ROM image to be changed without a recompile. Also
> define a layer of access routines so that other technolgies can be used
> later to provide the key, e.g. smart card, USB dongle, etc.

I'm not too sure (yet) how to specify something to be put in an
"unused" portion of ROM, but I will have a look at it.
Having a (lateron #ifdef'ed) call to safeboot_loadpublickey() would be
what you want, right? Perhaps even something like keyboard-interactive
as a fallback-method - I think I will initially only need /rom and
/keyboard support.

> The authentication the other way might be worth thinking about, how to
> make sure that the appropriate clients are booting the image (not
> reading, you can't stop clients from TFTPing the image). Perhaps a
> client key (which might be a group key to reduce the number of distinct
> keys) might be used to verify a different signed hash in the image. Not
> sure if this is useful.

I don't understand your point. At any time, any client could boot the
image if it's not encrypted. If you don't want that client to boot the
image, just specify another dhcp filename... *ouch*, I see, as I wrote
DHCP shall not be secured. BUT: This could be solved by embedding an
ELF section with allowed MAC addresses (or MAC-prefix/bitmask stuff).
Of course that's only reasonable after SafeBoot is up, but then it
should be kind of kindergarten game to have it. I think that's one of
the ideas I do not plan to implement at the beginning. Perhaps someone
else will later, if there's need for it.

One last thing: Is there anything to notice with using digital
signature stuff? That's *not* cryptography, but sourceforge's hosted
in US and I don't want to be hanged for doing some forbidden crypto
stuff transfer. AFAIK, Germany's more liberal :-\

Thanks for your comments, any more welcome.
I'll let y'all know where I get to.

Best regards,
 Anselm                            mailto:an...@ho...

Re: [Etherboot-developers] RFC: Safe booting concept

[<ke...@us...>]

Sounds reasonable for a first cut. Some comments.

> - Files in /tftpboot on the server cannot be modified by an attacker

You don't need to assume this. You only need to assume that it's
infeasable for the attacker to modify it and yet pass the check.

What you call server keys I would call publisher key. Multiple servers,
sites sharing images etc.

Rather than sending the signed hash in the DHCP reply, incorporate it in
the image. That is, all files are signed, including menus. Eric has
already used ELF note sections to hold a checksum.  You can define
another type to hold a signed hash. Modifying dhcpd.conf is a hassle,
you have to restart the server afterwards. One less service to worry
about. Also no limit on hash length.

It would be good if you could use existing GPG programs to manage the
publisher keys, there are already facilities to protect the private keys
with a passphrase. When building the image with mkelf-linux, the key
would be unlocked to hash and sign the image in one go.

There may need to be a way to override the requirement for signed images
from the client for some purposes, e.g. testing. An option that says ok,
I will accept the risk of loading and running an unsigned image, because
I'm servicing the machine.

It would be preferable if the public key were not put in the body of the
Ethernet code, but rather written into an unused part of the ROM. This
allows the key in the ROM image to be changed without a recompile. Also
define a layer of access routines so that other technolgies can be used
later to provide the key, e.g. smart card, USB dongle, etc.

The authentication the other way might be worth thinking about, how to
make sure that the appropriate clients are booting the image (not
reading, you can't stop clients from TFTPing the image). Perhaps a
client key (which might be a group key to reduce the number of distinct
keys) might be used to verify a different signed hash in the image. Not
sure if this is useful.

Re: [Etherboot-developers] World domination, anyone?

[Georg B. <gb...@us...>]

Am Freitag, 25. April 2003 00:39 schrieb Timothy Legge:
> The docs need work, especially the developer manual.  I am documenting
> the process of porting a Linux driver as I go through the pcnet32 port.

A good starting point would be src/drivers/net/sis900.txt from Marty. 
Unfortunately it does not apply completely to 5.1 anymore.


Georg

[Etherboot-developers] RFC: Safe booting concept

[Anselm M. H. <an...@ho...>]

Dear list,

after reading several posts about the upcoming
  ---)World Domination Of Etherboot(---
I had some thoughts about a safe booting concepts. As I just have some
minutes, I'd like to dig into it, but first I'd like some opinion
about this concept:

In a safe-boot environment, we must assume
 - boot rom can be read out (but not modified) by an attacker
   Why this? Because on my machines there is also a local dos. Users
     cannot open the machines and cannot disable bootrom (as the next
     user would notice), but can read it into a file.
   Consequences? We cannot store a *symmetric* key on the bootrom.
 - all network traffic can be overheard & modified by an attacker
   Why this? Because one lab is cabled BNC/10MBit, so anyone could
     attach a laptop
 - Files in /tftpboot on the server cannot be modified by an attacker

Assumption:
  dhcp: option 159 now reserved for "secure boot file digest signature",
  fixed length 32 bytes, example

  |  option option-159 code 159 = string;
  |  filename "/vmlinuz.ltsp";
  |  option option-159 73:f7:e2:03:e8:0f:c4:61:25:c3:da:28:da:4c:52:a7:18:be:70:67:8f:83:84:c9:f5:f3:85:96:52:44:43:e0;

So what do you think about the following procedure?

Boot ROM contains the server's public RSA key + corresponding software
On bootup, when etherboot gains control (which on many architectures
can be forced by the administrator, so that users cannot manipulate
without changing hardware), it gets a dhcp address+information block
as usual. This one need not be verified in my concept, it is just
trusted. Inside this packet, a filename is specified. If it's
localboot (harddisk, floppy, whatever), it proceeds. If it's a
network filename (so, "slam://10.3.4.1/slam-boot/image" would be, as
"/vmlinuz.ltsp"), it is retrieved while the md5 checksum is built over
it ( "This implementation is copyright 1997 by M. Gutschke" ). After
that, option-159 is decoded with the server's public key (which then
must have been burnt into the bootrom) and compared with the md5
digest. If it does not match, the etherboot machine refuses to boot.

This setup is designed so that without a ROM change other files could
be downloaded. A menu system would have not only to modify "filename",
but also to enter another value for option-150, but that is possible,
I did this (modifying an option string from a menu system) in a test
setup just some days ago. As the menu has been verified before, it
would be "safe", as any other loaded file would be checked again.

Can this setup be tricked? Is it "safe"? Any interest in something
like it?

Ready to code, waiting for comments.

Best regards,
  Anselm Martin Hoffmeister
  Stockholm Projekt Computer-Service
  <an...@ho...>

[Etherboot-developers] developer material

[<Gee...@xs...>]

On Fri, Apr 25, 2003 at 09:20:35PM +1000, Ken Yap wrote:
> >delete also  src/bin/.cvsignore and src/bin/ from the CVS repository
> 
> Ok.
> 
> Hmm you sound like developer material. Wanna be a developer? :-)
> 

Nice gesture.

I not sure about it. Let me think about it.


Geert Stappers

Re: [Etherboot-developers] files that CVS may ignore

[<ke...@us...>]

>delete also  src/bin/.cvsignore and src/bin/ from the CVS repository

Ok.

Hmm you sound like developer material. Wanna be a developer? :-)

Re: [Etherboot-developers] files that CVS may ignore

[<Gee...@xs...>]

On Fri, Apr 25, 2003 at 11:28:02AM +0100, prl...@sy... wrote:
> > Can't we just ignore the entire bin directory?
> > Everything in it is auto-generated.
> 
> Yes.
> 
> echo bin > src/.cvsignore
> 
> should do the trick...
> 

delete also  src/bin/.cvsignore and src/bin/ from the CVS repository

Geert Stappers

Re: [Etherboot-developers] files that CVS may ignore

[<prl...@sy...>]

> Can't we just ignore the entire bin directory?
> Everything in it is auto-generated.

Yes.

echo bin > src/.cvsignore

should do the trick...

Re: [Etherboot-developers] World domination, anyone?

[<ke...@us...>]

>Also the structure of source tree is so different in 5.1 that it should
>be documented.  Also, we should document standards for where things go
>(USB/PCMCIA).  Documentation of architecture difference would be good as
>well.

Yes it should but you will notice that Eric did the clever thing and
stole the Linux source tree structure for the most part. So have a look
at /usr/src/linux/ on your Linux box for hints.

Re: [Etherboot-developers] World domination, anyone?

[H. P. A. <hp...@zy...>]

Ken Yap wrote:
>>The UNDI driver discussion seemed interesting as 
>>well, though I need Peter or Vasil to explain how it works -- one more 
>>time :)
> 
> 
> I like the sound of this one actually.  My impression is that the idea
> is that the driver calls UNDI software interrupts. In Etherboot this
> would require a bunch of stub routines in asm callable from C. I don't
> know what the UNDI entry points are like? Are they low level, like
> read/write a network packet, or high level, like get a file by TFTP?
> Where are the readable specs? Ok, maybe just some specs? :-) What
> revision level of the specs should we be aiming for? Peter or Vasil?
> 

There are basically three levels of support in PXE: UNDI, which are raw 
link-layer packets, UDP, and TFTP.  The latter two are referred to as 
the "base code" (BC).

> 
> Apropos of something else, does anybody know if recent BIOSes support
> booting from USB flash, or is that regarded as too prone to abuse? If
> USB booting is supported, does it work like a floppy disk?
> 

Works like a hard disk.

	-hpa

Re: [Etherboot-developers] World domination, anyone?

[<ke...@us...>]

>> By the way if somebody keen could grab the OpenOffice 1.1beta and work
>> out how to edit Docbook format doco and write a short HOWTO that would
>> be good.
>
>Grabbed and looked at.  I think it still need some work.  It does a poop
>rendering job and I managed to convert a doc to one big html
>paragraph...

I think there is a webpage at the OO dev site that explains what is
needed, maybe an extra module or something, I don't remember the
details.

RE: [Etherboot-developers] World domination, anyone?

[Timothy L. <tl...@ro...>]

> By the way if somebody keen could grab the OpenOffice 1.1beta and work
> out how to edit Docbook format doco and write a short HOWTO that would
> be good.

Grabbed and looked at.  I think it still need some work.  It does a poop
rendering job and I managed to convert a doc to one big html
paragraph...

> Etherboot needs to expand its helper base. Many people are scared off
by
> the highly technical nature of the code, but there are many things to
be

I agree, there are parts of it that scare the hell out of me... ;-)

Tin

RE: [Etherboot-developers] World domination, anyone?

[Timothy L. <tl...@ro...>]

> Apropos of something else, does anybody know if recent BIOSes support
> booting from USB flash, or is that regarded as too prone to abuse? If
> USB booting is supported, does it work like a floppy disk?

I gather that some of the USB flash drives are bootable.  I assume that
it is bios dependant.

Re: [Etherboot-developers] World domination, anyone?

[Markus G. <ma...@gu...>]

Ken Yap wrote:
> plugged into existing PXE infrastructure.
> 
> Apropos of something else, does anybody know if recent BIOSes support
> booting from USB flash, or is that regarded as too prone to abuse? If
> USB booting is supported, does it work like a floppy disk?

My new Dell D800 claims to be able to boot from USB mass storage devices 
(i.e. flash) and I believe I even saw options for booting over the net 
from PCMCIA and/or 802.11b. I haven't actually tried any of these 
options, so I am not sure how well the support is implemented, and I 
haven't been able to find any documentation for it.


Markus

Re: [Etherboot-developers] World domination, anyone?

[<ke...@us...>]

>They have been converted to Docbook and are in the CVS. Feel free to
>work on them, but probably let Timothy Legge know too, as he said he had
>some intentions there. I'm going on hols in a week for 3 weeks so find
>lots of bugs and fix lots of them.

By the way if somebody keen could grab the OpenOffice 1.1beta and work
out how to edit Docbook format doco and write a short HOWTO that would
be good.

Etherboot needs to expand its helper base. Many people are scared off by
the highly technical nature of the code, but there are many things to be
done in other areas, such as improving documentation (including the
website content), installation procedures and packaging, etc.

Re: [Etherboot-developers] World domination, anyone?

[<ke...@us...>]

>The UNDI driver discussion seemed interesting as 
>well, though I need Peter or Vasil to explain how it works -- one more 
>time :)

I like the sound of this one actually.  My impression is that the idea
is that the driver calls UNDI software interrupts. In Etherboot this
would require a bunch of stub routines in asm callable from C. I don't
know what the UNDI entry points are like? Are they low level, like
read/write a network packet, or high level, like get a file by TFTP?
Where are the readable specs? Ok, maybe just some specs? :-) What
revision level of the specs should we be aiming for? Peter or Vasil?

>But what do you think?  If we went for PXE or UNDI, where are the big 
>wins? I'm always thinking about ways Etherboot could be used by more 
>people, and how we could become even more useful as a component 
>technology.

Supporting UNDI would allow Etherboot to run on NICs to which Etherboot
has not been ported but UNDI is available in the PXE code.

Supporting PXE would be another step and would allow Etherboot to be
plugged into existing PXE infrastructure.

Apropos of something else, does anybody know if recent BIOSes support
booting from USB flash, or is that regarded as too prone to abuse? If
USB booting is supported, does it work like a floppy disk?

Re: [Etherboot-developers] World domination, anyone?

[<ke...@us...>]

>I'm in work up to the ears right now, but that's not to last more than
>a week or three. I'd prefer honestly more than adding features myself
>doing something in the docs - they seemed quite not to be uptodate at
>some places. But - there was a mailing some days ago that someone
>worked on them, wasn't it? What's the status over there?

They have been converted to Docbook and are in the CVS. Feel free to
work on them, but probably let Timothy Legge know too, as he said he had
some intentions there. I'm going on hols in a week for 3 weeks so find
lots of bugs and fix lots of them.

Re: [Etherboot-developers] files that CVS may ignore

[<ebi...@ln...>]

Gee...@xs... (Geert Stappers) writes:

> On Sun, Apr 20, 2003 at 01:28:24PM +0200, Geert Stappers wrote:
> > Hello,
> > 
> > On a `cvs update` you will get a lot of warnings
> > of unregistered files in the src/bin/ directory
> > 
> > The avoid all the outputlines that start with '? src/bin/',
> > I made a cvs ignore file. IMHO it should go into CVS.
> > 
> > Could someone do
> > 
> > echo "*.rom
> > *.bin
> > *.img
> > *.zimg
> > *.fi
> *.dsk
> 
> > *.zfi
> *.zdsk
> 
> > nrv2b" > src/bin/.cvsignore
> 
> So after "the eye opener" it should be
> 
> echo "*.rom
> *.bin
> *.img
> *.zimg
> *.dsk
> *.zdsk
> nrv2b" > src/bin/.cvsignore

Can't we just ignore the entire bin directory?
Everything in it is auto-generated.

Eric

Re: [Etherboot-developers] World domination, anyone?

[<ebi...@ln...>]

"Timothy Legge" <tl...@ro...> writes:

> > I'll start by listing some of the things that personally come to mind:
> > 
> > 	o USB support
> 
> I am interested in this area.  Right at the moment, I would be more
> capable of porting the Pegasus driver than the subsystem.  The spec is
> still gathering dust here.

USB is on my long range wish list.  But it has not become a real project yet.
Though I am more likely to support USB disks than NICs.

Oh.  And I forgot to add earlier.
        o ``Trusted'' booting

> > 	o PCMCIA support
> 
> I may have access to a Laptop in the near future and this may be of some
> interest.  I suspect that supporting this with a hack (similar to the
> 3c515's ISAPNP) would be fairly easy.
> 
> > 	o UNDI driver
> > 	o PXE Support
> > 
> ???
> 
> > But what do you think?  If we went for PXE or UNDI, where are the big
> > wins? I'm always thinking about ways Etherboot could be used by more
> > people, and how we could become even more useful as a component
> > technology.
> 
> To throw it out there is there any possibility of Etherboot replacing
> PXE as a Standard?  
> 
> Also, if there was a way to end the need to tag kernels that would
> probably win some points.

Supporting pxelinux would certainly strengthen our position.


> > Btw, this is much more than of theoretical interest. I'd like to see
> us
> > implement something really cool for LinuxWorld Expo SF in August, and
> I
> > may be able to swing some limited funding for some of this.
> 
> Cooler than booting an OS through a NIC? ;-)

He might have to join up with those guys porting LinuxBIOS to the
epia.  Booting an OS through a NIC from the ROM chip.  And GPL'd
code the whole way :)
 
> > Ok, so go ahead. What do you think would be cool to do? Could you do
> > it? Do you know who could or would? And, most importantly, would it
> > bring us closer to WoRLd DomINatIoN? ;)
> > 
> Way out there (is it even possible).  Supercomputer status diskless
> cluster?

MCR is the #5 ranked supercomputer and it boots over the network
using etherboot.
http://top500.org/list/2002/11
The nodes have hard drives for their filesystems.

There is also Pink at LANL which is diskless (A 16M compaq flash
used as an extra big rom does not count).  It boots over Myrinet
so it does not use etherboot except for the ide_disk driver to load
it's bootloader.

The challenge right now is to find a good network filesystem.  Booting
the cluster is no problem (especially with multicast support).  But
even atftp has managed to cope.  It is not fast though.

Eric