[LinuxBIOS] [PATCH] v3: lar header walk off-by-one

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Thu Sep 27 17:59:15 CEST 2007

On 26.09.2007 18:11, ron minnich wrote:
> On 9/26/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> OK, this patch is not for the weak of hart because it touches some logic
>> we had lots of problems with in the past.
>> Basically, the lar archive header walk will not see a header at the end
>> of the archive if nothing is after that header. However, since a file
>> with zero size is a legal lar member, we really can't forbid to look at
>> a header terminating the archive.
> I need to be convinced that there is any value if having a header for
> a zero-length file at the very end of the archive. I think this is way
> more capability than we need, and I am very paranoid about LAR, given
> the subtle bugs that we have had. Otherwise, I would rather not commit
> this.

I have a case where this is needed if we don't want to maintain two
different lar archive formats:
AFAIK not all architectures start executing code at the top of ROM, some
start at the bottom (low address). In that case, we can't start the
archive with a LAR header, but we can end it with one. We could redefine
offset as signed instead of unsigned and make the last lar header point
to the boot block at the beginning. That way, even bottom boot
architectures can use the current format unless the flash size is >2GB.

Current LAR archives look like this:

Hn=header n
Dn=data n
where the last bytes of D2 are executed after poweron.

The patch (together with signed offset) would make archives like the
below one possible:
D0D0D0H1D1----H2D2D2H0 (header at end of archive points to boot block)
or this one:
D0D0D0H0H1D1----H2D2D2 (header after boot block points to boot block)

Both new archives allow placing a boot block at the beginning without
sacrificing the goal of one common archive format. However, there are
two potential problems:
- endless loops if we aren't careful when walking the LAR
- "nobody will need more than 640kB", in our case it would be 2GB


More information about the coreboot mailing list