Hi, Am Fr., 18. Jan. 2019, 07:29 hat Stephen Warren <swar...@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. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot