ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
ungeskriptet_ has joined #linux-sunxi
ungeskriptet_ has quit [Remote host closed the connection]
ungeskriptet_ has joined #linux-sunxi
ungeskriptet_ has quit [Remote host closed the connection]
ungeskriptet_ has joined #linux-sunxi
ungeskriptet_ has quit [Remote host closed the connection]
ungeskriptet_ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
junari_ has quit [Remote host closed the connection]
ungeskriptet_ has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
hexdump01 has quit []
hexdump0815 has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
montjoie_ has joined #linux-sunxi
mripard has joined #linux-sunxi
warpme has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
apritzel has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
hentai has joined #linux-sunxi
ad__ has quit []
ad__ has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Read error: No route to host]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
bauen1 has joined #linux-sunxi
warpme has joined #linux-sunxi
pmp-p has quit [Ping timeout: 480 seconds]
pmp-p has joined #linux-sunxi
diego71_ has joined #linux-sunxi
diego71 has quit [Ping timeout: 480 seconds]
<loki666>
apritzel: some activity for panfrost, I can fix the _init/_deinit sequence... should I sent a V2 with that, or a different patch ?
diego71 has joined #linux-sunxi
<apritzel>
loki666: it would be a separate patch anyway. I would just wait for Rob to wake up and potentially comment, to see if we actually need a v2 of this series or not. If yes, it becomes [v2 3/3], if not, it's a new patch on its own
diego71_ has quit [Ping timeout: 480 seconds]
<loki666>
Steve already like a V2 to merge the flags
<apritzel>
yes, but wait for another day still, at least
warpme has quit []
ungeskriptet has quit [Remote host closed the connection]
<gamiee>
jakllsch : yeah, it seems to be related only for LS and FS. For some reason, I thought also HS will be impacted, but according to this, it's not. So it should be fine.
<gamiee>
Still, connecting WiFi to native USB, and using USB hub port for USB on pin headers would be much better tbh.
warpme has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
radxanaoki has quit [Quit: radxanaoki]
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
ungeskriptet has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit [Read error: No route to host]
warpme has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
ungeskriptet_ has joined #linux-sunxi
ungeskriptet__ has joined #linux-sunxi
<Lightsword>
anyone know why mkimage adds a SBROMSW_KEY section to toc0 images but the allwinner bsp does not for toc0 images?
warpme has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-sunxi
ungeskriptet_ has quit [Ping timeout: 480 seconds]
ungeskriptet__ has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
mripard_ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
mripard has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
warpme has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
ungeskriptet_ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
ungeskriptet_ has quit [Ping timeout: 480 seconds]
warpme has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel>
Lightsword: smaeul would probably know (as he wrote that code), but IIRC he just implemented what we need for mainline U-Boot
<smaeul>
Lightsword: which SoC are you referring to? the key item (TOC0_ITEM_INFO_NAME_KEY, which I believe is what you are referring to) is only used on H6, as far as I know, but it doesn't hurt to put the item there for other chips
<smaeul>
mkimage doesn't know what SoC it is generating an image for, so the code is written to generate an image that works on every SoC
<Lightsword>
smaeul, it's for h616/h618 boards, TOC0_ITEM_INFO_NAME_KEY isn't used at all for bsp generated toc0's looks like
<smaeul>
correct. h616 boot rom (at least, on the die revision I looked at) doesn't use that item
<Lightsword>
smaeul, so that TOC0_ITEM_INFO_NAME_KEY key is required for h6?
<smaeul>
yes
warpme has joined #linux-sunxi
<smaeul>
> If the SBROM is configured to use a key item (this is the default on the H6; it is unavailable on older SoCs), the certificate must include (and be signed by) "KEY1" from the key item. Otherwise, it must include (and be signed by) the ROTPK.
<Lightsword>
smaeul, that sysfs thing is just pulling info from efuses I think
<Lightsword>
smaeul, is h6 BROM_CONFIG the same as h616?
<smaeul>
probably not, since like I said, there's no code in the boot ROM to read TOC0_ITEM_INFO_NAME_KEY
<Lightsword>
smaeul, so if the rotpk validation for h616 is enabled by burning the efuses then mkimage should be able to generate a toc0 that will validate correctly for it as long as the right root key is used?
<smaeul>
yes. I never burned a ROTPK, but the signature verification part is tested on H616
<Lightsword>
smaeul, hmm, so it might be completely broken if a rotpk is burned?
<smaeul>
(the logic is that if the efuse ROTPK hash is all zeroes or all ones, the BROM accepts any TOC0 ROTPK hash, but other than that, the verification is the same)
<smaeul>
no, the main thing you'd have to worry about is getting the endianness of the efuse value correct
warpme has quit [Ping timeout: 480 seconds]
<smaeul>
even without the ROTPK hash programmed, the signature verification (SHA256+RSA) is still performed, just the public key can be anything
<smaeul>
that said, it _might_ be completely broken; I provide no warranties ;-)
<Lightsword>
smaeul, and you're sure there's not something that requires a SBROMSW_CERTIF to be the first toc0 item in the event the hash is programmed?
<smaeul>
yes, I'm sure. but even if that were the case, it wouldn't brick your board, you'd just have to regenerate the image after patching mkimage
<Lightsword>
smaeul, so can someone actually disable rotpk hash validation permenantly by setting any non-1 bits in the efuse?
<smaeul>
yes, but the efuse can only be accessed from secure mode, so it's your software's resposibility to prevent that
<Lightsword>
smaeul, so if I say have an exploit that gives me root access from Linux I could use that to disable hash validation entirely?
<smaeul>
no, you'd have to get code execution in secure mode (e.g. TF-A in EL3)
warpme has joined #linux-sunxi
<Lightsword>
smaeul, there isn't some interface Linux can use to ask the TF to burn the fuses?
<smaeul>
no, the recommended way to burn the fuses is from FEL or a dedicated boot0/eGON/TOC0 image
<apritzel>
though didn't the vendor TF-A have some SMC call to read or write arbitrary values in secure?
<smaeul>
that sounds like a security hole :)
<Lightsword>
allwinner security holes seem the norm, lol
<apritzel>
smaeul: sure, but what's the question? ;-)
<apritzel>
I think they needed it to get even read access to the SID from Linux, so they hacked it in
<Lightsword>
smaeul, so when mkimage generates a uboot image, what was the reason that it puts SBROMSW_KEY before the SBROMSW_CERTIF as opposed to the other way around?
<smaeul>
the order doesn't matter. the BROM searches for the item by ID
<Lightsword>
apritzel, yeah pretty sure those sysfs kernel interfaces expose SID access to Linux
<smaeul>
but logically the chain of trust is ROTPK -> SBROMSW_KEY -> SBROMSW_CERTIF -> firmware code, so that's the order I chose
<Lightsword>
smaeul, but SBROMSW_KEY is only involved in the chain of trust on h6 boards right?
<smaeul>
yes (AFAIK, I haven't looked at every SoC, but it's not used on H616 or D1)
<apritzel>
ignore that Arm in that context is meant to say "as architected by Arm Ltd." ;-)
warpme has quit [Ping timeout: 480 seconds]
<Lightsword>
smaeul, is there an example bsp generated h6 toc0 image somewhere?
<apritzel>
the implementation of ARM_SVC_WRITE_SEC_REG is particularly hilarious: there is no check or validation whatsoever ...
<gamiee>
smaeul : hi! The rotpk is in form of hash of rsa public key, burned into efuse? Then bootloader during boot gets public rsa key from boot header, calculate hask, compare with efuse, and if valid, it does RSA signature check on the firmware code?
<apritzel>
Lightsword: can you dump the SID content from your BSP root shell?
<Lightsword>
smaeul, but why wouldn't the h6 also use SBROMSW_CERTIF like the other boards? that's also signed right?
<smaeul>
it uses both
<smaeul>
SBROMSW_CERTIF is signed by the public key in SBROMSW_KEY, SBROMSW_KEY is signed by ROTPK
evgeny_boger has joined #linux-sunxi
<smaeul>
in a real usage, the two keys shouldn't be the same -- this allows the ROTPK holder to delegate image signing for a subset of devices (those with matching vendor_id efuse) and revoke that privilege
<Lightsword>
smaeul, so from what I can tell in theory h6 should work fine without SBROMSW_KEY and the ladder stuff isn't needed unless there's an actual need for that feature