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

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

[Jason Gunthorpe]

On Thu, Dec 17, 2015 at 11:44:41AM +0000, Fuchs, Andreas wrote:
> Jumping in real quick, since I'm going through some TPM2.0 RM
> design and implementation at the moment.
> 
> The big issue that I see with RMs in the kernel is none of the mentioned,
> but the issue of where to store the swap'ed (TPM2_ContextSave()'ed)
> blobs. These blobs are spec'ed with a size of up to 4kBytes.

This isn't a problem. As long as the context is located in swappable
memory that falls under the existing resource limit schemes for
userspace memory, then everything is fine.

Allocate the memory during open/write and fail those syscalls if the
process exceeds any of the standard memory limits.

It is no different than a process mmaping alot of memory and dirtying
it.

Jason

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

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

[Wilck, Martin]

> 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?

Martin

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

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

[Jarkko Sakkinen]

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.

> Martin

/Jarkko

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

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

[Jarkko Sakkinen]

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.

/Jarkko

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

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

[Wilck, Martin]

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?

Martin

> 
> /Jarkko
------------------------------------------------------------------------------

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

[Jarkko Sakkinen]

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

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

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

[Ken Goldman]

On 12/18/2015 6:41 AM, Jarkko Sakkinen wrote:
>
> 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.

As a developer, the philosophical side is #1 in importance.

A resource manager isn't a little patch.  It's a large, complex project 
which will take perhaps 6 months to code and test.  No one wants to 
spend those months and then have the code rejected for philosophical 
reasons.

If the community agrees that a RM in the kernel will be accepted if the 
code is of good quality and well tested, we can do it.

If the community won't accept the code under any conditions, tell us 
now.  We'll fall back on the user space resource manager, the limited 
resource manager in the kernel, and all the hacks required to have them 
work together.


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

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

[Fuchs, Andreas]

Let me emphasise this even more. It would be greate to have a kernel-space TPM
Resource Manager (everybody thinks to agree), but it would also bit a big module
and a big programming investment.

I ask the tpmdd-maintainers to check (reconcile with parent subsystem
maintainers) if a 3-5 kLoC module would be generally acceptable for a 
TPM-ResourceManager?

The advantages would be to have some actual full access to all of TPM from
within the kernel (including access to sessions without hacks); e.g.
TrustedKeyrings and ecryptfs come to mind.
With a userspace-RM we need some hacks to have sessions run because of the
ungaping-problem (see earlier mail). It's also way cleaner.

Also we wind up with a light-RM inside the kernel anyways, so it might be worth
going full instead. Going with the hacked approach we are assuming some
limitations on kernel accesses to the TPM.  With the full RM inside the kernel
there are no limitations, i.e. the RM is future proof as more kernel and app
level uses of the TPM are added.


In case there was a positive signal, I'd be willing to contribute to the RM development.

Proposed roadmap:
- Gather interested developers (both from Kernel as well as TSSes)
- Prepare a feature-architecture (to be added to kernel-doc)
   Includes behavior of e.g. fd-fork, fd-passing, etc
   Also see the TCG-Draft on RMs: 
   http://www.trustedcomputinggroup.org/resources/tss_tab_and_resource_manager
   New in-Kernel tpm-interface
- Sketch out software architecture
   includes layered system, hook-based, ....
- Do the patches coordinated (to prevent having multiple implementation efforts)

So please, Jarkko, Peter, Marcel, James, Greg K-H (I think that's the list),
would there be the chance for a signal / tendency by one of you ?

Many interessted parties need this before proceeding because of the significant
amount of work involved.

________________________________________
From: Ken Goldman [kgoldman-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org]
Sent: Friday, December 18, 2015 15:10
To: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [tpmdd-devel] Question on Linux TSS architecture design (kernel vs. user space access)

On 12/18/2015 6:41 AM, Jarkko Sakkinen wrote:
>
> 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.

As a developer, the philosophical side is #1 in importance.

A resource manager isn't a little patch.  It's a large, complex project
which will take perhaps 6 months to code and test.  No one wants to
spend those months and then have the code rejected for philosophical
reasons.

If the community agrees that a RM in the kernel will be accepted if the
code is of good quality and well tested, we can do it.

If the community won't accept the code under any conditions, tell us
now.  We'll fall back on the user space resource manager, the limited
resource manager in the kernel, and all the hacks required to have them
work together.


------------------------------------------------------------------------------
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

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

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

[Stefan Berger]

[-- Attachment #1.1: Type: text/plain, Size: 660 bytes --]

"Fuchs, Andreas" <andreas.fuchs-iXjGqz/onsDSyEMIgutvibNAH6kLmebB@public.gmane.org> wrote on 12/21/2015 
08:22:04 AM:


> 
> Let me emphasise this even more. It would be greate to have a 
kernel-space TPM
> Resource Manager (everybody thinks to agree), but it would also bit 
> a big module
> and a big programming investment.
> 
> I ask the tpmdd-maintainers to check (reconcile with parent subsystem
> maintainers) if a 3-5 kLoC module would be generally acceptable for a 
> TPM-ResourceManager?

Does that include TPM 2 only or also TPM 1.2 ? The need for a light-RM 
inside the kernel
is also there for TPM 1.2.

Regards,
   Stefan



[-- Attachment #1.2: Type: text/html, Size: 918 bytes --]

[-- Attachment #2: Type: text/plain, Size: 79 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

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

[Jason Gunthorpe]

On Mon, Dec 21, 2015 at 01:22:04PM +0000, Fuchs, Andreas wrote:
> maintainers) if a 3-5 kLoC module would be generally acceptable for a 
> TPM-ResourceManager?

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.

I have an entire tpm1.2 userpace in less than 2kloc, so I struggle to
see why a simple resource manager would be so big.

1-2kloc is not a big deal kernel wise if it is well written and in the
kernel style.

Jason

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

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

[Ken Goldman]

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.

> I have an entire tpm1.2 userpace in less than 2kloc, so I struggle to
> see why a simple resource manager would be so big.
>
> 1-2kloc is not a big deal kernel wise if it is well written and in the
> kernel style.

Similar question.  Let's assume it's 5 kloc, or even more.  Can it be 
accepted or not?

I don't want to go down the TPM 1.2 path, where IBM funded several 
projects and they were all rejected, not after any technical evaluation, 
but simply based on LOC.



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

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

[Jarkko Sakkinen]

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.

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

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

[Ken Goldman]

On 12/24/2015 6:42 AM, Jarkko Sakkinen wrote:
>
> Code is not rejected solely on its size as long as is broken up into
> reasonable size and otherwise sane patches.

I'm still at the prime question. If we present a ~5 loc resource 
manager, can it be accepted, or will it be rejected as "too big"?

~~

We already went through the failing process with TPM 1.2.  I had a 50 
kloc TPM, and they wanted me to release it as <100 loc patches.

1 - How do you release an entirely new function as a patch.  It's not 
patching anything?

2 - If you break it up, won't it be rejected because it doesn't work. 
It may not even compile?

3 - Breaking it up into small pieces that even compile can mean 
designing the code inefficiently.

4 - Or, are you saying that we code the entire RM, but just show it to 
you a function at a time?  Can anyone review a bunch of functions 
without seeing how it fits together into a program?

~~

I can understand small "patches" to fix bugs, but not for new code.






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

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

[Jason Gunthorpe]

On Thu, Dec 24, 2015 at 10:09:43AM -0500, Ken Goldman wrote:

> I can understand small "patches" to fix bugs, but not for new code.

You need to do it in smaller functional stages.

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?

Next step would be to parse commands and require that the commands are
'valid' and of the allowed subset.

Next step would be to parse commands deeper and do access control on
all the tpm objects. Ie a vtpm fd can only use key ids it created.

Next step would be auto-cleanup of created objects when the vtpm fd
closes, ie destroy key ids created on the fd

Next step would be hooking kernel access through the above

Next step would be allowing objects to be swapped in/out

Jason

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

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

[Jarkko Sakkinen]

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.

/Jarkko

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

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

[Fuchs, Andreas]

> 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
------------------------------------------------------------------------------

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

[Jarkko Sakkinen]

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

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

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

[Mimi Zohar]

On Mon, 2016-01-04 at 20:19 +0200, Jarkko Sakkinen wrote:
> 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.

Jarkko is right.  At the end of the day, the code itself is what gets
reviewed.  To ease that review process, the code needs to be broken up
into manageable chunks known as patch sets.  Each patch set builds upon
previous patch sets, introducing a new feature/function with the
motivation for that feature described in the cover-letter.  Within a
patch set, patches need to be bi-sect safe, meaning it needs to build
cleanly after each patch.

Bottom line, break up the project and submit small incremental changes.

There's some documentation describing the upstreaming process:
- Documentation/SubmittingPatches
- Documentation/SubmitChecklist
- Documentation/SubmittingDrivers

Mimi


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

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

[Fuchs, Andreas]

> > 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.

Understood, you and Mimi do not want to talk concept without code.
However, I'd prefer to have some things steightened out conceptually, before
running in wrong directions for weeks. Therefore, if anyone is willing to
argue some design choices with me, I appreciate the help.

> > 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.

Ok let me iterate a little about this point and why it's important.

The current semantics of a ResoureManager does not include the concept of
dup()'ing application contexts or concurrent access to session or key objects
from different application contexts. The reason is pretty simple; (i) there is
no real need and (ii) it is hard to get concurrent access to sessions right,
since they are stateful. When one context performs a change on a session object
the other context would be out of sync. Accordingly, in the ResourceManager
semantics a session (and also key) object are always bound to a single context
only.

In order to keep these semantics also for an in-kernel ResourceManager, I saw
specifically problems with the fork() and dup() calls. So my immediate reaction
was to question if they can be disallowed for the tpm-fd.

Side-Question: how does the current tpm-fd handle fork() and dup() ? Since it is
single access only as well ?

If disallowing is indeed impossible, the question for constructive alternatives
from other (similar) kernel-drivers would be interesting. I could imagine to
e.g. keep all objects bound to the original tpm-fd only and have the fork()'ed /
dup()'ed tpm-fd be completely blank with regards to associated objects. This may
also work.

The question of "How do I continue using tpm-fd contexts in the second thread"
and "How to handle fd-passing" remain unanswered though. Perhapes in the
passing case, one could empty the original context and move all objects to the
new tpm-fd context ? Would also provide a solution for the first question.

Comments highly welcome.

Thanks,
Andreas

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

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

[Mimi Zohar]

On Tue, 2016-01-05 at 09:43 +0000, Fuchs, Andreas wrote:
> > > 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.
> 
> Understood, you and Mimi do not want to talk concept without code.
> However, I'd prefer to have some things steightened out conceptually, before
> running in wrong directions for weeks. Therefore, if anyone is willing to
> argue some design choices with me, I appreciate the help.

At this stage, the design discussion needs to be at a higher level as to
how the project will be broken up into smaller, more manageable chunks
(eg. patch sets) for review.  The design issues of the individual patch
sets will be reviewed/discussed as they're posted.

Mimi


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

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

[Jason Gunthorpe]

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

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

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

[Jarkko Sakkinen]

On Fri, Dec 18, 2015 at 09:10:35AM -0500, Ken Goldman wrote:
> On 12/18/2015 6:41 AM, Jarkko Sakkinen wrote:
> >
> > 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.
> 
> As a developer, the philosophical side is #1 in importance.
> 
> A resource manager isn't a little patch.  It's a large, complex project 
> which will take perhaps 6 months to code and test.  No one wants to 
> spend those months and then have the code rejected for philosophical 
> reasons.
> 
> If the community agrees that a RM in the kernel will be accepted if the 
> code is of good quality and well tested, we can do it.
> 
> If the community won't accept the code under any conditions, tell us 
> now.  We'll fall back on the user space resource manager, the limited 
> resource manager in the kernel, and all the hacks required to have them 
> work together.

I'm all for the idea but I'd like to discuss more about constraints and
corner cases and in the end of the day would rather read code than
email (even big pile of code).

One of the corner cases are vendor specific commands. I raised that but
it was ignored in this discussion.

Now that I looked at TCG document it does not give any recommendation how
they should be managed:

http://www.trustedcomputinggroup.org/resources/tss_tab_and_resource_manager

/Jarkko

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

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

[Fuchs, Andreas]

> >
> > If the community won't accept the code under any conditions, tell us
> > now.  We'll fall back on the user space resource manager, the limited
> > resource manager in the kernel, and all the hacks required to have them
> > work together.
> 
> I'm all for the idea but I'd like to discuss more about constraints and
> corner cases and in the end of the day would rather read code than
> email (even big pile of code).
> 
> One of the corner cases are vendor specific commands. I raised that but
> it was ignored in this discussion.
> 
> Now that I looked at TCG document it does not give any recommendation how
> they should be managed:
> 
> http://www.trustedcomputinggroup.org/resources/tss_tab_and_resource_manager

I'll try to remeber this point for the next iteration...

IMHO, it should check the number of handles in the handle-area via the
TPM2_GetCapability() call. If a vendor is ignorant enough to put a handle into
the parameter-section, there is nothing we can do besides some quirks once we
recognize them...
But this will be the same for all OSes...

Cheers,
Andreas
------------------------------------------------------------------------------

TPM2 resource manager vendor specific commands

[Ken Goldman]

On 12/22/2015 1:59 AM, Jarkko Sakkinen wrote:
>
> One of the corner cases are vendor specific commands. I raised that but
> it was ignored in this discussion.
>
> Now that I looked at TCG document it does not give any recommendation how
> they should be managed:

You are right that we should add this to the TCG documents.  We 
discussed this on a TPM WG call today.  Here's some design information 
for an implementer.

My high level conclusion is that the resource manager (RM) should not 
have any command specific handling.  It it does, that's a red flag that 
a vendor specific command may not work.

The TPM 2.0 design includes features to generalize vendor specific
commands.  There is a getcapability that returns command ordinal
properties, specifically:

- The number of command and response handles indicate whether and how 
many handles should be mapped.

- Whether transient objects are flushed.

- An extensive flag indicates that the command has many side effects. 
For these commands, the RM should use getcapability to enumerate the 
handles that are still active or loaded and synchronize its tables. 
TPM2_Clear is an example.






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

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

[Wilck, Martin]

On Do, 2015-12-17 at 10:23 -0500, Stefan Berger wrote:

> > kernel space. Can you point out a particular part of the problem
> that
> > could be solved better or more easily in user space?
> 
> User space would handle any number of client applications. It would
> handle
> the arbitration between applications from concurrent TPM usage while
> one
> application needs to access the TPM for a sequence of commands that
> requires
> access to session and key slots. This application can use the TPM
> directly
> with commands it passes through /dev/tpm0, so there's no need for a
> higher
> level API (provided by the TPM driver) for the usage of the TPM or the
> need
> to intercept commands where one application's usage of the TPM would
> interfere with another application's usage of TPM, such as one
> application
> swapping out the context of another applications keys/session and/or
> deleting
> another applications session and key handles.

I had asked for things that user space could do *better* than the
kernel. Could you point that out more clearly?

> And, as mentioned by Andreas, the kernel becomes attackable if it
> needs to
> handle hundred's of applications' sessions and contexts that may these
> applications may create for the purpose of exhausting resources.

It seems to be controversial whether that represents a real threat.
Similar threats exist in many places where the kernel has to user space
cache data for slow devices. Techniques are available to deal with it.

> > I am not voting for "replacing TSS" as Jason suggested in a previous
> > email. I expect that the industry will standardize on the TSS API,
> so
> > Linux will have to provide it to the upper layers. If resource
> 
> And it can do so via a user space library, no ?

Yes, certainly. All this talk is only about the TAB/RM.

> > Rogue user space applications could even
> > use the "keyctl" mechanism to bypass the tcsd and obtain priority
> access
> > to the TPM resources.
> 
> The only way to restrict this would be to only allow root access to
> the keyctl commands affecting the TPM.

I'll leave it to Jarkko to comment on that. 
Btw, wouldn't the "keys, trusted" API need some sort of resource
management, too? And wouldn't it make sense to merge that all into a
single TPM resource pool?

> > management was done in the kernel, a trivial user space "tcsd" could
> > simply sit on top of the kernel interface. That would provide a
> reliable
> > resource-managed TSS interface to application, what else would they
> > need?
> 
> A daemon that implements this functionality and would be the only
> application usng /dev/tpm0 could do the same.

Not quite, because this daemon wouldn't be fully in control of the
resources it manages.

Regards
Martin

> 
>    Stefan
> 
> > 
> > Regards
> > Martin
> > 
> > > 
> > >    Stefan
> > > > 
> > > > Jason
> > > > 
> > > 
> 
------------------------------------------------------------------------------

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

[Jarkko Sakkinen]

On Fri, Dec 18, 2015 at 12:21:01PM +0100, Wilck, Martin wrote:
> > The only way to restrict this would be to only allow root access to
> > the keyctl commands affecting the TPM.
> 
> I'll leave it to Jarkko to comment on that. 
> Btw, wouldn't the "keys, trusted" API need some sort of resource
> management, too? And wouldn't it make sense to merge that all into a
> single TPM resource pool?

Well this should have been done when the syscall was originally
introduced. I think the right long term solution would be to do resource
swapping mechnaism (like the LRU mechanism that I described).

/Jarkko

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

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

[Jarkko Sakkinen]

On Fri, Dec 18, 2015 at 01:51:37PM +0200, Jarkko Sakkinen wrote:
> On Fri, Dec 18, 2015 at 12:21:01PM +0100, Wilck, Martin wrote:
> > > The only way to restrict this would be to only allow root access to
> > > the keyctl commands affecting the TPM.
> > 
> > I'll leave it to Jarkko to comment on that. 
> > Btw, wouldn't the "keys, trusted" API need some sort of resource
> > management, too? And wouldn't it make sense to merge that all into a
> > single TPM resource pool?
> 
> Well this should have been done when the syscall was originally
> introduced. I think the right long term solution would be to do resource
> swapping mechnaism (like the LRU mechanism that I described).

If you really want to block "dangerous" syscalls, IMHO the way to go is
seccomp like browsers do.

> /Jarkko

/Jarkko

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

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

[Stefan Berger]

[-- Attachment #1.1: Type: text/plain, Size: 1353 bytes --]

"Wilck, Martin" <martin.wilck-RJz4owOZxyXQFUHtdCDX3A@public.gmane.org> wrote on 12/18/2015 06:21:01 
AM:

> 
> On Do, 2015-12-17 at 10:23 -0500, Stefan Berger wrote:
> 
> > > kernel space. Can you point out a particular part of the problem
> > that
> > > could be solved better or more easily in user space?
> > 
> > User space would handle any number of client applications. It would
> > handle
> > the arbitration between applications from concurrent TPM usage while
> > one
> > application needs to access the TPM for a sequence of commands that
> > requires
> > access to session and key slots. This application can use the TPM
> > directly
> > with commands it passes through /dev/tpm0, so there's no need for a
> > higher
> > level API (provided by the TPM driver) for the usage of the TPM or the
> > need
> > to intercept commands where one application's usage of the TPM would
> > interfere with another application's usage of TPM, such as one
> > application
> > swapping out the context of another applications keys/session and/or
> > deleting
> > another applications session and key handles.
> 
> I had asked for things that user space could do *better* than the
> kernel. Could you point that out more clearly?

I don't think it can do things 'better' just keep it simpler in the 
kernel.

   Stefan



[-- Attachment #1.2: Type: text/html, Size: 1727 bytes --]

[-- Attachment #2: Type: text/plain, Size: 79 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

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

[Kenneth Goldman]

[-- Attachment #1.1: Type: text/plain, Size: 1084 bytes --]

> From: "Wilck, Martin" <martin.wilck-RJz4owOZxyXQFUHtdCDX3A@public.gmane.org>

> I am glad that this disucssion is gaining momentum. Whether to do
> resource arbitration in user or kernel space is an important question
> that should be discussed broadly.

I am too.  Putting the resource manager in the kernel make the design so 
much 
cleaner than a resource manager in user space, another smaller one in the 
kernel, 
and communications hacks to make it hopefully work

> > > If the kernel takes over TSS's role of virtualization then we don't
> > > need TSS in user space any more. Multiple opens is a missing peice
> > to replace tss.

Just to be clear on TCG terminology, there is a "TSS" library per 
application,
in user space, that handles crypto and the forming of the command byte 
stream.
Whatever the RM solution, you still need that TSS.  2-3 solutions are 
already
open sourced.

There is one (or a layered) "Resource Manager" that schedules application 
access
to the TPM, does resource swapping, handle virtualization, and much more.




[-- Attachment #1.2: Type: text/html, Size: 1530 bytes --]

[-- Attachment #2: Type: text/plain, Size: 79 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel