> On 25-08-06, Pankaj Gupta wrote: > > > On 25-07-09, Pankaj Gupta wrote: > > > > > Am 30.06.25 um 14:17 schrieb Marco Felsch: > > ... > > > > Lockdown: For a verified boot setup you need to burn an eFuse at > > > some > > point, > > > to tell the bootROM to boot only correct verified firmware images. > > > > > > After this lockdown it's no longer possible to burn eFuses from the > > > REE > > albeit > > > the production line setup still requires the support. > > > > > Understood. ELE access from both secure and non-secure world is fixed > > in Q3 release. > > User can be able to modify eFuses via OPTEE. > > Splitting the read and write between two drivers is even worse. This could be use-case dependent. Depends on how customer will deploy its solution. > > Can you please point out why you can't just move the driver parts into the > tee? I do see many advantages if only op-tee is used: The ELE's KEY derivation function takes account of world from where, the operations are requested. - The key derived from secure world and from non-secure world will be different. There are different use-case for ELE accesses from both the worlds. Using OPTEE ELE driver for Linux specific ELE-HSM requests, it will add significant overhead. Usecases like Transparent TLS offload while securing the secrets in HSM, would incur additional overhead. IOT-cases where real-time encrypted feed from sensors, will take latency hit. > > + Minimize the maintainer effort, because only one driver > implementation is used. > + TEE code could be reused by other OSes + You could already start adding > the support for it to OP-TEE because > no ELE-FW update is required. As answered above, we do need support of ELE driver in both worlds. > + TEE is used anyway for new projects due to CRA and friends + Concurrent > access handling is done by the TEE core As answered above, we do need support of ELE driver in both worlds. > > The only downside of this approach is the integration effort for the TEE, but > this shouldn't be an excuse. Mostly all well known buildsystems > like: Yocto/OE, buildroot, ptxdist do have mainline support for OP-TEE. > As answered above, we do need support of ELE driver in both worlds. > > > > >> - With new regulations like the EU CRA I think we need some sort of > > > > >> secure-enclave anyway. > > > > > > > > > Probably some sort of, yes. But not necessarily in the form of > > > > > TEE or TrustZone, I guess. > > > > To use ELE features through Linux, there is no dependency on OPTEE-OS. > > > > > > Once again, still no fix available and if your system requires a TEE > > you're forced > > > to move the ELE communication into the TEE (at least until now). > > > > > > Also the eFuse R/W access is not possible from the REE/Linux after > > > doing > > the > > > device lockdown. > > > > > ELE access from both secure and non-secure world will be fixed in Q3 > > release. > > User can be able to modify eFuses via OPTEE. > > NACK, please see my comment above. > > > > > >> - Making it optional cause more paths of potential errors e.g. > > > > >> by > > not > > > > >> including the correct "secure.dtsi". Multiple paths also > > > > >> require > > more > > > > >> maintain- and testing effort. IMHO I do think that one of > > > > >> the > > paths > > > > >> get unmaintened at some point but we would need to keep it for > > > > >> backward compatibility. > > > > >> > > > > >> Having one implementation eliminates this since. > > > > >> > > > > >> - All above points assume that the ELE-FW and -HW is capable > > > > >> of > > talking > > > > >> to both world, which is not the case. As we learned NXP > > > > >> doesn't > > have > > > > >> a fix for the 2-MUs ELE yet and even more important there are 1- > MU > > > > >> ELE-IPs. > > > > > > > > For i.MX9x SoC(s) there is at least one dedicated ELE MU(s) for > > > > each world - Linux(one or more) and OPTEE-OS (one or more), that > > > > needs to be shared between them. > > > > > > Please mention this within your commit message. > > Accepted & mentioned. > > > > > > > > > As mentioned earlier, there is an issue of using MUs > > > > simultaneously, from both worlds. Fix is in progress. > > > > > > So until now no fix available and i.MX93 based products which do use > > > a TEE are forced to move the communication into OP-TEE. > > > > > > > >> I do see the (minimal) drawback of having +1 FW but I think > > > > >> this is more an integration problem. > > > > >> Speaking of FW files, for the new i.MX9* you already have > > > > >> plenty fo > > > > >> them: bootloader, TF-A, ele-fw, scu-fw (i.MX95). So your > > > > >> integation needs to handle multiple firmware files already. > > > > > > > > > Sure, but I really like to keep the complexity and therefore the > > > > > number of FW files as low as possible. I'm not sure what has > > > > > more weight in terms of > > > > > security: shipping an additional firmware and therefore > > > > > increasing the attack surface or maintaining an additional code-path. > > > > > > > > There is no +1 firmware in case of i.MX93. > > > > > > > > >> > > > > >>> Anyway, I see your point of having a single implementation for > > > > >>> the ELE API in the "right" place. But as far as I know other > > > > >>> platforms like > > > > >>> STM32MP1 also implement both ways for the HWRNG, secure > access > > > > >>> via OPTEE and non-secure access via kernel directly. > > > > >> > > > > >> I'm not a STM32MP1 expert but here you have this setup with the > > > > >> *-scmi.dtsi. So you have two code paths which needs to be > > > > >> maintained and tested. Also if one customer of yours want to > > > > >> use OP-TEE you need the integration anyway, so you (Kontron) > > > > >> needs to maintain multiple configuration as well. I don't see the > added value. > > > > >> > > > > >> I think for STM32MP1 the *-scmi.dtsi support was added later > > > > >> because it required a lot effort to support it. This is not the > > > > >> case for the > > > > >> i.MX9* series. > > > > > > > > > Anyway, thanks for elaborating. Your points are all valid and > > > > > basically I > > > > agree. I'm fine with either way. But I'm afraid that implementing > > > > the ELE API in OP-TEE only will cause another tremendous delay for > > > > having ELE access in the kernel, especially seeing how slow NXP > > > > seems to be working on these topics right now. > > > > > > > > To use ELE features through Linux, there is no dependency on OPTEE-OS. > > > > > > How exactly do you provide the eFuse write access after the device > > > was > > locked > > > down? > > As mentioned above by you. It will be done via OPTEE-OS (or may be via > TFA). > > Why TF-A? Please see my comments above. > > At the moment I don't see why the ELE must be a Linux driver. You could start > adding a TEE driver now, because there is no need to wait 3 months for a ELE- > FW fix. > > IMHO having a dedicated normal-world driver makes only sense for > bootlaoders which don't have support for the TEE communication but need > access to the ELE. This is not the case for the kernel. > > Regards, > Marco
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
