etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] File Location in 5.1

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

>I would place the in:
>core/isapnp.c
>include/isapnp.h
>
>And if there is something that is demonstrably x86 specific
>the code can code in arch/i386/core.  But isapnp primarily depends
>on the isa bus and inb/outb none of which are x86 specific.  And
>inb/outb already have arch dependent implementations.

Then again, the Linux equivalents live in drivers/pnp. There is also a
directory drivers/pci. Not sure what the logic is there.

Re: [Etherboot-developers] File Location in 5.1

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

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

> Sorry for the html format, here is the text
>=20
> Hi=20
> =A0
> I am going to update the 3c515 driver in 5.1 with the changes that I
> have done in 5.0 (separating out the ISAPNP code to isapnp.c and
> isapnp.h and other updates).=A0 Where in the directory structure should
> they go?=A0 Should I leave them in drivers/net or move them to somewhere
> like core/ or arch/i386/core/

I would place the in:
core/isapnp.c
include/isapnp.h

And if there is something that is demonstrably x86 specific
the code can code in arch/i386/core.  But isapnp primarily depends
on the isa bus and inb/outb none of which are x86 specific.  And
inb/outb already have arch dependent implementations.

Eric

[Etherboot-developers] File Location in 5.1

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

Sorry for the html format, here is the text

Hi=20
=A0
I am going to update the 3c515 driver in 5.1 with the changes that I
have done in 5.0 (separating out the ISAPNP code to isapnp.c and
isapnp.h and other updates).=A0 Where in the directory structure should
they go?=A0 Should I leave them in drivers/net or move them to somewhere
like core/ or arch/i386/core/
=A0
Tim

[Etherboot-developers] File Location in 5.1

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

Hi 

 

I am going to update the 3c515 driver in 5.1 with the changes that I
have done in 5.0 (separating out the ISAPNP code to isapnp.c and
isapnp.h and other updates).  Where in the directory structure should
they go?  Should I leave them in drivers/net or move them to somewhere
like core/ or arch/i386/core/

 

Tim


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.465 / Virus Database: 263 - Release Date: 3/25/2003
 

Re: [Etherboot-developers] Securing bootup

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

"Jason A. Pattie" <pat...@pc...> writes:

> Eric W. Biederman wrote:
> > As I understand encryption most encryption techniques fail to
> > be effective about disguising a message if you send the same
> > message over and over again.  With network booting this is the
> > case.  Loading an image that was authenticated at some point
> > in time is a reasonable problem.  Beyond that the code is complicated
> > and it really does not help.
> 
> So, you would see signing a kernel+initial ramdisk package 'a good
> thing' so that the client will always boot authenticated code.  So even
> if a hacker were to send it anything, they would have to send the client
> the exact same code, which would hopefully help to prevent them from
> succeeding in their attempt or making it much more difficult.

Correct.  If you want to proceed down that direction feel free.

Eric

Re: [Etherboot-developers] Securing bootup

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

"Sam Leffler" <sa...@er...> writes:

> > There is/was a uni project working on secure booting in general, don't
> > have the URL handy, Eric has it.
> 
> google "secure bootstrap" leads you quickly to the answer(s).  I suspect
> you're thinking of Bill Arbaugh's work but there's also been stuff going on
> at CITI to use smartcards.

Right as Bill and the people working with him have already expressed some
interest in LinuxBIOS and etherboot.

Eric

Re: [Etherboot-developers] Securing bootup

[Sam L. <sa...@er...>]

> There is/was a uni project working on secure booting in general, don't
> have the URL handy, Eric has it.

google "secure bootstrap" leads you quickly to the answer(s).  I suspect
you're thinking of Bill Arbaugh's work but there's also been stuff going on
at CITI to use smartcards.

    Sam

Re: [Etherboot-developers] Securing bootup

[Jason A. P. <pat...@pc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric W. Biederman wrote:
> As I understand encryption most encryption techniques fail to
> be effective about disguising a message if you send the same
> message over and over again.  With network booting this is the
> case.  Loading an image that was authenticated at some point
> in time is a reasonable problem.  Beyond that the code is complicated
> and it really does not help.

So, you would see signing a kernel+initial ramdisk package 'a good
thing' so that the client will always boot authenticated code.  So even
if a hacker were to send it anything, they would have to send the client
the exact same code, which would hopefully help to prevent them from
succeeding in their attempt or making it much more difficult.

- --
Jason A. Pattie
pat...@xp...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+hGhtuYsUrHkpYtARAmLeAJ9cPN/6VGsorpw1My0lcJU8hQ4MwgCeJ1kf
yDHO8aWwrxNVHmVjUext5OE=
=6QOp
-----END PGP SIGNATURE-----


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Etherboot-developers] Securing bootup

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

"Jason A. Pattie" <pat...@pc...> writes:

> Ken Yap wrote:
> >>Does Etherboot initialize USB and read this key?
> >
> >
> > No, that would be another project on the wishlist. :-)
> >
> >
> >>Perfect!  IPSec implements key exchanges on UDP port 500.
> >
> >
> > Don't you need TCP for data transfers?
> 
> Hmm.  I think so.  However, the encrypted tunnel would be using packets
> on protocols 50 and 51 (ESP/AH), which then get converted to TCP or UDP
> packets inside the kernel.

As I understand encryption most encryption techniques fail to
be effective about disguising a message if you send the same
message over and over again.  With network booting this is the
case.  Loading an image that was authenticated at some point
in time is a reasonable problem.  Beyond that the code is complicated
and it really does not help.

Eric

Re: [Etherboot-developers] 3c509 driver and the troublesome 486

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

>Some time ago someone mentioned that perhaps currticks was not working
>correctly on my 486.  How can I find out?  

There are two main sources of timing in PCBIOS hosted Etherboto: the
18.2 Hz clock (currcicks) and the one-shot timer that's clocked at 1.1
MHz or something close (udelay). Insert little code segments in
Etherboot to call currticks or udelay respectively in a loop and print
something every second.  That will tell you which timers are working.

Re: [Etherboot-developers] Securing bootup

[Jason A. P. <pat...@pc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ken Yap wrote:
>>Does Etherboot initialize USB and read this key?
>
>
> No, that would be another project on the wishlist. :-)
>
>
>>Perfect!  IPSec implements key exchanges on UDP port 500.
>
>
> Don't you need TCP for data transfers?

Hmm.  I think so.  However, the encrypted tunnel would be using packets
on protocols 50 and 51 (ESP/AH), which then get converted to TCP or UDP
packets inside the kernel.

- --
Jason A. Pattie
pat...@xp...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+g5MauYsUrHkpYtARAqNiAJ9x96jL3xhFFVDHAxqiD1a6OPqSXACePYdK
6ZEU4jEvHNc6cuoQF2okoNs=
=FMep
-----END PGP SIGNATURE-----


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Etherboot-developers] Securing bootup

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

>Does Etherboot initialize USB and read this key?

No, that would be another project on the wishlist. :-)

>Perfect!  IPSec implements key exchanges on UDP port 500.

Don't you need TCP for data transfers?

Re: [Etherboot-developers] Securing bootup

[Jason A. P. <pat...@pc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ken Yap wrote:
>>An idea struck me today as I was thinking about a way to more securely
>
> Hope it wasn't too painful. :-)

Just fried a few brain cells...  :D

>>verify that the client that is booting via Etherboot is actually
>>downloading the kernel/code that you really want it to.  Use a preshared
>>key built into the Etherboot code that is flashed onto the bootrom to
>>validate the kernel image/code.  So, in order for the client to
>>successfully boot, the image it downloads has to be digitally signed and
>>that signature has to match when signed by the clients Etherboot key.
>>Otherwise the client refuses to boot.  There could be a number of ways
>>to go about this, from having a default "Etherboot" maintained key and
>>signature to a site-by-site basis where the administrator/deployer would
>>build there own version of Etherboot to embed their own key for their
>>own thin client workstations.
>
>
> Or a key in a USB dongle.

Does Etherboot initialize USB and read this key?

> There is/was a uni project working on secure booting in general, don't
> have the URL handy, Eric has it.
>
> Eric's got a hook in 5.1 that verifies download integrity using a
> checksum over the image. Verifying a signature is an obvious extension.
>
>
>>Another possibility that this presents is to not only authenticate the
>>connection but also be able to create an encrypted tunnel using
>>Diffie-Hellman key exchange.  This may be a rather involved process just
>>to get a secure boot layer, but it may open up the doors to a larger
>>audience and wider acceptance of Etherboot.
>
>
> Tunnels are much harder. Etherboot only implements UDP.

Perfect!  IPSec implements key exchanges on UDP port 500.

>>What do you all think?
>
>
> Great idea, looking forward to seeing your code soon. :-)
>
> But seriously, it's a good idea worth developing further, but as always
> implementation depends on someone keen enough to contribute some time to
> do it.

Heh.  I haven't even looked at the source code in any serious way for
Etherboot.  And definitely not any of the later versions.  I usually go
to Rom-o-Matic.net to download one whenever I need an image.

- --
Jason A. Pattie
pat...@xp...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+g4bZuYsUrHkpYtARAuHGAJ9D/WGqZng9CRIKRuPQ1d5JD9eBGgCeIKlR
IqHyhBnVKYyDtsiqTqxcTGo=
=pAEG
-----END PGP SIGNATURE-----


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Etherboot-developers] Securing bootup

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

>An idea struck me today as I was thinking about a way to more securely

Hope it wasn't too painful. :-)

>verify that the client that is booting via Etherboot is actually
>downloading the kernel/code that you really want it to.  Use a preshared
>key built into the Etherboot code that is flashed onto the bootrom to
>validate the kernel image/code.  So, in order for the client to
>successfully boot, the image it downloads has to be digitally signed and
>that signature has to match when signed by the clients Etherboot key.
>Otherwise the client refuses to boot.  There could be a number of ways
>to go about this, from having a default "Etherboot" maintained key and
>signature to a site-by-site basis where the administrator/deployer would
>build there own version of Etherboot to embed their own key for their
>own thin client workstations.

Or a key in a USB dongle.

There is/was a uni project working on secure booting in general, don't
have the URL handy, Eric has it.

Eric's got a hook in 5.1 that verifies download integrity using a
checksum over the image. Verifying a signature is an obvious extension.

>Another possibility that this presents is to not only authenticate the
>connection but also be able to create an encrypted tunnel using
>Diffie-Hellman key exchange.  This may be a rather involved process just
>to get a secure boot layer, but it may open up the doors to a larger
>audience and wider acceptance of Etherboot.

Tunnels are much harder. Etherboot only implements UDP.

>What do you all think?

Great idea, looking forward to seeing your code soon. :-)

But seriously, it's a good idea worth developing further, but as always
implementation depends on someone keen enough to contribute some time to
do it.

[Etherboot-developers] Securing bootup

[Jason A. P. <pat...@pc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I haven't looked through the archives, yet, but wanted to throw an idea
out to see what everyone thinks.

An idea struck me today as I was thinking about a way to more securely
verify that the client that is booting via Etherboot is actually
downloading the kernel/code that you really want it to.  Use a preshared
key built into the Etherboot code that is flashed onto the bootrom to
validate the kernel image/code.  So, in order for the client to
successfully boot, the image it downloads has to be digitally signed and
that signature has to match when signed by the clients Etherboot key.
Otherwise the client refuses to boot.  There could be a number of ways
to go about this, from having a default "Etherboot" maintained key and
signature to a site-by-site basis where the administrator/deployer would
build there own version of Etherboot to embed their own key for their
own thin client workstations.

Another possibility that this presents is to not only authenticate the
connection but also be able to create an encrypted tunnel using
Diffie-Hellman key exchange.  This may be a rather involved process just
to get a secure boot layer, but it may open up the doors to a larger
audience and wider acceptance of Etherboot.

What do you all think?

- --
Jason A. Pattie
pat...@xp...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+g3MguYsUrHkpYtARApPUAJ4zPzMp8WrBK/g5hwdXwX454D5I/wCeNq08
XtAWPTZcZltj0u4Z4/h7GIw=
=8QF4
-----END PGP SIGNATURE-----


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Etherboot-developers] Error reporting thoughts...

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

>1)  If we drop a DHCP packet because it does not have what
>    we are looking for we do not even warn once.  This is probably
>    as useful as the fragmented packet handling warning.

Yes, some newbies forget to provide a filename and wonder why there's no
response. However to know that the warning has been issued, one would
have to retain the IP address of the useless server(s). Also the output
could get annoying in situations where it's expected that useless
servers will make offers. Maybe a config variable that can be turned
off?

>2)  If you do not have a TFTP server setup we ignore the icmp error.
>    Possibly we should do something with it.

Sounds reasonable.

[Etherboot-developers] Error reporting thoughts...

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

Recently I have run into two cases that might be worth at least
thinking about with respect to error handling.

1)  If we drop a DHCP packet because it does not have what
    we are looking for we do not even warn once.  This is probably
    as useful as the fragmented packet handling warning.

2)  If you do not have a TFTP server setup we ignore the icmp error.
    Possibly we should do something with it.

I'm not thinking clearly be it is quite possible that something should
be done on that score.

Eric

[Etherboot-developers] 3c509 driver and the troublesome 486

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

Hi

In order to get the 3c509 driver to find the card on my 486, I need to
and the old DELAY function:

static void DELAY(int val)
{
    int c;
    for (c = 0; c < val; c += 20) {
	twiddle();
    }
}

and change get_eeprom_data as follows (changing the udelay to 60000 does
not help):

static int
get_eeprom_data(int id_port, int offset)
{
	int i, data = 0;
	outb(0x80 + offset, id_port);
	/* Do we really need this wait? Won't be noticeable anyway */
- udelay(10000);
+ DELAY(350);
	for (i = 0; i < 16; i++)
		data = (data << 1) | (inw(id_port) & 1);
	return (data);
}

Some time ago someone mentioned that perhaps currticks was not working
correctly on my 486.  How can I find out?  

Tim


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.465 / Virus Database: 263 - Release Date: 3/25/2003
 

RE: [Etherboot-developers] Tagged Test Image

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

> >I'm going to comment out the gateA20_unset and see what happens.
> 
> Bingo, DOS and ROM images now load and run.

I am not sure what happened, but the latest cvs update I did reboots
almost immediately on my 486.  I will try some debugging tomorrow.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.465 / Virus Database: 263 - Release Date: 3/25/2003
 

Re: [Etherboot-developers] Tagged Test Image

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

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

> >O.k.  Then we need to get a20 handling fixed in 5.1.x
> >That is one area 5.0 is definitely doing better.
> 
> The Linux images not running appears to be my bug in the trampoline
> (invalid assumption about which 64kB segment it's running in). I'll work
> on that.
> 
> It also looked like a bunch of stuff in misc.c should be migrated to
> arch/i386/firmware.

Yep.  The are all conditional upon -DPCBIOS so they are not
a problem.  But moving the could would certainly be a clean
thing to do.

Eric 

Re: [Etherboot-developers] Tagged Test Image

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

>O.k.  Then we need to get a20 handling fixed in 5.1.x
>That is one area 5.0 is definitely doing better.

The Linux images not running appears to be my bug in the trampoline
(invalid assumption about which 64kB segment it's running in). I'll work
on that.

It also looked like a bunch of stuff in misc.c should be migrated to
arch/i386/firmware.

Re: [Etherboot-developers] Etherboot questions

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

Paul <pau...@vi...> writes:
> 
> OK - I'll have a look at where etherboot uses the clock - My embedded PC
> has an AMD Elan 520 processor on it which has standard PC stuff
> integrated along with it.  
> 
> I have only just started looking at ROLO and Etherboot source code so
> I'm not exactly sure what I need to do yet.  I didn't see pci bus
> enumeration/resource allocation going on in ROLO so I am assuming that
> this is left to Linux.  However, clearly the PCI registers in the
> ethernet device will need to be enabled - and perhaps the interrupt? -
> again I haven't yet concluded whether Etherboot uses an interrupt... 

If you get to the point where you need this it may be worth getting
LinuxBIOS going or at least looking at the source.  It already does
the pci bus enumeration/resource allocation.

LinuxBIOS may be over kill for an embedded system like that though.

> If an etherboot build can provide me with a BIOS extension ROM image for
> my PCI ethernet controller device then I can put it straight into my
> boot PROM at the appropriate address.  ROLO doesn't appear to do any
> searching for BIOS extensions but this shouldn't be too much of a
> problem to add some code so that it finds the image provided by
> etherboot.
> 
> Thanks,

Welcome and good luck.

Eric

Re: [Etherboot-developers] Tagged Test Image

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

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

> >I'm going to comment out the gateA20_unset and see what happens.
> 
> Bingo, DOS and ROM images now load and run.

O.k.  Then we need to get a20 handling fixed in 5.1.x
That is one area 5.0 is definitely doing better.

Enabling a20 we can leave in the C code. 
But the code should:
- Test to see if a20 is already enabled.
- Test to see if we can use the bios to enable a20
- Test to see if we can directly enable a20 KBC.

And we should record how a20 was enabled so when we are in 16bit mode
we can restore a20 to the state we can in with.

I think there is something else missing from the 5.0.x a20
handling as well.

But it should not be hard to move that down to 16bit mode.

I believe some things do get grumpy if we don't disable a20
handling when we do the hand off in 16bit mode so.

But moving the disable to xstart16 looks like the right
place to do it given the consequence if we are above 1MB.

We probably did not see this earlier as -DRELOCATE was not
the default.

Eric

Re: [Etherboot-developers] Tagged Test Image

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

>I'm going to comment out the gateA20_unset and see what happens.

Bingo, DOS and ROM images now load and run.

Re: [Etherboot-developers] Tagged Test Image

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

>(1) could be an error in the trampoline that mknbi uses, but with
>FreeDOS and the ROM image it should be just straight jumps into 16-bit
>code; Etherboot is supposed to just call xstart16. Which makes me
>suspect that the 16-bit registers are messed up in RELOCATE mode. Or
>maybe it's something to do with A20 routines? Any theories, Eric?

Eric, at lines 133 onward in tagged_loader.c there is:

					gateA20_unset();
					xstart16(tctx.img.execaddr, 
						tctx.img.u.location, 
						virt_to_phys(BOOTP_DATA_ADDR));

But if A20 is unset, the relocated Etherboot may be unmapped (depending
on whether it's in an odd or even megabyte), and then there's no way to
execute xstart16. Am I wrong? Wasn't this discussed last year?

Perhaps what's needed is an xstart16 that does the A20 unset as well (in
16-bit mode).

I'm going to comment out the gateA20_unset and see what happens.