On 8/28/07, Stefan Reinauer stepan@coresystems.de wrote:
- ron minnich rminnich@gmail.com [070828 06:16]:
=================================================================== --- lib/lar.c (revision 480) +++ lib/lar.c (working copy) @@ -42,9 +49,31 @@
for (walk = archive->start; (walk - 1) < (char *)(archive->start + archive->len - 1 ); walk += 16) {
if (strcmp(walk, MAGIC) != 0)
/* I am leaving this code in here because it is so dangerous. MAGIC is* #define'd to a string. That string lives in data space. All of the 1M linuxbios* image is a LAR file. Therefore, this search can walk ALL of linuxbios.* IF the MAGIC string (in code space) just happens to be 16-byte aligned,* Then the strcmp will succeed, and you will match a non-LAR entry,* and you are screwed. can this happen? YES!* LAR: Attempting to open 'fallback/initram'.* LAR: Start 0xfff00000 len 0x100000* LAR: current filename is normal/payload* LAR: current filename is normal/option_table* LAR: current filename is normal/stage2* LAR: current filename is normal/initram* LAR: current filename is R: it matches %s @ %p* That garbage is there because the pointer is in the middle of a bunch* of non-null-terminated junk. The fix is easy, as you can see.I think the fix could be even simpler. Instead, if the first header is found, the second header should be searched _after_ the end of the first file in the LAR archive. Going through all of the ROM including the data itself is plain stupid. I remember we did not do this in the beginning, but we broke it since then.
The match appeared to be happening in the code space of linuxbios, i.e. in the top 64k or so of rom. that string (MAGIC) was 16-bit aligned. How can you fix that? The lar archive size is 0x100000 -- all of FLASH.
printf(" -e pre-parse the payload ELF into LAR segments. Recommended\n\n");
{"parseelf", 1, 0, 'p'},
while ((opt = getopt_long(argc, argv, "acC:xls:b:vVh?",--parseelf will not work like that.
Fixed. Patch follows in next message in reply to Carl-Daniel.
ron