14:48 <phh> Hello. I have a secure-booted s902x2/g12a box, with vendor bootloader, that won't boot un-signed video decoding firmware (looks like the only way to know is that it never sends any interrupt...?), instead the firmware loading process is done by a trusted application. I did a very crude implementation on top of mainline linux. I validated that h264 decoder works and display correct frames, and the vp9 decoder outputs frame (but i don't know if the output is

14:48 <phh> Very ugly kernel change: https://github.com/phhusson/linux/commit/6551d587c20f8435c697659eaf494be6ee74e1d4

14:48 <phh> correct), both are quite flaky when it comes to startup, i have maybe 50% of chance to properly startup every time.

14:48 <phh> Reverse-engineered user-space code to load the firmware into the TA: https://github.com/phhusson/linux/blob/fbx-pop/TEE/tee-load-vid-fw.c

14:48 <phh> (That's just a FYI, I see no reasonably easy way to upstream this, and don't really plan to spend on stablizing/improving it for my own usage)

15:40 <narmstrong> phh: it’s pretty cool! I wonder if you could use the optee Linux code to scan the TAs and use it to load the fw if this particular TA is present ?

16:03 <phh> I don't know what you know about TAs, so I'll give more details about it: When Linux is started, no TA is loaded inside optee [1]. The code "tee-load-vid-fw.c" will implicitly load the TA, when receiving that OpenSession call, tee-supplicant will look for /lib/optee_armtz and look for a file whose name is the UUID provided in OpenSession, send that file to optee, and optee will launch that TA. Only then will the smcc calls in my patch succeed. So before "tee

16:03 <phh> on non-vendor optee

16:03 <phh> -load-vid-fw" is called from userspace, kernel can't know whether this TA is present. Maybe it's possible to check for it afterwards, would that work? I can check. Also, something I could explore is the `TEE_SMC_CALLS_UID` call (which in this case actually does nothing, it's just for logs), vendor code checks for the return value of this call to determine whether to go into tee path or not, but I don't know whether it's standard op-tee call, or it'll break

16:10 <narmstrong> phh: you can tie a driver to a ta like https://elixir.bootlin.com/linux/latest/source/drivers/char/hw_random/optee-rng.c#L273

16:10 <narmstrong> So you can probably lookup a ta

16:16 <phh> I guess I could open the session and close it directly without calling any method inside that session to detect it. This would trigger loading the TA from the FS into optee. At this point, I could maybe even implement tee-load-vid-fw fully in kernel?

16:31 <narmstrong> phh: you would still need to know if you're in secure boot or no, perhaps by cheking if there's en OPTEE loaded ?

17:00 <phh> actually there is probably a register somewhere saying the platform is secure booted, no need to tinker with optee. also this would help debugging for people trying to boot mainline on a secure boot device since we would be able to provide a nice warning

17:11 <phh> yeah, there is {readl(aobus + 0x228) & 0x10} to know whether secure boot is enabled

17:14 <phh> (register called AO_SEC_SD_CFG10 downstream)

17:58 <phh> narmstrong: https://github.com/phhusson/linux/commit/be0fceecf7b63110d88e74461401ff14700e27b9 + https://github.com/phhusson/linux/commit/cdd6221c64be94c06f541bcc8ae89a1c60870882 -- i'm really not used to kernel development, i don't know whether that way is good. though it would be useful if you could at least check the value of that register on your devices to ensure they all have 0

19:34 <narmstrong> phh: looks good ! I’ll have a try