[U-Boot] (patch) segfault when calling fit_check_format() on corrupt FIT images

[Jon Nalley]

On Mon, Mar 8, 2010 at 11:07 AM, Detlev Zundel <dzu at denx.de> wrote:
> We are a bit reluctant to accept changes here as this is shared code
> with the 'dtc' device tree compiler[1].

Understandable.

> Also when glancing over the code, it seems like there may be more places
> where a corrupt fdt may backfire so this makes me also sceptic if this
> single fix is a useful thing.

I agree.  It looks like there might be more than one case where a non
null terminated string could cause problems.

> Stepping back a little bit, I don't even know why we should trap such a
> problem at all - after all while developing we have quite a few
> possibilities to shoot ourselves in the foot.  In a production system
> such a thing should not happen and if it does, it will be caught by a
> sensible infrastructure and e.g. a hardware watchdog.

In our environment we have redundant FIT images in flash.  This issue
was caught by one of our testers who was purposely powering off the
device during a firmware upgrade (in order to test the redundancy).
The segfault is observed after rebooting to the remaining "good" image
and invoking a command that calls fit_check_format().  The issue
occurs after the flash has been erased, since in this case the erased
flash is all 1's no terminating null character is ever found.

My goal is to be able to determine (while in Linux) if one of the two
firmware images in flash is corrupt or not.  Although our platform
supports a hardware watchdog, I am unclear how it could solve this
particular problem?  Granted, this is a fairly obscure case and it is
not likely that users will be powering off hardware during firmware
upgrades, but I wanted to at least describe the scenario to see what
others might think.  I would appreciate any suggestions for other
methods of determining if a FIT image in flash is valid or not.

> On the other hand if you do insist on your change, then pleas send git
> patches as written in the documentation[2].

Sorry about that.  I will submit any further patches as per the documentation.

Regards,

Jon Nalley