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

[Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>]

On Mon, Jan 04, 2016 at 04:22:25PM +0000, Fuchs, Andreas wrote:
> > On Sat, Jan 02, 2016 at 01:39:57PM -0700, Jason Gunthorpe wrote:
> > > Ie the first step would be to create a new /dev/ node for the
> > > 'virtualized' tpm (vs the raw tpm we have now). We'd want to have some
> > > idea exactly what that is and exactly what the UAPI looks like, and
> > > make decsisions like, should there be one per tpm or one for all tpms?
> > 
> > Or you can get a new context when you open tpm device. There are
> > multiple options.
> 
> I guess there are ways to add stuff.
> 
> I'd like to get a list of people interested to work on some conceptual stuff
> first though.

I don't care in what process the patches are implemented. I can review
and test patches once there is something real to be evaluated.

> Some concrete questions that originate from my personal unfamiliarity with
> kernel coding that would influence my getting started concepting this thing:
> 
> - fd-duplication (dup(), fork(), ...): How to handle objects in this case ? It is
> possible to duplicate DH_HANDLES, but not SESSION_HANDLES.

What you are saying does not match the semantics of these system calls.
They do not duplicate data. Nothing needs to be done.

> It would be easiest to disallow dup() and fork(), similar to CLOEXEC but rather
> "CLOFORK". Is this possible ? What are alternatives ?
> 
> - Similarly, can/shall we allow fd-passing ? In context of the previous question,
> is it possible to force closing of fd in the original process when passing the fd ?
> What alternatives would there be ?
> 
> - What would be preferred, a layered approach vs a hook-table based approach ?
> What's generally used in kernel modules ?

This discussion about fd's is way out of context.

> Thanks for all inputs,
> Andreas

/Jarkko

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