+ Thiru (original author), Ilias, Joakim Hi Jarkko, On Mon, 25 May 2020 at 12:20, Maxim Uvarov <maxim.uvarov@xxxxxxxxxx> wrote: > > On Fri, 22 May 2020 at 23:03, Jarkko Sakkinen > <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > > > > On Fri, May 22, 2020 at 10:29:44PM +0300, Maxim Uvarov wrote: > > > On Fri, 22 May 2020 at 20:15, Jarkko Sakkinen > > > <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > > > > > > > > On Thu, May 21, 2020 at 09:47:43AM +0300, Maxim Uvarov wrote: > > > > > Register driver on TEE bus. module tee registers bus, > > > > > > > > "on the TEE bus" > > > > > > > > "The module tee" > > > > > > > > > and module optee calls optee_enumerate_devices() to scan > > > > > all devices on the bus. Trusted Application for this driver > > > > > > > > Looking at drivers/tee, it shows that tee and optee are in fact the same > > > > module as opposed to what your commit message says. > > > > > > > > > > In the current kernel it's 2 different modules. > > > > > > > > can be Early TA's (can be compiled into optee-os). In that > > > > > case it will be on OPTEE bus before linux booting. Also > > > > > optee-suplicant application is needed to be loaded between > > > > > OPTEE module and ftpm module to maintain functionality > > > > > for fTPM driver. > > > > > > > > Why is this needed and why things worked before having this? If you remembered earlier discussions when this driver was added, tee-supplicant dependency concern was raised at that time too. But the response from author [1] was to use a workaround in firmware to overcome the initialization issue of fTPM driver. Basically while using upstream OP-TEE, fTPM NV RAM is implemented via RPMB secure storage [2]. So any fTPM operation dependent on NV RAM may fail without access to RPMB secure storage. And during kernel boot, RPMB access isn't available (there were some prior efforts [3] around this but unfortunately didn't land in upstream) due to which we need to rely on user mode tee-supplicant for corresponding access. So we should only register fTPM device when the underlying infrastructure is working, which is something this patch-set addresses via registering fTPM device only when the tee-supplicant is up and running. [1] https://lkml.org/lkml/2019/7/4/779 [2] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html#rpmb-secure-storage [3] https://lwn.net/Articles/682276/ > > > > > > > > > > Before these changes user space has to drive boot sequence. I.e. tee > > > and optee modules loads, then application tee-supplicant has to start > > > and only then module ftpm can be loaded. The reason for that is > > > storage services are implemented in userspace and driver needs them. > > > > Is the TPM implementation uploaded to TEE from user space and or what > > storage are we talking about? Not sure how these storage services > > connect to the TPM. Please see my response above. -Sumit > > > > /Jarkko > > Jakko, > tee-supplicant application provides state machine over callbacks with > RPC messages. > https://github.com/OP-TEE/optee_client/blob/master/tee-supplicant/src/tee_supplicant.c#L614 > It also allocates shm. Without running tee-supplicant > tee_client_open_session() will fail. > optee_open_session()->get_msg_arg()->tee_shm_alloc()->... > Optee team wanted to remove some dependencies from tee-supplicant with > moving code > to the kernel. But for now I think that should be out of the scope of > current patches due to > they fix driver initialization on tee bus without breaking current > functionality. > > Maxim.
