[coreboot] [RFC] coreboot image marker

[Carl-Daniel Hailfinger]

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?
The v3 patch below illustrates the idea, but it does not yet fill in the
pointer.

Index: arch/x86/stage0_common.S
===================================================================
--- arch/x86/stage0_common.S	(Revision 1065)
+++ arch/x86/stage0_common.S	(Arbeitskopie)
@@ -156,10 +156,12 @@
 	 * instead of the weird 16 bit relocations that binutils does not
 	 * handle consistenly between versions because they are used so rarely.
 	 */
-.byte	0
+	/* 3 filler bytes to have the signature at 0xfffff8. */
+.byte	0,0,0
 
-/* Date? ID string? We might want to put something else in here. */
-.ascii DATE
+/* Signature together with a pointer to a struct with more information. */
+.ascii "cb30"
+.long 0
 
 /* Checksum. */
 /* .word 0 */


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/