Patchwork [U-Boot] tools: default image: use ih_size for checking data size

login
register
mail settings
Submitter Jonas Gorski
Date May 3, 2013, 11:37 a.m.
Message ID <1367581025-26740-1-git-send-email-jogo@openwrt.org>
Download mbox | patch
Permalink /patch/241306/
State Rejected
Delegated to: Wolfgang Denk
Headers show

Comments

Jonas Gorski - May 3, 2013, 11:37 a.m.
Common image usage is uImage + appended rootfs, so the the uImage data
is only part of the total image. So read out and use the header's
ih_size field instead of the total file size.

To prevent reading over the end of the buffer, check that the image file
is big enough to contain the data before calculating its checksum.

Before:
~# mkimage -l dir665_fw_100NA.bin
mkimage: ERROR: "dir665_fw_100NA/dir665_fw_100NA.bin" has corrupted data!

After:
~# mkimage -l dir665_fw_100NA.bin
Image Name:   Linux Kernel Image
Created:      Fri Feb 12 03:38:36 2010
Image Type:   ARM Linux Kernel Image (lzma compressed)
Data Size:    1107781 Bytes = 1081.82 kB = 1.06 MB
Load Address: 00008000
Entry Point:  00008000

Signed-off-by: Jonas Gorski <jogo@openwrt.org>
---
 tools/default_image.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
Wolfgang Denk - May 3, 2013, 3:04 p.m.
Dear Jonas Gorski,

In message <1367581025-26740-1-git-send-email-jogo@openwrt.org> you wrote:
> Common image usage is uImage + appended rootfs, so the the uImage data

No, this is not at all "common usage".  Actually this something you
should never do.

> is only part of the total image. So read out and use the header's
> ih_size field instead of the total file size.
> 
> To prevent reading over the end of the buffer, check that the image file
> is big enough to contain the data before calculating its checksum.
> 
> Before:
> ~# mkimage -l dir665_fw_100NA.bin
> mkimage: ERROR: "dir665_fw_100NA/dir665_fw_100NA.bin" has corrupted data!

Sorry, I don't know how you create your image files, but you must be
doing something fundamentally wrong.  If mkimage reports a bug here,
it is probably right.  If the actual payload size is different from
the content of the  ih_size  field, then your image _is_ broken.

NAK.

Best regards,

Wolfgang Denk
Jonas Gorski - May 3, 2013, 3:42 p.m.
On Fri, 03 May 2013 17:04:44 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Jonas Gorski,
> 
> In message <1367581025-26740-1-git-send-email-jogo@openwrt.org> you
> wrote:
> > Common image usage is uImage + appended rootfs, so the the uImage
> > data
> 
> No, this is not at all "common usage".  Actually this something you
> should never do.
> 
> > is only part of the total image. So read out and use the header's
> > ih_size field instead of the total file size.
> > 
> > To prevent reading over the end of the buffer, check that the image
> > file is big enough to contain the data before calculating its
> > checksum.
> > 
> > Before:
> > ~# mkimage -l dir665_fw_100NA.bin
> > mkimage: ERROR: "dir665_fw_100NA/dir665_fw_100NA.bin" has corrupted
> > data!
> 
> Sorry, I don't know how you create your image files, but you must be
> doing something fundamentally wrong.  If mkimage reports a bug here,
> it is probably right.  If the actual payload size is different from
> the content of the  ih_size  field, then your image _is_ broken.

That what else for is the ih_size field then except to say what the
actual datasize is? mkuimage also sets this fields to the
correct size.

And this isn't from me, but this is how most firmware images are
created for devices using U-Boot, i.e. uImage packed kernel + appended
rootfs. Also U-Boot itself only cares for the first ih_size bytes of the
image and not for any "garbage" that might be behind it:

int image_check_dcrc(const image_header_t *hdr)
{
	...
	ulong len = image_get_data_size(hdr);
	...
	ulong dcrc = crc32_wd(...,len,...);
	...
}

static inline uint32_t image_get_data_size(const image_header_t *hdr)
{
	return image_get_size(hdr); /* == hdr->ih_size */
}

It checks the crc of the first ih_size bytes after the image_header -
and my change changes mkimage to mirror that behaviour.
It still reports data errors if the checksum is wrong for the data
actually specified by the image header, but now it actually respects
the length of the data field.

One might even argue that it is now *more* correct, because I can
can easily construct you an image that will pass the "old" mkimage, but
will be rejected by U-Boot, by creating a different length payload
that has the same crc32 as expected by the header.


Best regards
Jonas Gorski
Wolfgang Denk - May 3, 2013, 3:54 p.m.
Dear Jonas Gorski,

In message <20130503174205.00000070@unknown> you wrote:
>
> > Sorry, I don't know how you create your image files, but you must be
> > doing something fundamentally wrong.  If mkimage reports a bug here,
> > it is probably right.  If the actual payload size is different from
> > the content of the  ih_size  field, then your image _is_ broken.
> 
> That what else for is the ih_size field then except to say what the
> actual datasize is? mkuimage also sets this fields to the
> correct size.

It's exactly for this very purpose, and allows for consistency
checking.  You run into errors, becuase your images are not correct.
For plain legacy image format (i. e. we are not talking about
multi-file image format here), header size (= 64 bytes) plus the
content of the ih_size  field will give the total file size of the
image.  If this condition is not met, then your image is broken.

> And this isn't from me, but this is how most firmware images are

Define "most".

> created for devices using U-Boot, i.e. uImage packed kernel + appended
> rootfs. Also U-Boot itself only cares for the first ih_size bytes of the
> image and not for any "garbage" that might be behind it:

Yes, because in U-Boot we have no notion of "files" and thus no
indication where an image ends.  Otherwise such a check would be
there.

> It checks the crc of the first ih_size bytes after the image_header -
> and my change changes mkimage to mirror that behaviour.

But this is wrong.

> It still reports data errors if the checksum is wrong for the data
> actually specified by the image header, but now it actually respects
> the length of the data field.

Let me repeat: a valid image will have sizeof(struct image_header)
plus ih_size == file size.  If this condition is not true, then your
image is broken.


Best regards,

Wolfgang Denk
Jonas Gorski - May 3, 2013, 4:31 p.m.
On Fri, 03 May 2013 17:54:25 +0200
Wolfgang Denk <wd@denx.de> wrote:

> Dear Jonas Gorski,
> 
> In message <20130503174205.00000070@unknown> you wrote:
> >
> > > Sorry, I don't know how you create your image files, but you must
> > > be doing something fundamentally wrong.  If mkimage reports a bug
> > > here, it is probably right.  If the actual payload size is
> > > different from the content of the  ih_size  field, then your
> > > image _is_ broken.
> > 
> > That what else for is the ih_size field then except to say what the
> > actual datasize is? mkuimage also sets this fields to the
> > correct size.
> 
> It's exactly for this very purpose, and allows for consistency
> checking.  You run into errors, becuase your images are not correct.
> For plain legacy image format (i. e. we are not talking about
> multi-file image format here), header size (= 64 bytes) plus the
> content of the ih_size  field will give the total file size of the
> image.  If this condition is not met, then your image is broken.
> 
> > And this isn't from me, but this is how most firmware images are
> 
> Define "most".

Most images I have seen for kirkwood, ar71xx, ralink, and I'm sure
there are more.

> > created for devices using U-Boot, i.e. uImage packed kernel +
> > appended rootfs. Also U-Boot itself only cares for the first
> > ih_size bytes of the image and not for any "garbage" that might be
> > behind it:
> 
> Yes, because in U-Boot we have no notion of "files" and thus no
> indication where an image ends.  Otherwise such a check would be
> there.
> 
> > It checks the crc of the first ih_size bytes after the image_header
> > - and my change changes mkimage to mirror that behaviour.
> 
> But this is wrong.

But that's what U-Boot does. The quoted code is taken straight from
git. My impression was that if U-Boot accepts this image, then mkimage
should, too.

> > It still reports data errors if the checksum is wrong for the data
> > actually specified by the image header, but now it actually respects
> > the length of the data field.
> 
> Let me repeat: a valid image will have sizeof(struct image_header)
> plus ih_size == file size.  If this condition is not true, then your
> image is broken.

Okay, after a bit of IRC discussion the following compromise:

If the header is correct, and the crc is correct for the ih_size data,
then assume everything is fine, but print out a warning if the file
length does not match the header lengh + ih_size.

My typical use case would be looking at vendor images or flashdumps and
check if they have a valid uimage header. With this patch I can do
it easily with the imagefile/flashdump, without it I would need to parse
the header first manually, find the ih_size field, truncate the file to
the expected size, and then hope the header is valid.


Best regards,
Jonas Gorski
Wolfgang Denk - May 3, 2013, 7:13 p.m.
Dear Jonas Gorski,

In message <20130503183128.00000900@unknown> you wrote:
>
> > > And this isn't from me, but this is how most firmware images are
> > 
> > Define "most".
> 
> Most images I have seen for kirkwood, ar71xx, ralink, and I'm sure
> there are more.

Maybe these do - but these are a tiny, virtually invisible minority of
the platforms supported in mainline.

> > Yes, because in U-Boot we have no notion of "files" and thus no
> > indication where an image ends.  Otherwise such a check would be
> > there.
> > 
> > > It checks the crc of the first ih_size bytes after the image_header
> > > - and my change changes mkimage to mirror that behaviour.
> > 
> > But this is wrong.
> 
> But that's what U-Boot does. The quoted code is taken straight from
> git. My impression was that if U-Boot accepts this image, then mkimage
> should, too.

I explained this before: in U-Boot we have no way to figure out the
total size (or "file size") as there is no such concept as files.
For U-Boot, an image is only identified by it's start address in
memory, but we have no length information available, so how could we
check it?

> Okay, after a bit of IRC discussion the following compromise:
> 
> If the header is correct, and the crc is correct for the ih_size data,
> then assume everything is fine, but print out a warning if the file
> length does not match the header lengh + ih_size.

No, this was not exactly what we discussed.  I wrote:

| I suggest you change mkimage such that it will display the (valid)
| image data, but then bail out with a "NNN bytes excess data present"
| error message.  Note that mkimage must return an error code (EFAILURE)
| in this case.

So no warning, but an error, please.  And only for excess lenght.

If the length is too short, we are really in trouble, especially if
the CRC still matches.  This should never happen.


Best regards,

Wolfgang Denk
Peter Korsgaard - May 7, 2013, 3:16 p.m.
>>>>> "Jonas" == Jonas Gorski <jogo@openwrt.org> writes:

 Jonas> Common image usage is uImage + appended rootfs, so the the uImage data
 Jonas> is only part of the total image. So read out and use the header's
 Jonas> ih_size field instead of the total file size.

 Jonas> To prevent reading over the end of the buffer, check that the image file
 Jonas> is big enough to contain the data before calculating its checksum.

 Jonas> Before:
 Jonas> ~# mkimage -l dir665_fw_100NA.bin
 Jonas> mkimage: ERROR: "dir665_fw_100NA/dir665_fw_100NA.bin" has corrupted data!

A related usecase is checking the version info of whatever is written to
flash - E.G.

mkimage -l /dev/mtdN

But that already fails as stat returns st_size=0 for devices.

Patch

diff --git a/tools/default_image.c b/tools/default_image.c
index e9d0729..db20e53 100644
--- a/tools/default_image.c
+++ b/tools/default_image.c
@@ -86,10 +86,11 @@  static int image_verify_header(unsigned char *ptr, int image_size,
 	}
 
 	data = (const unsigned char *)ptr + sizeof(image_header_t);
-	len  = image_size - sizeof(image_header_t) ;
+	len  = be32_to_cpu(hdr->ih_size);
 
 	checksum = be32_to_cpu(hdr->ih_dcrc);
-	if (crc32(0, data, len) != checksum) {
+	if ((image_size - sizeof(image_header_t)) < len ||
+	    crc32(0, data, len) != checksum) {
 		fprintf(stderr,
 			"%s: ERROR: \"%s\" has corrupted data!\n",
 			params->cmdname, params->imagefile);