On Tue, Jan 05, 2016 at 09:43:04AM +0000, Fuchs, Andreas wrote: > The current semantics of a ResoureManager does not include the concept of > dup()'ing application contexts or concurrent access to session or > key objects
Don't worry about this. The singleton context is the struct file in the kernel, and it is never copied or dup'd. How user space uses the struct file from multiple threads/processes sanely is a different question the kernel doesn't have to answer. > Side-Question: how does the current tpm-fd handle fork() and dup() ? Since it > is > single access only as well ? It is not really single access. >From a uapi perspective the question is how do you design the char dev to be useful in a threaded scenario. The current uapi is write,poll,read which cannot be run concurrently, but does allow a multiplex'd sleep for long operations. An alternative would be a synchronous ioctl which would be safe in a multi-threaded environment but not no longer pollable. In any event, it is up to the application to ensure different threads/processes do not step on each other from a TPM spec perspective. That is not something the kernel need to worry about. As I've said to Ken, the starting place for any work, and the natural first patch, should be a new uapi that allows unprivileged access to the TPMs. An obvious trivial starting point is to enable the obviously safe commands like get capability and get random. Progressively build up more capabilities from that point. Jason ------------------------------------------------------------------------------ _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
