07:51 <vigneshr> austriancoder: are you looking to fall back from boot0 to boot1 due to corrupted image, I dont have a solution for that. But for A/B update, you can choose which partition would the next active boot partition (boot0 or boot1) via mmc partconf cmd during flashing (say from u-boot) mmc partconf dev [boot_ack boot_partition partition_access] where boot_partition can be 1 or 2

08:59 <ldts> the next iteration of this architecture would benefit from an A53 OTP interface so securing the board is not such a convoluted process.The bootflow (IMO) is not that bad - on par with AMD/Xilinx SoCs (zynqmp/Versal ACAP) and many other processors...but certainly writing keys to fuses does not need to be this painful.

09:12 <ldts> would also be nice to have better crypto support in OP-TEE so pkcs#11 runs with hardware support in the trusted world (that just requires doing some drivers since SA2UL supports the TEE island...at least for the KEK).

12:02 <NishanthMenon> Thanks vigneshr . austriancoder : I ran into a team member who mentioned that on emmc boot0/1 csd will help select, but no fallback.. e2e might give you an official answer though

12:04 <NishanthMenon> ldts: fuse programming: that is under scrutiny.. but what specific stuff do you see benefit with pkcs on optee.. for my education...

12:07 <NishanthMenon> austriancoder: ospi boot might have a scheme closer to a/b update though..

12:14 <ldts> @NishanthMenon the main benefit is that keys - and operations - never leave the Trusted Zone: OP-TEE provides ciphers via libtomcrypt and libmbedtls but also supports IPs on iMx, SP, Zynqmp and so on. Should be easy to add K3 (seems to be just a mbox layer?) Some HSMs on i2c are also supported adding even more security to those keys.

12:22 <NishanthMenon> ldts: thx for your feedback. I will pass this along.

14:43 <ldts> @NishanthMenon great thanks. WRT to the eFuses, I think controlling the write operation from the TEE (instead of perhaps directly from u-boot) is a good choice. Uboot would implement a trusted application and the whole fuse process could be scripted. The u-boot script would send the write requests to the TEE which then would send the efuse requests to the firmware. It is a workflow to secure the boards that we follow on a number of

14:43 <ldts> SoCs

15:48 <NishanthMenon> @ldts Thanks once again - understood.

15:51 <ldts> this is a good summary https://www.timesys.com/security/pkcs11-with-op-tee-securing-iot-device-keys/ (no affiliation to timesys)

16:16 <NishanthMenon> ldts: +1 :)

16:34 <NishanthMenon> ldts: https://github.com/OP-TEE/optee_os/pull/5758 might be of partial interest..

16:36 <ldts> oh vow, great timing :)

16:36 <ldts> will review, I didnt notice it

16:37 <NishanthMenon> just passing on from internal chat.. I think the folks are working on what is doable.. there are some architectural constraints to work with..

16:38 <ldts> with the PTA, a u-boot command is really simple and should be accepted upstream (we have one to provision a secure element)

16:38 <ldts> right

16:40 <ldts> https://u-boot.readthedocs.io/en/latest/usage/cmd/scp03.html something along these lines to write the fuses from u-boot to optee

16:49 <NishanthMenon> gotcha

21:13 <austriancoder> NishanthMenon: sadly there is no ospi on our device.. only emmc. I could switch bootx in r5 U-Boot before loading/running a53 U-Boot .. all I need would be to setup a HW watchdog by R5 U-Boot. The harder path is if R5 U-Boot is broken :( dsmc would need change bootx (and I think there is a HW watchdog too that is used already).