[U-Boot] Strange CFI flash problem

[Kees Cook]

On Mon, Apr 14, 2014 at 1:51 AM, Matthias Weißer <weisserm at 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.9000806 at 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 <keescook at 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 <keescook at chromium.org>
>     Acked-by: Simon Glass <sjg at 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?

---
From: Kees Cook <keescook at 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 <weisserm at arcor.de>
Signed-off-by: Kees Cook <keescook at 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);

-- 
1.7.9.5



-- 
Kees Cook
Chrome OS Security