On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg <sumit.garg@xxxxxxxxxx> wrote: > > I chose the userspace plugin due to this, you can use userspace aids > > to provide any type of service. Use the crypto library you desire to > > do the magic you want. > > Here TEE isn't similar to a user-space crypto library. In our case TEE > is based on ARM TrustZone which only allows TEE communications to be > initiated from privileged mode. So why would you like to route > communications via user-mode (which is less secure) when we have > standardised TEE interface available in kernel? The physical access guards for reading/writing the involved critical memory are identical as far as I know? Layered security is generally a good thing, and the userspace pass actually adds a layer, so not sure which is really safer? In my case the rerouting was to done generalize it. Any type of trust source, anywhere. > > > Isn't actual purpose to have trusted keys is to protect user-space > > > from access to kernel keys in plain format? Doesn't user mode helper > > > defeat that purpose in one way or another? > > > > Not really. CPU is in the user mode while running the code, but the > > code or the secure keydata being is not available to the 'normal' > > userspace. It's like microkernel service/driver this way. The usermode > > driver is part of the kernel image and it runs on top of a invisible > > rootfs. > > Can you elaborate here with an example regarding how this user-mode > helper will securely communicate with a hardware based trust source > with other user-space processes denied access to that trust source? The other user mode processes will never see the device node to open. There is none in existence for them; it only exists in the ramfs based root for the user mode helper. -- Janne
