<linkmauve>
A difference I’ve noticed compared to ALARM’s default kernel is that I don’t get a DMA zone range in early boot.
<linkmauve>
Err, why did I say “bought”, I meant “built”. >_<
<linkmauve>
This is an Allwinner A10 platform, in case this is any relevant.
vagrantc has quit [Ping timeout: 244 seconds]
vagrantc has joined #linux-sunxi
<apritzel>
linkmauve: did you use the DTB from that very kernel as well?
<linkmauve>
Yes, I also tried the one from ALARM which I had been using ever since, neither is setting up the DMA zone correctly (it shows up as “normal” instead).
gaston1980 has quit [Quit: Konversation terminated!]
gaston1980 has joined #linux-sunxi
lurchi_ is now known as lurchi__
<MoeIcenowy>
apritzel: for eMMC, SPL in boot partition and SPL at 8K of main storage, which have higher priority?
<apritzel>
boot partition is higher priority (if that is enabled)
vagrantc has quit [Quit: leaving]
Mangy_Dog has quit [Ping timeout: 256 seconds]
<apritzel>
MoeIcenowy: if you have an H3 board with eMMC, I'd be grateful for any testing!
<apritzel>
I just have A64, H5 and H6 with eMMC
apritzel has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 260 seconds]
ChriChri_ is now known as ChriChri
gaston1980 has quit [Ping timeout: 256 seconds]
victhor has quit [Ping timeout: 264 seconds]
tlwoerner has joined #linux-sunxi
<smaeul>
bauen1: turns out I actually did find the BROM swap bit earlier by scanning through the SRAM controller registers... but I neglected the fact that FEL won't work after you swap out the FEL code for whatever is in SBROM
<smaeul>
all I needed was a thunk to swap BROMs, dump SBROM, and swap back before returning to FEL, instead of trying to use `sunxi-fel writel`
dev1990 has quit [Remote host closed the connection]
<bauen1>
and it doesn't look like the lcjs is used anymore
dev1990 has joined #linux-sunxi
<bauen1>
smaeul: do you still know what exact bit you burnt to enable secure mode ?
dev1990 has quit [Client Quit]
dev1990 has joined #linux-sunxi
florian_kc is now known as florian
camus1 has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
camus1 is now known as kaspter
<bauen1>
smaeul: also, the sbrom saves the "progress" into 0x3000000+0xd0, so maybe you can try to boot your toc0 image and when it enters fel dump that address
<bauen1>
it also looks like the sbrom requires a new item with id 0x10303, no idea what it's for, but maybe something related to NV2
<bauen1>
it _will_ fail without it present (at least on one of the boot modes {try, efuse specified})
<bauen1>
something of size 0x538
<bauen1>
and now i have to chase pointers again :/
<asdf28>
:->
<apritzel>
bauen1: are you guys using egon2toc.rb? And you are saying that the H6 extended the requirements?
yann has quit [Ping timeout: 260 seconds]
<bauen1>
apritzel: i haven't actually booted my h6 yet lol, but yeah h6 has changed the requirements
<bauen1>
also i need to make a pr for egon2toc.rb so the run code address is also signed, otherwise you can bypass secure boot easily
<apritzel>
bauen1: do you know of any work to get some better tool than egon2toc.rb?
<apritzel>
bauen1: I once started with adding the boiler plate part of mkimage support
<apritzel>
but didn't understand enough of the TOC internals to finish this
<bauen1>
no not really
<bauen1>
but yeah, a better tool would be nice
<bauen1>
i'll see if i can figure out what 0x10303 does and then see if i can add it to egon2toc
<apritzel>
bauen1: do we have some TOC0 image for some H6 board?
<apritzel>
bauen1: and do you just stare at objdump listings or do you have some tool to help you out?
<bauen1>
apritzel: i'm currently using radare2
<bauen1>
apritzel: i don't think so
yann has joined #linux-sunxi
<bauen1>
thanks to pine64 i now have a pine h64, but still need to pick up an usb cable to access fel
<bauen1>
apritzel: according to smaeul not even the "official" tool manages to create a working image \o/
<apritzel>
bauen1: so is radare2 any good? Would you recommend it? I just installed it the other day, but didn't find time to dive into it yet.
<bauen1>
yeah it's decent
<bauen1>
apritzel: i haven't really figured out how to make radare2 retain the arguments and type information however
<apritzel>
so you must not end your session?
<bauen1>
apritzel: the integrated emulator also doesn't quite emulate all instructions correctly
<bauen1>
apritzel: it does save everything else
<bauen1>
apritzel: the benefits somewhat outweight the issues caust by loosing argument names / types in some cases
<apritzel>
bauen1: I see, thanks, I will take a deeper look then. I used my own objdump post-processor so far, but objdump doesn't work well with binary mixed Thumb/Arm, for instance
<apritzel>
(though I think the BROM is pure ARM, isn't it?)
<bauen1>
i think so
<bauen1>
BROM is arm 32 but uses the arm16 calling convention
<bauen1>
apritzel: i think the calling convention is why radare2 sometimes fails to save arguments
<apritzel>
ah, interesting. The BROM assembly looked weird to me: it seems to be generated by some compiler (at least most parts), but by some very stupid one
<bauen1>
yes, it kind of looks like -O0
<bauen1>
almost like it was hand assembled
<apritzel>
-O-1 in parts ;-)
<bauen1>
it does make it a lot easier to reverse engineer
<apritzel>
that's true, it's just painful to read: I always feel the urge to fix it ;-)
<apritzel>
there were some things no human would do, like "mov r1, r0; mov r0, r1", also some stub functions (just a ret)
<bauen1>
yes, and useless call wrappers
<bauen1>
actually, completely unused functions even (e.g. sid_write in nbrom)
<bauen1>
which almost makes me believe that they have 1 git repo for all chips and use preprocessor macros to select functionality as needed
<bauen1>
or at least some shared library between all broms
<apritzel>
exactly what I thought
lurchi__ is now known as lurchi_
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 244 seconds]
camus1 has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
<bauen1>
there's also some mix of clearly optimised (for speed) memory functions and e.g. this https://termbin.com/j4lg
hanni76 has joined #linux-sunxi
<bauen1>
the code to check if the rotpk is all 0 / 1 is still present, but i'm not really sure if it is called
rojiro has quit [Write error: Broken pipe]
rojiro has joined #linux-sunxi
<apritzel>
bauen1: ouch. Do we know a key that generates an all-0 hash? That would maybe fix smaeul's problem
<bauen1>
he didn't even flash a key so it should be all-1 / all-0
<apritzel>
bauen1: I know, but normally all-0 or all-1 means: "ignore key". But maybe it doesn't anymore on the H6 (as you hinted). So we now need an actual key that has an all-0 hash.
jbrown has quit [Ping timeout: 240 seconds]
<bauen1>
oh i see
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
jbrown has joined #linux-sunxi
<bauen1>
in fact there appear to be 2 different implementations that check the signature of an image, one with the new 0x10303 and one without
gaston1980 has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
<bauen1>
smaeul: maybe adding an item with the id 0x10303 to your toc0 image can already make it boot
<bauen1>
or at least it should "increase" the value saved into the sram debug
<bauen1>
i think i've finally found the function that "parses" 0x10303 and it does some operation on it and the sid HUK field (offset 0x5c)
<bauen1>
but if sid[0x5c] == 0 then some more checks should be skipped
<bauen1>
but first the item has to have some sort of format to get this far
<bauen1>
it does kind of look like "another certificate" since the operation also involves the rotpk hash
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
_whitelogger has joined #linux-sunxi
lurchi_ is now known as lurchi__
<smaeul>
bauen1: LCJS is used by hardware, not necessarily the BROM. It drives SID register 0xA0, which is a read-only secure mode flag. I flashed bit 11 of LCJS on both (0xf4 on H5; 0x48 on H6), and I just verified that's the only bit flashed (no BROM_CONFIG, no ROTPK_HASH) on both
<smaeul>
apritzel: bauen1: I was using egon2toc0.rb, but now I'm using my own C implementation that matches the output of dragonsecboot
<smaeul>
(other than the fact that dragonsecboot doesn't work on big-endian; both the header and the RSA bignum math is wrong)
<apritzel>
smaeul: awesome! any plans on your side to integrate this into mkimage, eventually?
<smaeul>
bauen1: there are multiple ways to make a toc0 in dragonsecboot -- some include the additional 0x10303 item (it appears to be a certificate chain)
<smaeul>
apritzel: yes and no, dragonsecboot source is "all rights reserved" :(
<apritzel>
smaeul: did you copy code from there? Or just cloned the functionality of dragonsecboot?
<smaeul>
so while the way I was calling it doesn't work, there may be a way to call it that works on H6 (I didn't know about the 0x10303 requirement, much thanks!)
<smaeul>
apritzel: I copied only constants. I definitely didn't copy their homegrown RSA implementation :)
<bauen1>
it probably only needs a somewhat valid 0x10303 unless you actually flash the HUK
<smaeul>
at least I'll be able to explain the format much better
<smaeul>
I found the egon2toc code harder to read, although it doesn't help that I don't know ruby
<bauen1>
smaeul: if you have any additional information about 0x10303 please update https://linux-sunxi.org/TOC0
<smaeul>
also, I'm using ghidra for the BROM, and other than cp15 access, it decompiles well
<apritzel>
smaeul: if you have copyright concerns, you could throw some pseudo code or a rough algorithm description over the fence, and I do the clean room implementation
<apritzel>
smaeul: ah, I see. I was recently looking at some (A63) boot0, which is mixed ARM/Thumb, and that's hard to decode from just a binary (not object) file
<smaeul>
(and $d is how to mark constant pools)
<smaeul>
that repo includes a script to convert a binary to ELF and inject the appropriate symbols
<smaeul>
I will try adding an 0x10303 this evening
<bauen1>
it also doesn't look like disabling fel is possible
sunshavi has joined #linux-sunxi
tuxd3v has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 256 seconds]
tnovotny has quit [Ping timeout: 258 seconds]
matthias_bgg has joined #linux-sunxi
hanni76 has quit [Remote host closed the connection]
hanni76 has joined #linux-sunxi
asdf28 has quit [Ping timeout: 240 seconds]
asdf28 has joined #linux-sunxi
tnovotny has joined #linux-sunxi
arete74 has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
ldevulder_ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
gaston1980 has quit [Quit: Konversation terminated!]
ldevulder has quit [Ping timeout: 272 seconds]
gaston1980 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 246 seconds]
matthias_bgg has joined #linux-sunxi
matthias_bgg has quit [Client Quit]
hanni76 has quit [Remote host closed the connection]
hanni76 has joined #linux-sunxi
vagrantc has joined #linux-sunxi
eduardas has quit [Quit: Konversation terminated!]