Am 14.04.2014 17:38, schrieb Kees Cook:
On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer <weiss...@arcor.de> wrote:
Am 14.04.2014 08:09, schrieb Matthias Weißer:

Hi Wolfgang

Am 11.04.2014 12:43, schrieb Wolfgang Denk:

Dear Matthias,

In message <5347bbbc.9000...@arcor.de> you wrote:


we are currently trying to get an out-of-tree board based on 2013.01
back in sync with current master and observing a strange behavior which
we think is located in the CFI flash system. If we load an image via
tftp, copy it to flash and then try to run the image via bootm we see an
error while decomressing:

...

    Uncompressing Kernel Image ... LZO: uncompress or overwrite error -5


Are you sure your malloc arena is big enough for LZO?  Try if
increasing it helps...


We increaded it from 4MB to 8MB and the behavior is still the same.

We also observed a different behavior when tftping the image to RAM and
then directly executing it without copying it to flash. It seems that
the flash device (EN29GL256H) is then in some a mode (maybe auto-select)
which prevents it from normal read operations which doesn't allow the
flash driver of the OS come up. We never saw this with our old u-boot.
If there are no ideas left we will have to bisect the problem.


Bisecting was successfull. The commit introducing the problem is

commit ff9d2efdbf1b3b5263f81e843c6724b8bead7f1f
Author: Kees Cook <keesc...@chromium.org>
Date:   Fri Aug 16 07:59:15 2013 -0700

    lzo: correctly bounds-check output buffer

    This checks the size of the output buffer and fails if it was going to
    overflow the buffer during lzo decompression.

    Signed-off-by: Kees Cook <keesc...@chromium.org>
    Acked-by: Simon Glass <s...@chromium.org>

This commit introduced the usage of the dst_len output parameter as
additional input parameter containing the maximum output buffer size. This
parameter isn't initialized in cmd_bootm.c:

 454 #ifdef CONFIG_LZO
 455     case IH_COMP_LZO: {
 456         size_t size;
 457
 458         printf("   Uncompressing %s ... ", type_name);
 459
 460         ret = lzop_decompress(image_buf, image_len, load_buf, &size);

Setting size to some big value (SZE_MAX is not avialable) fixed the behavior
but I am unsure if this is the correct solution. I think its hard to get the
max output buffer size at this point in cmd_bootm.c.

Does this work?

Yes. Didn't saw that configuration option. Thanks.

---
From: Kees Cook <keesc...@chromium.org>
Subject: [PATCH] bootm: set max output for LZO

The LZO decompressor wasn't initializing the maximum output size.

Reported-by: Matthias Weißer <weiss...@arcor.de>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
  common/cmd_bootm.c |    2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 9751edc..c243a5b 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -453,7 +453,7 @@ static int bootm_load_os(bootm_headers_t *images,
unsigned long *load_end,
  #endif /* CONFIG_LZMA */
  #ifdef CONFIG_LZO
         case IH_COMP_LZO: {
-               size_t size;
+               size_t size = unc_len;

                 printf("   Uncompressing %s ... ", type_name);


Tested-by: Matthias Weißer <weiss...@arcor.de>

Regards
Matthias
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to