Hi Tom,
[truncated the CC list a bit since I got "too many recipients" errors last time]
Am 11.12.2018 um 14:31 schrieb Tom Rini:
On Sun, Dec 09, 2018 at 09:45:13PM +0100, Simon Goldschmidt wrote:
This series fixes CVE-2018-18440 ("insufficient boundary checks in filesystem image load") by adding restrictions to the 'load' command and fixes CVE-2018-18439 ("insufficient boundary checks in network image boot") by adding restrictions to the tftp code. The functions from lmb.c are used to setup regions of allowed and reserved memory. Then, the file size to load is checked against these addresses and loading the file is aborted if it would overwrite reserved memory.
The memory reservation code is reused from bootm/image.
So, thanks for doing all of this. I'm sorry to dump a few problems on you now however. First, we have a lot of fail to builds: https://travis-ci.org/trini/u-boot/builds/466333708
Ok, I'll check those. At first sight, the build errors seem to be identical in that 'fdt_get_resource' is missing. I'll check that config option.
Second, giving this a run-time test on Raspberry Pi 3 (aarch64 mode) and trying to boot a regular Linux distro (this example is OpenEmbedded based but generic issue, boot.scr just loads Image to $loadaddr and booti's): U-Boot> run bootcmd switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 389 bytes read in 2 ms (189.5 KiB/s) ## Executing script at 02000000 13298176 bytes read in 701 ms (18.1 MiB/s) ## Flattened Device Tree blob at 2effb500 Booting using the fdt blob at 0x2effb500 ERROR: Failed to allocate 0x7ab5 bytes below 0xffffffff. Failed using fdt_high value for Device TreeFDT creation failed! hanging...### ERROR ### Please RESET the board ###
Switching the board to using bootm_size rather than initrd_high/fdt_high=0xffffffff does resolve the issue and I can boot, but it's still a case we need to fix. Thanks!
Thanks for testing! Of course it's a case we need to fix! Would it be possible for you to do this run-time test again with the attached patch that enables DEBUG in lmb.c and dumps 'lmb' contents in the error case shown above?
Regards, Simon