On Tue, Dec 11, 2018 at 10:05 PM Simon Goldschmidt
<simon.k.r.goldschm...@gmail.com> wrote:
>
> Am 11.12.2018 um 21:10 schrieb Tom Rini:
> > On Tue, Dec 11, 2018 at 04:19:44PM +0100, Simon Goldschmidt wrote:
> >> 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.
>
> The function 'fdt_get_resource' was the only match that I could find to
> decode register address + size from fdt. However, it resides in
> 'lib/fdtdec.c' which is only linked for OF_CONTROL. This seems strange
> as it is a read-access function to a dts and it can be used when
> booting, too. What would be the way to go here, move this to a different
> file or compile 'lib/fdtdec.c' depending on CONFIG_FIT or something?
>
> 2nd fail seems to be in 'test/py' tests. I'll dig into that, too.
>
> >>
> >>> 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?
> >
> > Here. Note that I'm sure you can replicate this anywhere by setting
> > initrd_high / fdt_high to 0xffffffff.
>
> OK, thanks for this additional output. I cannot reproduce this in the
> tests though. I'll have to check this with my hardware probably, but I
> hope it's not related to 64 bit...
>
> Regards,
> Simon
>
> > U-Boot> run bootcmd
> > switch to partitions #0, OK
> > mmc0 is current device
> > Scanning mmc 0:1...
> > Found U-Boot script /boot.scr
> > lmb_dump_all:
> > memory.cnt = 0x1
> > memory.size = 0x0
> > memory.reg[0x0].base = 0x0
> > .size = 0x3b400000
> >
> > reserved.cnt = 0x2
> > reserved.size = 0x0
> > reserved.reg[0x0].base = 0x0
> > .size = 0x1000
> > reserved.reg[0x1].base = 0x3af46e50
> > .size = 0x4b91b0
> > 389 bytes read in 28 ms (12.7 KiB/s)
> > ## Executing script at 02000000
> > lmb_dump_all:
> > memory.cnt = 0x1
> > memory.size = 0x0
> > memory.reg[0x0].base = 0x0
> > .size = 0x3b400000
> >
> > reserved.cnt = 0x2
> > reserved.size = 0x0
> > reserved.reg[0x0].base = 0x0
> > .size = 0x1000
> > reserved.reg[0x1].base = 0x3af46a20
> > .size = 0x4b95e0
> > 13298176 bytes read in 746 ms (17 MiB/s)
> > ## Flattened Device Tree blob at 2effb500
> > Booting using the fdt blob at 0x2effb500
> > ERROR: Failed to allocate 0x7ab5 bytes below 0xffffffff.
Tom, this looks strange. You said you're running this in 64-bit mode
but here, fdt_high seems to be all ones in the lower 32 bit only.
That's probably because you're running both 32bit and 64bit on the
same target and that 'fdt_high' value got loaded with the environment?
Anyway, this was the reason I haven't found it. I did find it now and
it's a bug that's been in lmb.c like forever. I'll send a v6 soon.
Regards,
Simon
> > Failed using fdt_high value for Device Treelmb_dump_all:
> > memory.cnt = 0x1
> > memory.size = 0x0
> > memory.reg[0x0].base = 0x0
> > .size = 0x3b400000
> >
> > reserved.cnt = 0x3
> > reserved.size = 0x0
> > reserved.reg[0x0].base = 0x0
> > .size = 0x1000
> > reserved.reg[0x1].base = 0x1080000
> > .size = 0xd83000
> > reserved.reg[0x2].base = 0x3af46b10
> > .size = 0x4b94f0
> > FDT creation failed! hanging...### ERROR ### Please RESET the board ###
> >
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
