[LinuxBIOS] ROM image integrity

Stefan Reinauer stepan at openbios.org
Sun Nov 13 14:28:48 CET 2005


* Eric W. Biederman <ebiederman at lnxi.com> [051113 09:33]:
> > Others (src/arch/i386/lib/id.lds)
> > SECTIONS {
> >         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
> >         .id (.): {
> >                 *(.id)
> >         }
> > }
> >
> > the arima hdama image looks like this:
> > 00000000fffdffd8 R __id_start
> > 00000000fffdffd8 r vendor
> > 00000000fffdffde r part
> > 00000000fffdfff0 R __id_end
> >
> > only the last 16 bytes don't belong to the ID.
> >
> > funny enough, linuxbios.rom contains this:
> >
> > 007ffd0: ffff ffff ffff ffff 4152 494d 4100 4844  ........ARIMA.HD
> > 007ffe0: 414d 4100 2800 0000 2200 0000 0000 0200  AMA.(...".......
> > 007fff0: e9b5 49ff ff00 0000 e903 4aff ff00 0000  ..I.......J.....
> >
> > So where does the 2800 0000 2200 0000 0000 0200 come from?
> >
> > Does the linker put some crap in there after the ID?
 
Looking at crt0.s it is not crap but really useful: The linker places
pointers to the string so we actually don't have to walk backward. I
could not find this in the code, but I consider it can be used:

   int show_id(unsigned char *bios, int size)
   {
           unsigned char *manuf, *id;
           unsigned int *walk;
   
           walk=(unsigned int *)(bios+size-0x10);
           walk--; printf("image size=%d\n", *walk);
           walk--; id=bios+size-*walk;
           walk--; manuf=bios+size-*walk;
           printf("MANUFACTURER: %s\n", manuf);
           printf("MAINBOARD ID: %s\n", id);
           return 0;
   }

> > I would also suggest that on a given cpu architecture (ie. x86 or ppc)
> > the ID string should either be at a fixed address, one that suits all
> > chipsets. Or It should be identifyable in flash using a signature,
> > similar to the LinuxBIOS table in memory.
> 
> The problem is that over time hardware people get inventive.  So
> I'm not certain that is possible.
 
Though, matching a file image with what is in a certain system is
absolutely necessary if we want to establish LinuxBIOS as a usable 
product for end customers.

> > If such a in-rom table differs in position or details between x86 and
> > ppc, this won't be too nasty.
> 
> Agreed.  But having code that works everywhere is useful.

There will always be small differences, such where the image is located
and where the entry point is loaded. As long as there's a good mechanism
making it easy to get this information in one way we're fine. The
LinuxBIOS table is slightly different on ppc and x86 already today.

> > Having this in the image would help comparing the map of an file
> > image to that of the rom image for example. I.e. you have two versions
> > of a board out there, one with 8MBit flash and one with 4 MBit flash.
> > Someone has a 512kByte flash file. Is this the normal image of case 1
> > or a complete image of case 2 etc pp.
> 
> Right now as long as the image is small enough it fits in 4Mbit it will
> happily flash in either a 4Mbit or an 8Mbit part.
 
So you could flash a fallback only image over a fallback+normal image
without lbflash ever complaining.

> Yes and no.  Having a directory with all of the pieces is useful, and is a lot
> more maintainable from a forward/backwards compatibility point of view.  If
> we combine them I would rather do it as a cpio or a tar or an rpm.
> Something where the structure is apparent but you have to try to work
> at it to get multiple files.
 
Probably true.

> I am conflicted on that one.  If you are talking users and not developers
> it is usually easier to ensure that people have the right mtd drivers
> loaded.  Last I looked the mtd code had a much better structure than
> flash_and_burn, allowing for much more code reuse and a lot more
> eyes looking at the problems.  flash_and_burn on the other hand seems
> a great tool for developers, who know what should be happening but it
> doesn't seem to have as many checks to make certain that you aren't
> doing something stupid.
 
I would agree if mtd did the autoprobing and flash_and_burn didnt. But
finding the right pair of mtd drivers can be annoying. The modular
concept is nice, no doubt. But for an end user I don't really see an
advantage. 

> Groan.  It looks like someone forget to place the source rpm on the
> public ftp site.  2.1 is pretty much a maintenance release with the
> exception of a couple of very minor bug fixes nothing really has
> changed.  So for getting a feel of the structure and the files we
> are currently using 2.0 should be reasonable starting point.

Ah, I assumed that you would only provide the source for older releases,
same for the cmos tool. Which would be perfectly understandable. So I
will have a closer look at lbflash. How do you produce the rom tables?

> Hmm.  In looking at things I just noticed that the decompressor
> doesn't have anything like that, which really is a bug.  That I
> unfortunately didn't catch when I found that code.

Hey, it's really small. In a safety critical application we might not
even want to go to fallback mode but rather print an error message over
serial and go to nirvana in case of a wrong checksum. 
Just wondering where the best place for such a checksum check would be
anyways. I would not want to cope with this in ramless code I guess.

Stefan 






More information about the coreboot mailing list