On Fri, 1 Nov 2019 at 03:17, Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > > On Thu, Oct 31, 2019 at 07:28:42PM +0530, Sumit Garg wrote: > > Provide documentation for usage of TEE based Trusted Keys via existing > > user-space "keyctl" utility. Also, document various use-cases. > > > > Signed-off-by: Sumit Garg <sumit.garg@xxxxxxxxxx> > > This is the most important commit in order for someone who don't deal > that much with ARM TEE to get right. > I agree that documentation needs to be updated and your following comments seems to be somewhat similar to comments from Mimi here [1]. > Until this commit is right, I don't > unfortunately have much to say about other commits. Isn't this statement contradicting with your earlier statement regarding the right order would be to complete TEE patches review first and then come up with documentation here [2]? [1] https://lore.kernel.org/linux-integrity/1568025601.4614.253.camel@xxxxxxxxxxxxx/ [2] https://lore.kernel.org/linux-integrity/20190909163643.qxmzpcggi567hmhv@xxxxxxxxxxxxxxx/ > Instead of making disjoint islands, you should edit trusted-encrypted.rst > so that it describes commonalities and differences. > > What the document currently describes is the usage model. It could be a > section of its own. In that you should describe first the common > parameters and separetely the backend specific parametrs. > > From kernel internals (there could be a section with this name) the > document describe the key generation e.g. is the hardware used and how > it is used, is there salting with krng and so forth. BTW, here is the info regarding RNG provided by OP-TEE (an open-source TEE implementation). It's either direct output from hardware based RNG (if platform supports one) [3] or a software based Fortuna CSPRNG (executing in trusted environment) [4] which is seeded via multiple entropy sources as described here [5]. Overall, I think salting this with krng sounds reasonable to address single RNG source concern. So I would suggest to have a common wrapper API that would do salting of trust source (TPM or TEE) RNG output with krng. [3] https://github.com/OP-TEE/optee_os/blob/master/core/crypto/rng_hw.c [4] https://github.com/OP-TEE/optee_os/blob/master/core/crypto/rng_fortuna.c [5] https://github.com/OP-TEE/optee_os/blob/master/core/include/crypto/crypto.h#L272 -Sumit > > /Jarkko
