Re: Question on Linux TSS architecture design (kernel vs. user space access)

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

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

------------------------------------------------------------------------------