[coreboot] [RFC] coreboot image marker

[Jordan Crouse]

Carl-Daniel Hailfinger wrote:
> I'd like to introduce a reasonably safe way to detect whether an image
> is a coreboot image.
> 
> Goals:
> - Easy to implement
> - Good for visual inspection of a image file with hexdump
> - Fixed location to make detection easy
> - Independence of the format of the image data
> - Reusable even if we decide to change the image data format completely
> 
> The existing solutions and approached do not fulfill all (or even any)
> of the goals above.
> 
> Proposal:
> Use the top 8 bytes of an image to store a short signature and a pointer
> to the real data. If the signature is 4 bytes and the pointer is 4
> bytes, they fit exactly into the range 0xfffffff8-0xffffffff.
> The reset vector lives at 0xfffffff0 and it is a jump instruction with
> immediate operand. The instruction is 1 byte, the operand is 2 bytes
> (well, 4 bytes in reality due to binutils workarounds, but as the code
> is 16bit, only the first two bytes are evaluated). The space after the
> reset vector is not usable for code because you could only fit ~2-3
> instructions there before needing another jump and that would complicate
> things a lot. So anything from 0xfffffff3 onwards (0xfffffff5 onwards if
> you consider the binutils workaround) is fair game for a signature or
> any other helpful construct.
> The LAR utility stores the 32-bit length of the archive at 0xfffffff4.
> That means the space 0xfffffff8-0xffffffff is up for grabs.
> 
> We could use the top 8 bytes for the following signature:
> 0xfffffff8-0xfffffffb: String (not NULL terminated) 'cb30'
> 0xfffffffc-0xffffffff: Relative location/pointer to a to-be-designed struct
> 
> This has the advantage of separating the information storage format from
> locating the information. If the string is 'cb30', follow the pointer
> and try to understand the storage format. If you can't decipher the
> storage format, you know that it is a coreboot image with an
> unsupported/unknown information storage format and you can tell the user
> to upgrade flashrom or whatever tool he/she is using to work on that image.
> We could even use the pointer to point to existing image information in
> v2 (which is currently searched for with exceessively ugly heuristics)
> and point to a LAR entry in v3 as needed.
> 
> Thoughts? Comments?

If you do this, then you can get rid of the length at 0xfffffff4 and put 
the pointer there.  All the ROM information should be contained in one 
place.  The pointer should point to a master information header, 
including, but not limited to:

Magic
ROM size
block alignment
start of the LAR data in the ROM (it might not always be at 0)

In addition, the structure could contain things like:

Date/time the ROM was created
Description (e.g. "CBV3+coreinfo")
Target architecture information
Flashrom identifiers, etc, etc.

I think its fine to have one header to rule them all - LAR information 
can probably coexist with the other stuff, even if it is unused in v2. 
if it is a concern, you can probably turn the master header into a list 
of lists (e.g - magic, pointer to coreboot header, pointer to LAR 
header) but I think thats probably needs more real estate then we want 
to spend.

LAR desperately needs this - a master header would solve problems in 
multiple fields at once.

Jordan