<pivi>
marex: no credit for the CVE? you can make some cash $$$$$ adding it to your CV!
* marex
rolls eyes
<marex>
pivi: I even have an exploit ;)
<marex>
more of a PoC really
<marex>
rfs613: some sort of memory corruption ? Start overwrites env area or whatever ?
<marex>
rfs613: check your memory layout
<marex>
rfs613: see cmd/bdinfo.c for details how that should be printed
<pivi>
marex: no doubt about it, is the $$$$ that is missing!
<marex>
pivi: hehehe
<pivi>
marex: by the way, I was finally able to meat fabio in real life last week in Brazil
<marex>
pivi: I think we should start writing our own CVEs though, going through that $company sucked
<marex>
pivi: ooooh nice
<marex>
pivi: he's a great guy :)
<pivi>
marex: I use to say that adding bugs is about job safety, adding bug that turns into CVS is about salary increase when job hopping ;-)
<pivi>
s/CVS/CVE/
niska has quit [Quit: Leaving]
<marex>
pivi: ha
niska has joined #u-boot
<rfs613>
marex: thanks for the reply. So env is the compiled-in one, from which a hash table is built at boot time, using lots of malloc() calls. I suppose it could be somehow writing out of bounds, and corrupting the (relocated) u-boot code, or the stack (more likely).
<marex>
rfs613: malloc shouldn't, stack might grow too deep
<marex>
rfs613: that would be my guess with obscure behavior like that anyway
<rfs613>
frankly I was surprised how many times malloc happens, eg. to compile a regex for matching against each env variable, as it is added to the hashtable.
<rfs613>
(see function regex_callback...)
<marex>
rfs613: optimization opportunity ? :)
<marex>
rfs613: that can be done in sandbox too
<rfs613>
yeah that would be a *lot* less painful ;-)
<marex>
indeed
<rfs613>
marex: just did a quick test with the internal environment minimized (undefined CONFIG_EXTRA_ENV_SETTINGS), and it looks like that works
<rfs613>
so you may be on to something with either the stack usage or otherwise memory corruption
<marex>
rfs613: check the memory layout
<marex>
rfs613: basically run what cmd/bdinfo does before you init env, or even in env_init or whatever it is called
<marex>
there is some hook in common/board_f.c and common/board_r.c
<rfs613>
marex: hmm so you're saying to look for changes in what bdinfo reports before/after the env_init() ?
<marex>
probably look at what bdinfo reports and where exactly is your stack at that point
<rfs613>
bdinfo on succesful boot report stack start 8x8fb86a0, which is what i'd expect, machine has 256MB starting at 0x80000000
<rfs613>
i guess i'll have to go see what values i'm gettin from those malloc()s during env_init
<marex>
malloc area is just below where uboot relocated itself
<marex>
is the failure happening early on boot in board_f or later in board_r ?
<silurian_invader>
this will surely increase his street cred in his quest to be known as an 31337 hax0r
* marex
rolls eyes :)
<deathcamel57>
I'm currently stuck on getting a new kernel booting on an old U-Boot build (2010.06). I'm loading the kernel + DTB, then booting with this command `usb start; fatload usb 0 0x83000000 uImage; fatload usb 0 0x81000000 hi3520dv200-demb.dtb;bootm 0x83000000 - 0x81000000` However, my new kernel can't find the DTB that I've passed in. Is there anything in particular I should start looking into?
<marex>
hanetzer: wasnt that ^ something you experimented with ?
<marex>
deathcamel57: you can always try to build the kernel with built-in DT
<marex>
deathcamel57: maybe the ancient uboot version doesn't support passing DT to Linux, or it was configured out
<marex>
deathcamel57: does the default boot command do it ?
<marex>
deathcamel57: => help bootm
<deathcamel57>
I'm not finding much about appending DTBs to a uImage, just zImage (which this build doesn't support).
<deathcamel57>
The most useful help string goes to: `bootm - boot application image from memory` lmao