> 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. 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. 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 ? Thanks for all inputs, Andreas ------------------------------------------------------------------------------ _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
