Re: [U-Boot] [PATCH v5 0/9] Fix CVE-2018-18440 and CVE-2018-18439
On Fri, Dec 14, 2018 at 02:06:38PM +0100, Simon Goldschmidt wrote:
> On Tue, Dec 11, 2018 at 10:05 PM Simon Goldschmidt
> 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 0200
> > >>> 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 0x.
> > >>> 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=0x 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 0x.
> >
> > 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 = 0x3b40
> > >
> > > 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 0200
> > > lmb_dump_all:
> > > memory.cnt = 0x1
> > > memory.size = 0x0
> > > memory.reg[0x0].base = 0x0
> > > .size = 0x3b40
> > >
> > > 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:
Re: [U-Boot] [PATCH v5 0/9] Fix CVE-2018-18440 and CVE-2018-18439
On Tue, Dec 11, 2018 at 10:05 PM Simon Goldschmidt
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 0200
> >>> 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 0x.
> >>> 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=0x 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 0x.
>
> 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 = 0x3b40
> >
> > 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 0200
> > lmb_dump_all:
> > memory.cnt = 0x1
> > memory.size = 0x0
> > memory.reg[0x0].base = 0x0
> > .size = 0x3b40
> >
> > 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 0x.
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
Re: [U-Boot] [PATCH v5 0/9] Fix CVE-2018-18440 and CVE-2018-18439
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 0200
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 0x.
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=0x 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 0x.
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 = 0x3b40
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 0200
lmb_dump_all:
memory.cnt= 0x1
memory.size = 0x0
memory.reg[0x0].base = 0x0
.size = 0x3b40
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 0x.
Failed using fdt_high value for Device Treelmb_dump_all:
memory.cnt= 0x1
memory.size = 0x0
memory.reg[0x0].base = 0x0
.size = 0x3b40
reserved.cnt = 0x3
reserved.size = 0x0
reserved.reg[0x0].base = 0x0
.size = 0x1000
reserved.reg[0x1].base = 0x108
.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
Re: [U-Boot] [PATCH v5 0/9] Fix CVE-2018-18440 and CVE-2018-18439
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.
>
> >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 0200
> >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 0x.
> >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=0x 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 0x.
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 = 0x3b40
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 0200
lmb_dump_all:
memory.cnt = 0x1
memory.size= 0x0
memory.reg[0x0].base = 0x0
.size = 0x3b40
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 0x.
Failed using fdt_high value for Device Treelmb_dump_all:
memory.cnt = 0x1
memory.size= 0x0
memory.reg[0x0].base = 0x0
.size = 0x3b40
reserved.cnt = 0x3
reserved.size = 0x0
reserved.reg[0x0].base = 0x0
.size = 0x1000
reserved.reg[0x1].base = 0x108
.size = 0xd83000
reserved.reg[0x2].base = 0x3af46b10
.size = 0x4b94f0
FDT creation failed! hanging...### ERROR ### Please RESET the board ###
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/9] Fix CVE-2018-18440 and CVE-2018-18439
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 0200
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 0x.
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=0x 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
>From f004736d14725cc210ac39b974214082622081d3 Mon Sep 17 00:00:00 2001
From: Simon Goldschmidt
Date: Tue, 11 Dec 2018 16:18:07 +0100
Subject: [PATCH] CVE-2018-18440: debug lmb failure
---
common/image-fdt.c | 1 +
lib/lmb.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 5c0d6db3fe..2d7e3237ea 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -186,6 +186,7 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree,
ulong *of_size)
(ulong)desired_addr);
if (of_start == NULL) {
puts("Failed using fdt_high value for Device
Tree");
+ lmb_dump_all(lmb);
goto error;
}
} else {
diff --git a/lib/lmb.c b/lib/lmb.c
index ba680f883e..c4539c461d 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -5,7 +5,7 @@
* Peter Bergner, IBM Corp.June 2001.
* Copyright (C) 2001 Peter Bergner.
*/
-
+#define DEBUG
#include
#include
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/9] Fix CVE-2018-18440 and CVE-2018-18439
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
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 0200
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 0x.
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=0x does resolve the issue and I can boot,
but it's still a case we need to fix. Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 0/9] Fix CVE-2018-18440 and CVE-2018-18439
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.
Changes in v4:
- added tests for lib/lmb.c
- fixed bug in lmb.c when ram is at the end of 32-bit address range
- fixed a bug in lmb_alloc_addr when resulting reserved rangesa get
combined
Changes in v4:
- fixed invalid 'if' statement without braces in boot_fdt_reserve_region
- removed patch 7 ("net: remove CONFIG_MCAST_TFTP), adapted patch 8
Changes in v3:
- No patch changes, but needed to resend since patman added too many cc
addresses that gmail seemed to detect as spam :-(
Changes in v2:
- added code to reserve devicetree reserved-memory in lmb
- added tftp fixes (patches 7 and 8)
- fixed a bug in new function lmb_alloc_addr
Simon Goldschmidt (9):
test: add test for lib/lmb.c
lmb: fix allocation at end of address range
lib: lmb: reserving overlapping regions should fail
fdt: parse "reserved-memory" for memory reservation
lib: lmb: extend lmb for checks at load time
fs: prevent overwriting reserved memory
bootm: use new common function lmb_init_and_reserve
lmb: remove unused extern declaration
tftp: prevent overwriting reserved memory
common/bootm.c | 8 +-
common/image-fdt.c | 53 -
fs/fs.c| 56 -
include/lmb.h | 7 +-
lib/lmb.c | 98 ++--
net/tftp.c | 66 +-
test/lib/Makefile | 1 +
test/lib/lmb.c | 561 +
8 files changed, 805 insertions(+), 45 deletions(-)
create mode 100644 test/lib/lmb.c
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
