AMD64: Something's missing?

[Stefan Reinauer]

Building the Quartet target with latest CVS I get:
raminit.c:2378.43: is_cpu_pre_c0 undeclared

I'll look into it..

Stefan

[Stefan Reinauer]

* Stefan Reinauer  [031013 10:42]:
> Building the Quartet target with latest CVS I get:
> raminit.c:2378.43: is_cpu_pre_c0 undeclared

ah.. northbridge/amd/amdk8/cpu_rev.c is the secret.

Stefan

Stefan Reinauer  writes:
> Stefan Reinauer  [031013 10:42]:
> > Building the Quartet target with latest CVS I get:
> > raminit.c:2378.43: is_cpu_pre_c0 undeclared
>
> ah.. northbridge/amd/amdk8/cpu_rev.c is the secret.

Sorry about that.

Before we declare this 2.0 instead of 1.1.xxx
we should really have a target that will build everything
in the tree that a person has the compilers for.

Eric

[Stefan Reinauer]

* Eric W. Biederman  [031013 15:23]:
> Sorry about that.

I fixed it for Solo, others will follow once I have the Solo up again.
> Before we declare this 2.0 instead of 1.1.xxx
> we should really have a target that will build everything
> in the tree that a person has the compilers for.

This would probably mean building only the linuxbios image without a
payload, since the payload paths differ pretty heavily across the
targets.

Stefan

Stefan Reinauer  writes:
> Eric W. Biederman  [031013 15:23]:
> > Sorry about that.
>
> I fixed it for Solo, others will follow once I have the Solo up again.
> > Before we declare this 2.0 instead of 1.1.xxx
> > we should really have a target that will build everything
> > in the tree that a person has the compilers for.
>
> This would probably mean building only the linuxbios image without a
> payload, since the payload paths differ pretty heavily across the
> targets.

Yes.  I think so.  I have some plans afoot to enable flashing from
rom images directly from ELF formated rom files instead of a raw
binary image.   Once that comes to pass relaxing the payload
requirement should be much easier.   Allowing us to flash and build
linuxbios and the payloads independently.  The tricky bit
is figuring out the proper distribution format, so a novice user
can't mess it up.

The first step is updating the mtd map drivers to actually register
in /proc/iomem.  That allows a user space program to dynamically
discover which mtd devices to use.

Eric

[Terry Blunt]

[e-mail] (Eric W. Biederman) wrote:
> Stefan Reinauer  writes:
> > Eric W. Biederman  [031013 15:23]:
> > > Sorry about that.
> >
> > I fixed it for Solo, others will follow once I have the Solo up again.
> > > Before we declare this 2.0 instead of 1.1.xxx we should really have a
> > > target that will build everything in the tree that a person has the
> > > compilers for.
> >
> > This would probably mean building only the linuxbios image without a
> > payload, since the payload paths differ pretty heavily across the
> > targets.
>
> Yes.  I think so.  I have some plans afoot to enable flashing from rom
> images directly from ELF formated rom files instead of a raw binary image.
> Once that comes to pass relaxing the payload requirement should be much
> easier.   Allowing us to flash and build linuxbios and the payloads
> independently.  The tricky bit is figuring out the proper distribution
> format, so a novice user can't mess it up.

Ah! My cue I think.

Being a novice user. I currently run the Mandrake distro. I'm not entirely
clear where LinuxBios leaves off and the normal distros take over. Or even
if it works that way at all.

I *very* much like the idea of having as much of my system as possible
open-source, and I'm also keen on the fast start-up the website suggests
However, I'm concerend at the possibility of trying to re-flash my bios,
making a mistake and finding I have an unusable motherboard.

Can someone help me get a clearer understanding of what is involved?

[Peter Stuge]

Hi everyone.

This has a lot of basic stuff probably already well known on the list, but I
figured it might help someone. Felt like documenting a little. :)

On Mon, Oct 20, 2003 at 11:10:54PM +0100, Terry Blunt wrote:
> I *very* much like the idea of having as much of my system as possible
> open-source, and I'm also keen on the fast start-up the website suggests
> However, I'm concerend at the possibility of trying to re-flash my bios,
> making a mistake and finding I have an unusable motherboard.

This is a very valid concern. Later on a rom-o-matic could be set up where
you just pick your motherboard and desired configuration using a web form
and then download a new BIOS image with instructions for flashing it onto
your motherboard. If you flash an image which isn't for your specific board,
the system will not start (at all!) and you will have to remove and
reprogram the flash memory chip outside your computer. (Messy for end users,
done several times a day by developers.) Flash memory chips soldered
directly to the mainboard is not uncommon, so people really have to beware.
> Can someone help me get a clearer understanding of what is involved?

A legacy BIOS does lots of stuff at boot, and then finally tries to find an
operating system bootloader in the MBR (Master Boot Record, sector 0) of the
first hard disk. (Subject to configuration in the BIOS setup menus, CD-ROM,
floppy, second hard disk etc..)

There are two common bootloaders for Linux written for the legacy BIOS; LILO
and GRUB. I prefer LILO, maybe because I'm too stupid to see the beauty of
GRUB.

LILO is installed to the hard disk by running /sbin/lilo in a Linux system.
Usually this is done from a distribution installation floppy or CDROM.

Before LILO can be installed, you have to tell it where on your harddisk the
Linux kernel you want it to load is, often done automatically by installers.
(Config file: /etc/lilo.conf)

/sbin/lilo will store the physical location(s) of the kernel (it can be
scattered throughout the disk because of how filesystems work) so that LILO
can read all these pieces at boot without knowing how the filesystem works.
LILO then jumps to the kernel.

The kernel does early setup, including switching text modes and getting the
CPU out of the hideous 8086 (popular CPU back in 1979 or so) compatibility
mode that all x86-compatible CPUs start up in. When the kernel is done
initializing subsystems, it executes /sbin/init, which forks according to
/etc/inittab.

LinuxBIOS differs in many ways but for this purpose I'll only mention the
bootloader, because it's the most obvious high-level difference.
(Low-level differences are numerous and very good, however!)

LinuxBIOS is designed to live with a bootloader, or payload, in flash.
Originally a Linux kernel was intended to be used as the bootloader, and
while this is cool and works very well, motherboard manufacturers don't
currently ship boards with large enough flash memory chips for this to be
viable in the mainstream.

Instead, a couple of other payloads are used/developed. EtherBoot, FILO and
9load come to my mind right now. Sorry about those I forgot. (BarebonesTK?)

EtherBoot can boot lots of things from the network or an IDE hard disk. FILO
can boot from IDE hard disk, IDE CDROM, floppy, and maybe more? 9load I
don't know much about except that it is used to load the plan9 kernel.

Short-term, I think LinuxBIOS+FILO will be the most common OSS BIOS, mainly
because of the limited size of flash memory. Hopefully, when vendors realize
that people want to buy motherboards with LinuxBIOS+Linux, they'll put
larger flash on them. (The board would still be cheaper, since there's no
license fee to pay for the proprietary BIOS.)

Hope this helps. :)

//Peter

[Evan Langlois]

> EtherBoot can boot lots of things from the network or an IDE hard disk.
> FILO can boot from IDE hard disk, IDE CDROM, floppy, and maybe more? 9load
> I don't know much about except that it is used to load the plan9 kernel.

I don't know much about FILO.  Can anyone comment on its compatibility with 
the LILO graphical features (displaying graphical menus/splash screens), and 
is there any support available for encrypted filesystems?

Assuming FILO works like LILO, and doesn't know about filesystems, I'm 
assuming encryption would be difficult, and it might therefore be best to 
chain-load another boot-loader, but I'd want the encryption keys to be in the 
ROM to make it as difficult as possible to get to them.

Encryption in the BIOS itself may be a positive feature, not just for 
corporate users that want to protect their IP, but laptop users and such (in 
which case the key would be asked for on boot) that don't want sensitive 
information leaking out just because a laptop was stolen.

-- Evan

LinuxBIOS high level overview [was: AMD64: Something's missing?]

[Peter Stuge]

On Tue, Oct 21, 2003 at 10:26:01PM +0200, Evan Langlois wrote:
> I don't know much about FILO.

I should have included the URL where it lives: http://te.to/~ts1/filo/
Sorry about that.
> Can anyone comment on its compatibility with the LILO graphical features
> (displaying graphical menus/splash screens), and is there any support
> available for encrypted filesystems?

Graphics may not be up when FILO runs, LinuxBIOS does not have a waterproof
way of initializing all graphics controllers yet. (See list archives, search
for VGABIOS.)
> Assuming FILO works like LILO, and doesn't know about filesystems, I'm 
> assuming encryption would be difficult, and it might therefore be best to 
> chain-load another boot-loader, but I'd want the encryption keys to be in
> the ROM to make it as difficult as possible to get to them.

Encryption keys should be in the user IMHO, but this is another discussion
entirely. The ROM is anyway very easy to get information from, assuming the
system boots from it. (There's limited use of a disconnected ROM though..)
> Encryption in the BIOS itself may be a positive feature, not just for 
> corporate users that want to protect their IP, but laptop users and such
> (in which case the key would be asked for on boot) that don't want
> sensitive information leaking out just because a laptop was stolen.

Yep, this is a good idea. See http://www.nah6.nl/products/secure-notebook/

//Peter

[SONE Takeshi]

On Tue, Oct 21, 2003 at 10:26:01PM +0200, Evan Langlois wrote:
> > EtherBoot can boot lots of things from the network or an IDE hard disk.
> > FILO can boot from IDE hard disk, IDE CDROM, floppy, and maybe more? 9load
> > I don't know much about except that it is used to load the plan9 kernel.
>
> I don't know much about FILO.  Can anyone comment on its compatibility with 
> the LILO graphical features (displaying graphical menus/splash screens), and 
> is there any support available for encrypted filesystems?

FILO is not aimed at being compatible with LILO.
> Assuming FILO works like LILO, and doesn't know about filesystems, I'm 
> assuming encryption would be difficult, and it might therefore be best to 
> chain-load another boot-loader, but I'd want the encryption keys to be in the 
> ROM to make it as difficult as possible to get to them.

FILO has filesystem routines borrowed from GRUB, so it works like GRUB
rather than LILO.
> Encryption in the BIOS itself may be a positive feature, not just for 
> corporate users that want to protect their IP, but laptop users and such (in 
> which case the key would be asked for on boot) that don't want sensitive 
> information leaking out just because a laptop was stolen.

Encryption in boot process doesn't make sense to me.
What you want to protect is the data in the storage, not the boot image
(kernel).
Encryption of the storage is OS's bussiness, and the OS will ask you the
password before decrypting any data.

[Evan Langlois]

> Encryption in boot process doesn't make sense to me.
> What you want to protect is the data in the storage, not the boot image
> (kernel).
> Encryption of the storage is OS's bussiness, and the OS will ask you the
> password before decrypting any data.

Don't assume the boot image is a Linux kernel!

The boot image in this case would be a proprietary piece of software for
real-time network filtering.  The algorythm for which is patented
technology.  A user-input encryption key doesn't make sense as the box
is stand-alone and does not have an operator.  A simple encryption at
least stops someone from removing the drive (or flash disk) from the
system and reverse engineering it.  Granted, they can get the key from
the ROM, but if they have to disassemble the ROM to do it, it might slow
things down.

It would at least be better protection than a non-encrypted system being
booted by the PC BIOS.

----
Evan K. Langlois
Melior, Inc.

iSecure - CyberWarfare Defense
www.dDoS.com

Tel: (888) 4 MELIOR or [phone]
Fax: (888) TO FAX US or [phone]

Mobile USA: [phone]

This email is intended for the addressee only.  
The material may be privileged and may contain confidential
information.  
If you have received this email in error, please notify Melior, Inc.
immediately 
by email and delete the original.  Thank you

[Peter Stuge]

On Wed, Oct 22, 2003 at 05:31:46AM -0500, Evan Langlois wrote:
> The boot image in this case would be a proprietary piece of software for
> real-time network filtering.  The algorythm for which is patented
> technology.  A user-input encryption key doesn't make sense as the box
> is stand-alone and does not have an operator.  A simple encryption at
> least stops someone from removing the drive (or flash disk) from the
> system and reverse engineering it.  Granted, they can get the key from
> the ROM, but if they have to disassemble the ROM to do it, it might slow
> things down.

Maybe by a day.
> It would at least be better protection than a non-encrypted system being
> booted by the PC BIOS.

IMHO it's hardly worth the effort. A skilled individual would probably not
need more than a single day to bypass it, while it will take several working
days to create. Instead, use dedicated hardware for decrypting, and require
it to be present at boot. (Smart cards come to mind.)
> iSecure - CyberWarfare Defense
> www.dDoS.com

Ehrm..
> This email is intended for the addressee only.  
> The material may be privileged and may contain confidential
> information.  
> If you have received this email in error, please notify Melior, Inc.
> immediately 
> by email and delete the original.  Thank you

Please do not send expressly confidential email to public mailing lists.

Thanks in advance for reconfiguring your mail system. :)

//Peter

[SONE Takeshi]

On Wed, Oct 22, 2003 at 12:27:35PM +0200, Peter Stuge wrote:
> On Wed, Oct 22, 2003 at 05:31:46AM -0500, Evan Langlois wrote:
> > The boot image in this case would be a proprietary piece of software for
> > real-time network filtering.  The algorythm for which is patented
> > technology.  A user-input encryption key doesn't make sense as the box
> > is stand-alone and does not have an operator.  A simple encryption at
> > least stops someone from removing the drive (or flash disk) from the
> > system and reverse engineering it.  Granted, they can get the key from
> > the ROM, but if they have to disassemble the ROM to do it, it might slow
> > things down.
>
> Maybe by a day.

They don't have to disassemble the ROM, when GPLed code is used to
build it.
You can't keep it secret when you added your crypto code to GPLed
software (like LinuxBIOS or FILO).

You want obfuscation. IMHO it is a bad idea in general.

[Evan Langlois]

> They don't have to disassemble the ROM, when GPLed code is used to
> build it.
> You can't keep it secret when you added your crypto code to GPLed
> software (like LinuxBIOS or FILO).
>
> You want obfuscation. IMHO it is a bad idea in general.

Agreed - was just a thought

-- Evan

[Evan Langlois]

> They don't have to disassemble the ROM, when GPLed code is used to
> build it.
> You can't keep it secret when you added your crypto code to GPLed
> software (like LinuxBIOS or FILO).

Oh yes!  My bad.

I agree 100%.  I'm definately against illegal appropriation of GPL code.  I'm 
usually the first to point stuff like that out.  Thank you very much for 
reminding me.  I need to catch up on sleep and plan this the right way that 
doesn't break GPL.  The smart-card suggestion someone posed might be an idea.

Thanks again!

-- Evan

[Peter Stuge]

On Wed, Oct 22, 2003 at 07:55:56PM +0200, Evan Langlois wrote:
> The smart-card suggestion someone posed might be an idea.

I like the Schlumberger (now: Axalto) Cryptoflex[1] (NB not Cyberflex) cards
a lot. I have a few e-gate 32K[2] cards that I'm playing with here, I'm
using the USB token, but i was told they can be used in serial card readers
as well. I use them with OpenSC[3] and OpenCT.

//Peter

[1] http://www.cryptoflex.com/
[2] http://www.reflexreaders.com/Products/e-gate/e-gate.html
[3] http://www.opensc.org/