hazardchem has quit [Remote host closed the connection]
hazardchem has joined #linux-sunxi
<smaeul>
Lightsword: no, looks like U-Boot doesn't have debug gadget support. does your board not have any available pins that can be muxed to any uart?
blathijs has joined #linux-sunxi
<Lightsword>
smaeul, I think just the sdcard ones
<Lightsword>
although might be wrong about that, I suppose some of the hashboard uart's could maybe be used
<smaeul>
apritzel: it might be more helpful to dump the 16 bytes at 0x3006240, not 0x3006230. 0x3006230 could reasonably be all zero, even if the value is readable
<apritzel>
just realised (and fixed) that myself ;-)
<apritzel>
on my non-secure-boot OPiZero2 everything starting from 0x230 is zero, so it's not really helpful anyway as an indicator whether the board uses SecureBoot or not
<smaeul>
Lightsword: right, you don't have to use UART0 as the U-Boot console. and there may be pins that aren't intended for use as UART, but happen to mux to a uart
<Lightsword>
smaeul, how would I say configure uboot to use uart1?
<apritzel>
Lightsword: CONFIG_CONS_INDEX
<smaeul>
and possibly updating the pinctrl driver. and for u-boot proper you need to update /chosen/stdout-path in the DT
<apritzel>
1 is UART0, 2 is UART1, ... but you have to check whether the configuration is supported, as smaeul said, plus arch/arm/mach-sunxi/board.c for the SPL
<apritzel>
Lightsword: I guess the FEL behaviour is still the same with the above: it crashed and re-enters non-secure FEL? Try if this works better, and also please check if the 3006240: line dumps values other than 0
<apritzel>
yeah, that's good, bit 11 in 0x3006248 is our secure-boot efuse. As expected, reads as 0 from the non-secure side, but also as 0 even from secure FEL on a normal board, so cannot be used to automate the SMC trick
<apritzel>
Lightsword: so can you run this twice in a row now, with identical output?
<Lightsword>
apritzel, it fails to return to FEL, I can run it again only after hard reset
<apritzel>
I see, bummer!
<Lightsword>
apritzel, the modified sdboot thing with the smc call would sometimes(but not always) return to FEL after running FYI
<apritzel>
yes, but I think we figured that's FEL "again after a reset", so back in non-secure, which is not helpful. You should be able to verify this by running: sunxi-fel readl 0x3006248
<apritzel>
on your board that reads zero if in non-secure state, and 0x800 in secure state. The goal is to read the latter, then U-Boot should work
<Lightsword>
apritzel, so something maybe needs to be restored so that it goes into secure state properly?
<apritzel>
ah, found another straw to grasp for: GICC_CTLR.AckCtl... just a sec
<Lightsword>
smaeul, is h618 reported differently from h616? I'm not entirely sure mine is a h616 and not a h618(the heat sink is glued on and not easy to remove)
<Lightsword>
AFAIU whatsminer originally only used h616 chips, but then at some point started using h618 revisions as well
<Lightsword>
allwinner indicated that h618 code is generally backwards compatible to h616, but the opposite might not be the case
<smaeul>
apritzel: could you modify your binary to dump the whole eFuse range once we're in secure state, so we know if a ROTPK hash is burnt on Lightsword's board?
<smaeul>
because if there is, we know why U-Boot won't boot. and if there isn't, we'll need to figure out what needs to change in mkimage to get the SBROM to accept the SPL TOC0.
<Lightsword>
is there an anti-rollback efuse as well btw? I may have come across some indications of something like that being used in vendor code
<smaeul>
on H6, VENDOR_ID could be used for anti-rollback, but I don't think H616 has an equivalent. Anti-rollback could be implemented in software in SPL, though.
<apritzel>
right, there we have the ROTPK hash. AckCtl got set (final GICC_CTLR print), but I guess it's still not back in FEL?
<Lightsword>
apritzel, no, it doesn't return back to FEL...but I noticed something interesting, if I run this after running the modified sdcard thing that sets smc mode...then this latest bootinfo behaves differently and gets stuck...so this may indicate that when it crashes back to FEL it's not fully resetting state https://gist.github.com/jameshilliard/c225fe76fe46eef345e154263a8a232e
<Lightsword>
it gets stuck at "Sending SMC ..." does this mean it's already in SMC mode or something?
<apritzel>
yes, that's what we want
<Lightsword>
apritzel, so this means it's partially persisting or something?
<apritzel>
mmh, but then the SID dump is all zeroes, so it's not in proper secure state I guess
<apritzel>
if you run the first image, can you run "sunxi-fel sid-dump" afterwards, and does it show zeros or the ROTPK hash?
<Lightsword>
apritzel, any idea why the uart0-helloworld-sdboot thing crashes back to FEL but the bootinfo does not?
<apritzel>
not really, but staying in monitor mode sounds "more wrong", so I think it's actually worse, and crashes differently, which triggers a reset. Or it happens to branch to 0, the reset vector
<Lightsword>
apritzel, so the goal is to go from monitor to secure mode when returning to FEL?
<apritzel>
FEL runs initially in non-secure SVC, that's what the BROM code assumes. We want it as close as possible, but in secure *state*, so secure SVC
<apritzel>
monitor is a different *mode*, and is always in secure *state*
<apritzel>
(secure state and the modes are mostly orthogonal, with this being one exception, and HYP mode being another one)
<apritzel>
I think there is one (somewhat tedious) way to mainline U-Boot:
<Lightsword>
apritzel, so returning to FEL is just always done via return 0? or is there like a way to directly dump to and re-execute FEL?
<apritzel>
*going* to FEL is branching to 0x20, or just returning from the initial call (bx lr) if the code was loaded via FEL (our case)
<apritzel>
so we could hack the SPL to issue the SMC, and hack the boot mode indicator to say "SD card". Then the SPL would switch to 64-bit, run the initial setup, plus DRAM init, and it would then continue loading from SD card
<apritzel>
only problem is then you have to decide between console via UART pins, or loading from SD card :-(
<Lightsword>
apritzel, hmm, but we wouldn't be able to load over USB then?
<Lightsword>
apritzel, it possible branching vs returning has different behavior?
<apritzel>
we load the SPL via USB-FEL, but don't need it anymore afterwards, if we load the rest from SD card
<Lightsword>
apritzel, but what if we do need to load the rest via USB instead of SD?
<apritzel>
if you load the SPL via FEL, you have to *return* to where the BROM called us, otherwise FEL mostly won't work
<apritzel>
Lightsword: well, this doesn't work at the moment, does it?
<apritzel>
another method to unblock you would be to write the ROTPK hash to all '1's, this would relieve you from the complications of getting the signature right
<Lightsword>
apritzel, yeah, I mean, can only usb-boot the test programs so far
<apritzel>
which might be because of the ROTPK hash being set something specific
<Lightsword>
apritzel, hmm, is it possible that the way I'm entering FEL mode is corrupting something?
<smaeul>
so I just looked back at the SBROM code... turns out the SBROM skips some code to extract the ROTPK from the certificate when the hash is all zero, and that code assumes some fixed offsets
<apritzel>
only "if hash is all zeroes", or also if "hash is all ones"?
<smaeul>
well technically it's "if all bytes of the ROTPK hash eFuse contain the same value"
<apritzel>
smaeul: so you mean mkimage atm is not compatible to proper ROTPK hashes?
<smaeul>
right, that explains why mkimage doesn't work, and fixing it should be as simple as updating the template with some padding to make the offsets line up
<smaeul>
yeah, and it's dead code in SBrom_Certif_verify.c. that file doesn't exactly match the BROM
<apritzel>
ironically some sophisticated "hash cracking engine" is controlled by something relying on finding a hash collision being very hard ;-)
<smaeul>
Lightsword: can you do `sunxi-fel readl 0x30000d0` after the SBROM fails to load a mkimage TOC0 and dumps you into FEL? this contains the error code from the SBROM.
<Lightsword>
0x08080013
<Lightsword>
smaeul, are meanings of error codes defined somewhere?
<Lightsword>
btw how do I modify arch/arm/mach-sunxi/board.c to allow uart1?
<apritzel>
take a deep breath and look at gpio_init() ...
<apritzel>
you need something like #elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN50I_H616)
<Lightsword>
apritzel, guess I would then need to figure out the pins right? although I guess it's kinda a moot point until I can get it to pass the verification
<apritzel>
somewhat, but as mentioned, by adding the SMC opcode into arch/arm/include/asm/arch-sunxi/boot0.h you could FEL load the SPL and execute it
<apritzel>
and if you then hack the FEL mode detection, to detect it as a SD card boot instead, you could load TF-A and U-Boot proper from SD card
<apritzel>
but only if you have a UART other than over the SD card pins, of course
<Lightsword>
apritzel, guessing probably easier to fix the signing code
<smaeul>
Lightsword: thanks! the meanings are defined by where in the SBROM the high/middle/low bytes are set. I _could_ document them, I suppose.
<smaeul>
Lightsword: in this case it's the rollback check that's failing
<Lightsword>
smaeul, ah, so it's not an issue with offsets?
<smaeul>
nope, the hardcoded offsets were in the parsed struct, not the original DER, which was obvious after plumbing through some data types :)
<smaeul>
30062c0: 0 0 1 0
<smaeul>
your rollback counter is 1, so the OID field in the certificate needs to be at least that
<Lightsword>
smaeul, oh, so I just need to patch mkimage?