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

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

On Fri, Dec 18, 2015 at 12:09:02PM +0100, Wilck, Martin wrote:
> On Fr, 2015-12-18 at 12:53 +0200, Jarkko Sakkinen wrote:
> > On Fri, Dec 18, 2015 at 12:51:48PM +0200, Jarkko Sakkinen wrote:
> > > On Fri, Dec 18, 2015 at 11:06:54AM +0100, Wilck, Martin wrote:
> > > > > That is the discussion to be held if the decision against RM inside
> > > > > kernel remains as is.
> > > > 
> > > > Is there a decision? If yes, who made it? Where is it documented?
> > > 
> > > Yeah, I'd be interested too.
> > 
> > That was sarcasm. You really can't make such decisions for the kernel.
> > It's always the code/patches that speaks.
> 
> Decisions are being made all the time, by maintainers, in mailing list
> discussions, on kernel summits. If only a limited subsystem is affected,
> they can be made based on coded quality alone. But it becomes difficult
> when several communities are involved, like kernel & systemd or, in our
> case, TPM device driver & user space TSS. In these cases it's important
> to take a step back from the purely technical developer perspective and
> try to figure out what the common goal is and how it can best be
> reached.
> 
> The question whether resource management should be done in the kernel or
> in user space can't be decided based on patches alone. Maybe we'll end
> up with a situation where both ways are implemented and either distro
> makers or even end users will have to make the choice. Is that
> desirable?

For me this discussion seems a bit paralyzed. If one wants to do
something for the issue, one should send a patch or patches and then we
can see how elegant the solution is and how much it does or does not
interfere the user space. That's why enumerated the technical
constraints for TPM2 in my previous responses and otherwise have been
quite passive. I'm not too interested on this "philosophical" side.

To give more pointers about the possible architecture I would like to
see LRU with objects enumerated by client, virtual handle and physical
handle. You would swap as many objects needed from LRU when you run out
of space.

This kind of architecture would have couple of advantages:

* You would have "unlimited" transient storage per client. This could
  simplify user space implementation even if you end up having daemon
  also there. Also kernel subsystems would not have to worry space
  running out.
* Swapping would be lazy. When you'd switch a client, immediately
  you'd do a zero amount of work for swapping.
* I think in the end you would get with this architecture the cleanest
  and simplest code paths inside the kernel.

You could use shmem_file for backing storage like GPU drivers do.

> Martin

/Jarkko

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