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

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

On Wed, Dec 23, 2015 at 10:02:05AM -0500, Ken Goldman wrote:
> On 12/22/2015 4:23 PM, Jason Gunthorpe wrote:
> >
> > I'd be alarmed if it is that much. The TPM format is very amenable to
> > doing this, a well designed table driven approach should be quite
> > small on the rpc handling side. The key is to not overthink/overdesign
> > it too much.
> 
> Let's expand on "alarmed".  If that just means you're surprised, OK.  If 
> it means the code will be rejected based solely on the size, please tell 
> us now.

Code is not rejected solely on its size as long as is broken up into
reasonable size and otherwise sane patches. It's impossible to give
promise on acceptance without seeing the code first.

For simple context swapping you'd have:

* One data structure per context containing virtual-physical mapping +
  shmem_file for storage.
* Generic swapping code command and response parameters. You get the
  meta-data from CAP_COMMANDS.
* Special cases for less than five commands.

Trivial swapping code would just dump transient data to shmem_file after
taking tpm_mutex and load its own mappings. Then it would do
substitution based on the meta-data given by the TPM. That's it.

It is extremely hard to imagine that one would reach source line counts
described unless the implementation is of extremely bad quality [1].

/Jarkko

[1] I'm considering here only TPM 2.0 implementation.

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