Am Fr., 21. Dez. 2018, 13:28 hat Frank Wunderlich <fran...@public-files.de>
geschrieben:
> tested now v9 with tftp
>
> U-Boot> bd
> arch_number = 0x00000000
> boot_params = 0x80000100
> DRAM bank = 0x00000000
> -> start = 0x80000000
> -> size = 0x80000000
> baudrate = 115200 bps
> TLB addr = 0xFFFF0000
> relocaddr = 0xFFF9B000
> reloc off = 0x7E19B000
> irq_sp = 0xFFB96FF0
> sp start = 0xFFB96FE0
> Early malloc usage: 318 / 4000
> fdt_blob = ffb97000
> U-Boot> tftp 0xFFF9B000 ${serverip}:files.lst
> Using ethernet@1b100000 device
> TFTP from server 192.168.0.10; our IP address is 192.168.0.11
> Filename 'files.lst'.
> Load address: 0xfff9b000
> Loading: #
> TFTP error: trying to overwrite reserved memory...
> U-Boot> tftp 0xFFB96FE0 ${serverip}:files.lst
> Using ethernet@1b100000 device
> TFTP from server 192.168.0.10; our IP address is 192.168.0.11
> Filename 'files.lst'.
> Load address: 0xffb96fe0
> Loading: #
> TFTP error: trying to overwrite reserved memory...
> U-Boot>
>
> works so far
>
> a small remark...i can write with mw data to the "protected areas" and
> bords resets...maybe this should be added in future :) but so far
>
Well, the idea of the CVE was that you can overwrite U-Boot in RAM without
actually having access. You "only" need to control the file system or tftp
server.
When doing 'mw', you actually need to have access to the U-Boot shell.
That's a different level. I'm not sure we need to limit access there...
> Tested-By: "Frank Wunderlich" <fran...@public-files.de>
>
Thanks for testing!
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
