Jerry Van Baren wrote:

Wolfgang Denk wrote:

...

Hello,

I'm trying to figure out what could be done to add (at least in some cases) more information to U-Boot images.

In this case, the existing CRC32 checksum is not sufficient; therequirement is to use some stronger hashes (md5 or sha1) to verify the correctness of the kernel and file system images.

A similar thing happened not so long ago when we discussed how to add the OFT blob.

Here some thoughts:

• The original 64 byte header is tabu and cannot be changed to provide

compatibility to existing versions.

• A quick & dirty hack could use a multi-file image to add - for

example - the SHA1 checksum as separate image in addition to the kernel (and eventually file system) image(s).

Add an OFT blob, and the confusion is perfect.

Seems we need a more structured approach.

I would like to use this opportunity to collect ideas and suggestions for a more generalized solution that is flexible and extensible enough to handle not only the current , but also future requirements. At least some of them ;-)

All input welcome...

Best regards,

Wolfgang Denk

Two possibilities come to mind for using (abusing) the original 64 byte header:

1. If we put an ASCII-hex hash _as_ the name, we could support a 16 byte

(128 bit) hash. The name would no longer be pronounceable :-P, but it _would_ be unique. An MD5 hash is typically a 32-character hexadecimal number. [Ref: http://en.wikipedia.org/wiki/MD5]

2. The name is 32 bytes. If we trimmed the maximum name length to 28

bytes, we could use the last 4 bytes as a pointer to a hash. Bleah, not much/any better than the multi-file approach.

gvb

What about an image tail?. The last 2 longs of the name could be changed by: u32 tail_magic_number; /* A magic number to detect an image with a tail */ u32 tail_offset; /* Offset to the tail from the image header */

The tail structure will add the new information for the next versions of U-Boot.

Josh Boyer wrote:

On 2/27/07, Wolfgang Denk wd@denx.de wrote:

...

Hello,

I'm trying to figure out what could be done to add (at least in some cases) more information to U-Boot images.

In this case, the existing CRC32 checksum is not sufficient; therequirement is to use some stronger hashes (md5 or sha1) to verify the correctness of the kernel and file system images.

Just curious, but why isn't CRC32 sufficient exactly?

josh

CRC32 is pretty weak with respect to: * Multibit errors: * It will detect all single bit errors - good * It will detect all two bit errors up to a block size that is dependent on the CRC length & polynomial (2KBytes for CRC-32 IIRC, but I may recall incorrectly - much less than a u-boot image size in any case) - bad * It detects some multibit errors but not all of them - bad * Cryptography: it is trivial (cryptographically speaking) to "fix up" the CRC after changing something in the block it is covering - very bad.

Ref: http://en.wikipedia.org/wiki/List_of_checksum_algorithms http://en.wikipedia.org/wiki/Cyclic_redundancy_check

HTH, gvb