On Sun, Dec 2, 2018 at 6:44 PM Frank Wunderlich <fran...@public-files.de> wrote: > > Right, i test on bananapi-r2. 2gb ram with 0x80000000 base-adress > > Seems you need (unsigned) int64 for calculations
Hmm, I don't know if that's enough. Of course using uint64_t would fix it on 32 bit systems, but I don't like the idea that it's then broken for 64-bit systems allocating something to the end of the address space... The existing lmb functions to check for overlap cannot handle "size + length " overflowing to 0. I might be able to fix that without promoting to the next higher type. Regards, Simon > > Am 2. Dezember 2018 18:14:19 MEZ schrieb Simon Goldschmidt > <simon.k.r.goldschm...@gmail.com>: > >Am 02.12.2018 um 16:48 schrieb Frank Wunderlich: > >> lmb_init: base: 0x80000000, size: 0x80000000 > > > >Ok, so I don't know your board, is that correct? Do you have 2 GByte > >starting at 0x80000000? > > > >If so, that would result in an overflow to 0 on a 32-bit platform and > >would explain why it doesn't work. > > > >This is a perfect input for a test case :-) > > > >Thanks, > >Simon > > > >> > >> > >https://github.com/frank-w/u-boot/commit/e0763252a8e135f00b996fbda7bb1067a192ca53 > >> > >> Regards Frank > >> > >>> Gesendet: Sonntag, 02. Dezember 2018 um 10:24 Uhr > >>> Von: "Simon Goldschmidt" <simon.k.r.goldschm...@gmail.com> > >>> An: "Frank Wunderlich" <fran...@public-files.de> > >>> Cc: u-boot@lists.denx.de > >>> Betreff: Re: [U-Boot] [PATCH v4 0/7] Fix CVE-2018-18440 and > >CVE-2018-18439 > >>> > >>> Am 01.12.2018 um 12:07 schrieb Frank Wunderlich: > >>>> forgot error-message and detailed command: > >>>> > >>>> fatload ${device} ${partition} ${scriptaddr} > >${bpi}/${board}/${service}/${bootenv} > >>>> ** Reading file would overwrite reserved memory ** > >>>> echo ${device} ${partition} ${scriptaddr} > >${bpi}/${board}/${service}/${bootenv} > >>>> mmc 1:1 0x83000000 bananapi/bpi-r2/linux/uEnv.txt > >>>> > >>>> file exists i checked with test, but fatload failed, after > >reverting the Patches same command works > >>> > >>> Hmm, ok. With your configuration, I thought > >'gd->bd->bi_dram[0].start' > >>> and 'gd->bd->bi_dram[0].size' should be populated and correctly > >describe > >>> your DRAM. > >>> > >>> Could you try adding this printf code to the function > >>> 'lmb_init_and_reserve': > >>> > >>> printf("lmb_init: base: 0x%x, size: 0x%x\n", base, size); > >>> > >>> and check if this correctly describes your memory? > >>> > >>> Thanks, > >>> Simon > >>> > >>>> > >>>> regards Frank > >>>> > >>>>> Gesendet: Samstag, 01. Dezember 2018 um 10:46 Uhr > >>>>> Von: "Frank Wunderlich" <fran...@public-files.de> > >>>>> An: "Simon Goldschmidt" <simon.k.r.goldschm...@gmail.com> > >>>>> Cc: u-boot@lists.denx.de > >>>>> Betreff: Re: [U-Boot] [PATCH v4 0/7] Fix CVE-2018-18440 and > >CVE-2018-18439 > >>>>> > >>>>> Hi Simon > >>>>> > >>>>> #define CONFIG_SYS_SDRAM_BASE 0x80000000 > >>>>> > >>>>> > >https://github.com/frank-w/u-boot/blob/a6d0c3f8e992a2e428f05443647fe9f5b13f8634/include/configs/mt7623.h#L47 > >>>>> > >>>>> CONFIG_ARM=y > >>>>> CONFIG_NR_DRAM_BANKS=1 > >>>>> > >https://github.com/frank-w/u-boot/blob/a6d0c3f8e992a2e428f05443647fe9f5b13f8634/configs/mt7623n_bpir2_defconfig#L7 > >>>>> > >>>>> i applied the patch-series on top of my 2018-11 final (currently > >removed from github) > >>>>> > >>>>> https://github.com/frank-w/u-boot/tree/bpi-r2_v5 > >>>>> > >>>>> tried ${scriptaddr}=0x83000000 > >>>>> > >>>>> here the fatload-command: > >>>>> > >>>>> > >https://github.com/frank-w/u-boot/blob/60bc4075c7744e36058fcba76cd6e6c3a4002265/uEnv.txt#L22 > >>>>> > >>>>> working before, 0x81000000 and some higher values > >>>>> > >>>>> HTH > >>>>> > >>>>> regards Frank > >>>>> > >>>>>> Gesendet: Samstag, 01. Dezember 2018 um 10:25 Uhr > >>>>>> Von: "Simon Goldschmidt" <simon.k.r.goldschm...@gmail.com> > >>>>>> An: "Frank Wunderlich" <fran...@public-files.de> > >>>>>> Cc: "U-Boot Mailing List" <u-boot@lists.denx.de> > >>>>>> Betreff: Re: [U-Boot] [PATCH v4 0/7] Fix CVE-2018-18440 and > >CVE-2018-18439 > >>>>>> > >>>>>> On Fri, Nov 30, 2018 at 6:51 PM Frank Wunderlich > >>>>>> <fran...@public-files.de> wrote: > >>>>>>> > >>>>>>> Hi Simon, > >>>>>>> > >>>>>>> after applying these Patch-series i cannot load to any address > >(fatload). Do i need any additional Patch ("fdt: parse > >"reserved-memory" for memory reservation" sounds like that). Maybe > >there should be a fallback if no reservation is defined. > >>>>>> > >>>>>> No, you should not need additional patches. The code makes use of > >>>>>> "lmb" memory allocation just like the "bootm" code does. The > >"memory > >>>>>> reservation" patch you cited only ensures that memory which is > >marked > >>>>>> as reserved in the fdt cannot be overwritten by load. > >>>>>> > >>>>>> If it doesn't work for you at all, the available memory is > >probably > >>>>>> not described correctly. Could you check the values of the > >following > >>>>>> defines (or if they are defined at all): > >>>>>> - CONFIG_SYS_SDRAM_BASE > >>>>>> - CONFIG_ARM > >>>>>> - CONFIG_NR_DRAM_BANKS > >>>>>> > >>>>>> I might need to improve the DRAM detection code in v5 (which is > >still > >>>>>> pending as I am working on lmb tests). > >>>>>> > >>>>>> Regards, > >>>>>> Simon > >>>>>> > >>>>>>> > >>>>>>> regards Frank > >>>>>>> > >>>>>>>> Gesendet: Samstag, 24. November 2018 um 15:11 Uhr > >>>>>>>> Von: "Simon Goldschmidt" <simon.k.r.goldschm...@gmail.com> > >>>>>>>> An: "Tom Rini" <tr...@konsulko.com>, u-boot@lists.denx.de, "Joe > >Hershberger" <joe.hershber...@ni.com> > >>>>>>>> Cc: "Alexey Brodkin" <alexey.brod...@synopsys.com>, "Heinrich > >Schuchardt" <xypron.g...@gmx.de>, "Michal Simek" > ><michal.si...@xilinx.com>, "Alexander Graf" <ag...@suse.de>, "Andrea > >Barisani" <andrea.baris...@f-secure.com> > >>>>>>>> Betreff: [U-Boot] [PATCH v4 0/7] 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: > >>>>>>>> - 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 (7): > >>>>>>>> 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 | 69 > >++++++++++++++++++++++++++++++++++++++++++++++ > >>>>>>>> net/tftp.c | 66 > >++++++++++++++++++++++++++++++++++++++------ > >>>>>>>> 6 files changed, 231 insertions(+), 28 deletions(-) > >>>>>>>> > >>>>>>>> -- > >>>>>>>> 2.17.1 > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> U-Boot mailing list > >>>>>>>> U-Boot@lists.denx.de > >>>>>>>> https://lists.denx.de/listinfo/u-boot > >>>>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> U-Boot mailing list > >>>>> U-Boot@lists.denx.de > >>>>> https://lists.denx.de/listinfo/u-boot > >>>>> > >>> > >>> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot