[U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push

[Simon Goldschmidt]

Hi,

Am Fr., 18. Jan. 2019, 07:29 hat Stephen Warren <swarren at wwwdotorg.org>
geschrieben:

> On 1/17/19 6:15 PM, Tom Rini wrote:
> > On Thu, Jan 17, 2019 at 05:50:27PM -0700, Stephen Warren wrote:
> >> On 1/17/19 5:42 PM, Tom Rini wrote:
> >>> On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote:
> >>>
> >>>> Tom,
> >>>>
> >>>> The recent set of patches pushed to u-boot/master cause DFU failures
> on both
> >>>> Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU
> test) with
> >>>> the following in the log:
> >>>>
> >>>> host:
> >>>> dfu-util -a 0 -U
> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin
> >>>> -p 3-2.3
> >>>>
> >>>> target:
> >>>> ** Reading file would overwrite reserved memory **
> >>>> dfu: Read error!
> >>>> dfu_read: Failed to fill buffer
> >>>> Tegra124 (Jetson TK1) #
> >>>>
> >>>> I noticed some lmb fixes in the list, so I guess it's due to that.
> >>>
> >>> So.. intentional!  Adding in Simon here, but I think the short answer
> is
> >>> that you need to change where you're saying the file goes in memory.
> >>> FWIW I run the DFU test on my dra7xx_evm and it's passing.
>

I'll try to help clarifying this, but I won't have access to a PC until
Monday.

Regards,
Simon

>>
> >> You applied a change which intentionally broke functionality??? That
> sounds
> >> pretty bad...
> >
> > So, yes.  A design decision / feature of "don't check where we're
> > loading payloads to" is also a security vulnerability to bypass secure
> > boot.  So we now have changes in that make a good attempt at keeping us
> > from loading a payload that can in turn overwrite ourself.  And I merged
> > it super early in the merge window to try and catch the unintended
> > consequences.
> >
> >> Looking at the precise test that failed, we don't actually specify
> where the
> >> data goes in memory; it's written to the filesystem and all memmory
> >> locations are internally allocated by U-Boot. So when you say "you need
> to
> >> change where you're saying the file goes in memory", do you mean via
> the DFU
> >> altinfo variable (which does not specify a memory location in this
> case, so
> >> I can't), or by modifying some board-/SoC-specific config file or code
> to
> >> specify where DFU buffers data (in which case, I'd argue that a
> >> backwards-compatible default should have been put in place to prevent
> >> breaking functionality)?
> >>
> >> The DFU altinfo values that are tested on both boards are:
> >>
> >> Fails:
> >>
> >> Device mmc 1 (which is an SD card):
> >> "alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1",
>
>         "test_sizes": (
>             64 - 1,
>             64,
>             64 + 1,
>             4096 - 1,
>         ),
>     },
>
> >> All pass:
> >>
> >> Device mmc 1 (which is an SD card):
> >> "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1",
>
>         "test_sizes": (
>             128 - 1,
>             128,
>             128 + 1,
>             4096,
>         ),
>
> >> Device mmc 1 (which is an SD card):
> >> "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1",
>
>         "test_sizes": (
>             960 - 1,
>             960,
>             960 + 1,
>             4096 + 1,
>         ),
>
> >> Device ram
> >> "alt_info": "alt0 ram 80000000 01000000;alt1 ram 81000000 01000000",
>
>         "test_sizes": (
>             1024 * 1024 - 1,
>             1024 * 1024,
>             8 * 1024 * 1024,
>         ),
>
> > So that's interesting.  How big is dfu_test.bin?  Checking my config, I
> > don't have SD card only RAM.  If you do RAM only tests does it pass (as
> > that might narrow down where maybe something is wrong) ?
>
> Yes, that RAM-only test passes. The tests are run in the order listed
> above.
>
> test_dfu.py iterates over a bunch of different file sizes; I listed them
> below the DFU configs above.
>