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.
>>
>> 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
