[LinuxBIOS] patch: extending LAR, and removing elf from linuxbios (it is not needed)

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Tue Aug 28 16:59:58 CEST 2007


On 28.08.2007 16:49, ron minnich wrote:
> On 8/28/07, Stefan Reinauer <stepan at coresystems.de> wrote:
>> * ron minnich <rminnich at 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.

Can we change the MAGIC to some less likely string, perhaps even with
version info? A lot of filesystems have mixed-case magic strings, for
example ReiserFS has "ReIsErFs" or "ReIsEr2Fs" or "ReIsEr3Fs". Nobody is
going to include such a string by accident in his code.

Regards,
Carl-Daniel




More information about the coreboot mailing list