mengxp 创建的主题

@mengxp 看了下r328上使用的v3代码，关键字alloc，我发现有

ss_rng_start buf 内存泄露 (kmalloc without kfree)

目前就发现这一个

分析到了。上下电时序可能有异常，破坏了efuse中rotpk的某些比特。

正确的rotpk
74e61bc6f59b1382a29019xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

芯片中的rotpk
74e61bc6fd9b1382a39019xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

果然efuse供电引脚需要改成按需上电。

我焯我焯。我参考了 https://support.xilinx.com/s/article/65240 上面说的，他说的上下电时序会影响 efuse 完整性！！！看来得改设计。。LDO是省不了了。

@mengxp 是的读取chipid然后&0xffff就行了，具体对应关系需要自己试一下

问题解决了。

我今天看到了 v833 的 Tina_Linux_Secure_Development_Guide.pdf 文档，里面有 TA 使用 SSK 加密的案例，查看了tina相关的代码，有一个sign.py，看了下，确认了加密引擎确实是使用原始SSK加密的，没有做什么黑盒变换。

那特么为什么我自己写的bootloader在调用CE使用ssk加密的结果异常呢？

想来optee肯定有相关的接口，找了下也就是
#define TEESMC_SSK_ENCRYPT 0
#define TEESMC_SSK_DECRYPT 3

由于optee是闭源的，只能拿IDA逆了一下看他是怎么做的。
发现了一个奇怪的事情，既然CE是使用SSK作为key，那代码里为什么要申请一个 256 字节的keyBuf呢？

然后我试着在我的bootloader里面，给 task desc 的 key 指向了一个 256 字节的缓冲，果然OK了！！！

补充测试代码
https://blog.csdn.net/MengXP/article/details/122736176?spm=1001.2014.3001.5501

@a1314258
同样的方法使用在r329的key_burn.c
编译成功了，无语