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