Am Fr., 21. Dez. 2018, 13:28 hat Frank Wunderlich frank-w@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" frank-w@public-files.de
Thanks for testing!
Regards, Simon