ftg has quit [Read error: Connection reset by peer]
cmeerw has joined #linux-sunxi
cmeerw has quit [Ping timeout: 480 seconds]
<gamiee>
apritzel: hello, few months ago we have been talking about implementing secure boot into sunxi platform. I wanted to ask, was something done in meantime? I would like to contribute and I can test it on H3 SoC (I'm aware of that I can brick few SoCs).
<clever>
gamiee: i'm not sure how much carries over, but i know some of how secureboot could work on one of the rpi soc's
<clever>
basically, the 1st stage of code (like uboot SPL) is signed with an hmac-sha1 signature, with the key coming from a combination of maskrom and fuses
<clever>
and then that code is responsible for validating all future stages
<clever>
the biggest blocker in terms of actually implementing it on rpi boards, is that the fuses with the key have been pre-burnt at the factory
<clever>
so you dont have any choice over what key is used
<clever>
enless you can special order some un-burnt boards
<gamiee>
Yes, it works similar on sunxi platform. It's required to burn fuses with rotpk and then special (TOC0) format is required to be flashed on SD card to boot, because it contains signature
<clever>
on the rpi, the fuses are arranged as an array of ~60 slots, each 32 bits wide
<clever>
and a 16 byte section of that, holds the per-device key
<clever>
plus 1 bit to act as a main enable flag
<clever>
for the vc4 lineup (pi0 to pi3), the 20 byte signature is in a second file on the sd card
<clever>
for the vc6 lineup (pi4, pi400), its just the last 20 bytes of the blob being executed
kprasadvnsi[m] has left #linux-sunxi [#linux-sunxi]
<clever>
only the vc6 lineup actually has signature checking enabled
<clever>
and every single unit has the identical key in the fuses, making the whole thing pointless!
<clever>
gamiee: the major weakness, is that hmac is a symetric algo, if you can gain execute once, you can dump the fuses, and then sign whatever you want
<clever>
the bcm2835 also had a timing exploit in the maskrom, which let you guess the signature without knowing the keys
ftg has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
tnovotny has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]
<gamiee>
clever: well, there are several exploits also for sunxi platform already known, but still I think it's still good to have it (some less skilled people will have problem to dump the firwmare)
cnxsoft has joined #linux-sunxi
cnxsoft1 has quit [Ping timeout: 480 seconds]
prefixcactus has joined #linux-sunxi
apritzel has joined #linux-sunxi
oliv3r[m] has quit []
MatrixTravelerbot[m] has quit []
pgwipeout[m] has quit []
kayterina[m] has quit []
z3ntu has quit [Quit: Bridge terminating on SIGTERM]
psydroid has quit [Quit: Bridge terminating on SIGTERM]
enick_130 has quit []
dittid[m] has quit []
insep has quit []
JuniorJPDJ has quit [Quit: Bridge terminating on SIGTERM]
ServerStatsDiscoverertraveler4 has quit []
aperezdc has quit [Quit: Bridge terminating on SIGTERM]
Tooniis[m] has quit [Quit: Bridge terminating on SIGTERM]
Guest482 has joined #linux-sunxi
warpme_ has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
pmp-p has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Mangy_Dog has joined #linux-sunxi
uwu has joined #linux-sunxi
apritzel has joined #linux-sunxi
uwu has quit [Ping timeout: 480 seconds]
uwu has joined #linux-sunxi
<JoaoSchim>
Anyone ever managed to get MIPI-DSI working on A83T using mainline kernel ?
Guest514 has joined #linux-sunxi
dittid[m] has joined #linux-sunxi
JuniorJPDJ has joined #linux-sunxi
kayterina[m] has joined #linux-sunxi
z3ntu has joined #linux-sunxi
insep has joined #linux-sunxi
oliv3r[m] has joined #linux-sunxi
pgwipeout[m] has joined #linux-sunxi
psydroid[m]1 has joined #linux-sunxi
ServerStatsDiscoverertraveler4 has joined #linux-sunxi
Tooniis[m] has joined #linux-sunxi
MatrixTravelerbot[m] has joined #linux-sunxi
mps has quit [Ping timeout: 480 seconds]
mps has joined #linux-sunxi
lunixoid has joined #linux-sunxi
<gamiee>
JoaoSchim: it's not possible atm because nobody is working on the mipi DSI driver for A83T
zumbi has quit [Ping timeout: 480 seconds]
<JoaoSchim>
Hmm. well by now the soc is so old, it won't happen either.. i suppose. Though BPI-M3 (also A83T) claims DSI support. non-mainline code maybe ?
<gamiee>
Most likely
<JoaoSchim>
A nasty consideration to make on this SoC it's either GMAC or LCD.. I want both. was thinking of using ICN6211 to convert DSI to LCD.. Bad luck, heh..
arti has quit [Quit: arti]
apritzel_ has joined #linux-sunxi
rellla has quit [Ping timeout: 480 seconds]
rellla has joined #linux-sunxi
tnovotny has quit []
tnovotny has joined #linux-sunxi
<wens>
sigh, couple days spent trying to get uart DMA to work
<wens>
half of them figuring out why bluetooth is flaky on my rk3399 boards :/
<tnovotny>
JoaoSchim: the LVDS is mainlined. It was used (at least) on one tablet documented on linux-sunxi.org
<JoaoSchim>
tnovotny: thanks. did not know that. though according to the datasheet of A83T LVDS is also multiplexed with GMAC pins, so it seems.
<JoaoSchim>
tnovotny: i will have a look at it.
prefixcactus has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
cmeerw has joined #linux-sunxi
hlauer has quit [Remote host closed the connection]
<tnovotny>
JoaoSchim: hmmm, it is true that there is no GMAC on that tablet... There is also fex of this tablet available, so you can check. It is still possible to get one for developers, see the wiki page of that tablet.
<jernej>
JoaoSchim: There is MIPI DSI driver, just for other AW SoCs. With any luck, it shouldn't be hard to adapt it for A83t.
uwu has quit [Ping timeout: 480 seconds]
arti has joined #linux-sunxi
lunixoid has quit []
lunixoid has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
lunixoid has quit [Ping timeout: 480 seconds]
uwu has joined #linux-sunxi
<clever>
gamiee: i do still have some unknowns in terms of firmware dumping
<clever>
gamiee: the maskrom is at address 0x6000_0000, but if i try to read that from under the official firmware, nada
<clever>
i suspect the rom can drop off the bus, like the gameboy or xbox
<gamiee>
clever: I think you will be able to dump it only via JTAG
<clever>
the jtag interface hasnt been documented publicly
<clever>
ive only been able to dump the rom from the early stages of the firmware
<gamiee>
apritzel: thanks for pointing me to smaeul work, found the patches on patchwork :)
<apritzel>
gamiee: check my replies, there are two bugs in there
<apritzel>
but the actual mkimage parts seem to work
<gamiee>
apritzel: thanks, I read them :)
Guest514 is now known as aperezdc
warpme_ has quit [Quit: Connection closed for inactivity]
<gamiee>
Okay, it looks like that the smaeul's work also handles certificate reading and signing, so only thing left is to burn eFuse and test it. (just hope that the part with ROTPK_HASH and LCJS will be possible to be burned with my burn script)
<gamiee>
smaeul: thanks for the snippet and for the information. The code works from userspace?
<smaeul>
no, I compile it with -fPIC and run it from FEL
<smaeul>
it's the same function you are using, so your userspace app should work as well. I just included it for completeness
<gamiee>
Great, thanks! About ROTPK_HASH, please, do you have any code/script snippet that would generate correct sha256 hash from the public key? (I'm kinda noob with anything crypto and I don't want to mess up the hash generation)
<smaeul>
no, I'd have to look back at what the BROM does