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

[Tom Rini <trini@konsulko.com>]

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.
> 
> 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",
> 
> All pass:
> 
> Device mmc 1 (which is an SD card):
> "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1",
> 
> Device mmc 1 (which is an SD card):
> "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1",
> 
> Device ram
> "alt_info": "alt0 ram 80000000 01000000;alt1 ram 81000000 01000000",

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) ?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190117/eb4e3877/attachment.sig>