Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Dr. Greg Wettstein]

On Jan 3,  5:21pm, Ken Goldman wrote:
} Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

Good morning, I hope this note finds the day going well for everyone.

> On 1/3/2017 4:47 PM, Jason Gunthorpe wrote:
> >
> > I think we should also consider TPM 1.2 support in all of this, it is
> > still a very popular piece of hardware and it is equally able to
> > support a RM.

> I suspect that TPM 2.0 and TPM 1.2 are so different that there may
> be little or no code in common.
>
> My immediate need is for a 2.0 resource manager, since it's a gap in
> the technology, while 1.2 does have tcsd.

In the FWIW department.

I influence architecture and engineering for a company which builds
deterministically modeled and attested computing platforms for high
security assurance environments.  This entity actually builds systems
based on TPM1.2 and TPM2 hardware.  TPM2 prototypes were being
developed based on the simulator which came out of Ken's lab as soon
as it was first made available.

The kernel needs a resource manager.  Everyone needs to think VERY
hard and VERY, VERY carefully about what gets put into the kernel.  In
making a decision, put the ABSOLUTE smallest amount of code into the
kernel which allows various 'TPM2 personalities' to be implemented in
userspace and functionally verified and protected by the physical
instance.  The emergence of commodity TEE's (SGX, et.al) should be in
the back of everyone's mind as a factor in the roadmap.

Repeat incessantly to oneself, TPM1.2 and TPM2 are only similar by
virtue of sharing three ASCII characters.

DO NOT rush this process.  If we do not get this right we will
ultimately end up trying to shove something which is conceptually
worse then tss/tscd into the kernel.

Repeat incesssantly to oneself, policy does not belong in the kernel.

Pay homage to Ken, his TSS2 and TPM2 simulator work are beyond
excellent...

Greg

}-- End of excerpt from Ken Goldman

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"... you should really focus more on simplifying your life.  I
 actually spend most of my time finding ways to de-clog my brain."
                                -- Sarah Wettstein
                                   At the lake

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Dr. Greg Wettstein]

On Jan 3,  5:21pm, Ken Goldman wrote:
} Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

Good morning, I hope this note finds the day going well for everyone.

> On 1/3/2017 4:47 PM, Jason Gunthorpe wrote:
> >
> > I think we should also consider TPM 1.2 support in all of this, it is
> > still a very popular piece of hardware and it is equally able to
> > support a RM.

> I suspect that TPM 2.0 and TPM 1.2 are so different that there may
> be little or no code in common.
>
> My immediate need is for a 2.0 resource manager, since it's a gap in
> the technology, while 1.2 does have tcsd.

In the FWIW department.

I influence architecture and engineering for a company which builds
deterministically modeled and attested computing platforms for high
security assurance environments.  This entity actually builds systems
based on TPM1.2 and TPM2 hardware.  TPM2 prototypes were being
developed based on the simulator which came out of Ken's lab as soon
as it was first made available.

The kernel needs a resource manager.  Everyone needs to think VERY
hard and VERY, VERY carefully about what gets put into the kernel.  In
making a decision, put the ABSOLUTE smallest amount of code into the
kernel which allows various 'TPM2 personalities' to be implemented in
userspace and functionally verified and protected by the physical
instance.  The emergence of commodity TEE's (SGX, et.al) should be in
the back of everyone's mind as a factor in the roadmap.

Repeat incessantly to oneself, TPM1.2 and TPM2 are only similar by
virtue of sharing three ASCII characters.

DO NOT rush this process.  If we do not get this right we will
ultimately end up trying to shove something which is conceptually
worse then tss/tscd into the kernel.

Repeat incesssantly to oneself, policy does not belong in the kernel.

Pay homage to Ken, his TSS2 and TPM2 simulator work are beyond
excellent...

Greg

}-- End of excerpt from Ken Goldman

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"... you should really focus more on simplifying your life.  I
 actually spend most of my time finding ways to de-clog my brain."
                                -- Sarah Wettstein
                                   At the lake

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Kenneth Goldman]

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

"Dr. Greg Wettstein" <greg-DHO+NtfOqB5PEDpkEIzg7wC/G2K4zDHf@public.gmane.org> wrote on 01/04/2017 11:12:41 
AM:

> The kernel needs a resource manager.  Everyone needs to think VERY
> hard and VERY, VERY carefully about what gets put into the kernel.  In
> making a decision, put the ABSOLUTE smallest amount of code into the
> kernel ...

If you're a TCG member, I invite you to join the TSS WG.  I'd like
an ally for simplicity.
 
> Repeat incessantly to oneself, TPM1.2 and TPM2 are only similar by
> virtue of sharing three ASCII characters.

:-) I have to remember that one!

But, to be accurate, the hardware interface is nearly compatible, and
the high level concepts (key hierarchy, authorization, PCRs, BV space) 
are similar.  The API and implementation are new.

> DO NOT rush this process.  If we do not get this right we will
> ultimately end up trying to shove something which is conceptually
> worse then tss/tscd into the kernel.

The (only?) reason to put any of this in the kernel is that the kernel
also needs access to the TPM. 

> Pay homage to Ken, his TSS2 and TPM2 simulator work are beyond
> excellent...

Thank you.



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

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- 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: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein wrote:
> The kernel needs a resource manager.  Everyone needs to think VERY
> hard and VERY, VERY carefully about what gets put into the kernel.  In
> making a decision, put the ABSOLUTE smallest amount of code into the
> kernel which allows various 'TPM2 personalities' to be implemented in
> userspace and functionally verified and protected by the physical
> instance.  The emergence of commodity TEE's (SGX, et.al) should be in
> the back of everyone's mind as a factor in the roadmap.

Here's my cuts for the kernel:

- Kernel virtualizes handle areas. It's mechanical.
- Kernel does not virtualize bodies. It's not mechanical.
- At least the first version of the RM will not do other than session
  isolation for sessions.

This keeps the core for RM inside the kernel small and tight.

If we start to do some weird shit to the bodies that we think is 
good after long hours over engineering, the implementation will be
a failure. In the user space the way bodies are virtualizes is easier
to fine-tune because it doesn't break every possible app using the
in-kernel RM.

/Jarkko

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Ken Goldman]

On 1/9/2017 6:16 PM, Jarkko Sakkinen wrote:
>
> Here's my cuts for the kernel:
>
> - Kernel virtualizes handle areas. It's mechanical.
> - Kernel does not virtualize bodies. It's not mechanical.
> - At least the first version of the RM will not do other than session
>   isolation for sessions.

Is it correct that "bodies" are the parameter area of the commands and 
responses?

if so, eventually something should virtualize getcapability.  It may be 
safer in user space, but it can mask RM issues.

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Ken Goldman]

On 1/9/2017 6:16 PM, Jarkko Sakkinen wrote:
>
> Here's my cuts for the kernel:
>
> - Kernel virtualizes handle areas. It's mechanical.
> - Kernel does not virtualize bodies. It's not mechanical.
> - At least the first version of the RM will not do other than session
>   isolation for sessions.

Is it correct that "bodies" are the parameter area of the commands and 
responses?

if so, eventually something should virtualize getcapability.  It may be 
safer in user space, but it can mask RM issues.

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote:
> On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein wrote:
> > The kernel needs a resource manager.  Everyone needs to think VERY
> > hard and VERY, VERY carefully about what gets put into the kernel.  In
> > making a decision, put the ABSOLUTE smallest amount of code into the
> > kernel which allows various 'TPM2 personalities' to be implemented in
> > userspace and functionally verified and protected by the physical
> > instance.  The emergence of commodity TEE's (SGX, et.al) should be in
> > the back of everyone's mind as a factor in the roadmap.
> 
> Here's my cuts for the kernel:
> 
> - Kernel virtualizes handle areas. It's mechanical.
> - Kernel does not virtualize bodies. It's not mechanical.
> - At least the first version of the RM will not do other than session
>   isolation for sessions.
> 
> This keeps the core for RM inside the kernel small and tight.

I think this makes sense.

In addition the kernel should only permit RM operations that are known
to be 100% correct with the RM.

I think you should stick with your original design basic design,
except instead of using an ioctl to switch modes, use an ioctl to
execute the operation:

struct tpm_ioctl_operation {
   u16 mode;  // == TPM1_RAW,TPM2_RAW,TPM1_RM,TPM2_RM
   u16 locality;
   u32 txlen;
   u32 rxlen;
   const void *txbuf;
   void *rxbuf;
};

The userspace broker would be expected to use a mixture of RM and RAW
operations.

Let's deal with the idea of another cdev some other day when someone
can figure out a comprehensive way to do that securely for unpriv..

Jason

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Andreas Fuchs]

Am 10.01.2017 um 21:05 schrieb Jason Gunthorpe:
> On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote:
>> On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein wrote:
>>> The kernel needs a resource manager.  Everyone needs to think VERY
>>> hard and VERY, VERY carefully about what gets put into the kernel.  In
>>> making a decision, put the ABSOLUTE smallest amount of code into the
>>> kernel which allows various 'TPM2 personalities' to be implemented in
>>> userspace and functionally verified and protected by the physical
>>> instance.  The emergence of commodity TEE's (SGX, et.al) should be in
>>> the back of everyone's mind as a factor in the roadmap.
>> Here's my cuts for the kernel:
>>
>> - Kernel virtualizes handle areas. It's mechanical.
>> - Kernel does not virtualize bodies. It's not mechanical.
>> - At least the first version of the RM will not do other than session
>>    isolation for sessions.
>>
>> This keeps the core for RM inside the kernel small and tight.

You need to do virtualization inside bodies, because TPM2_FlushContext 
carries it's handles inside the parameter body.
Yep, huge blunder in the TPM spec, but hey, time for quirks... ;-)

> I think this makes sense.
>
> In addition the kernel should only permit RM operations that are known
> to be 100% correct with the RM.
>
> I think you should stick with your original design basic design,
> except instead of using an ioctl to switch modes, use an ioctl to
> execute the operation:
>
> struct tpm_ioctl_operation {
>     u16 mode;  // == TPM1_RAW,TPM2_RAW,TPM1_RM,TPM2_RM
>     u16 locality;
>     u32 txlen;
>     u32 rxlen;
>     const void *txbuf;
>     void *rxbuf;
> };

could we please get an ioctl, that switches the "mode" of the fd entirely.
I'd like to see the write()/read() support still intact.
All my current code uses main-loop based poll on the fd and I don't want
to be force to start using threads...

Thanks,
Andreas

>
> The userspace broker would be expected to use a mixture of RM and RAW
> operations.
>
> Let's deal with the idea of another cdev some other day when someone
> can figure out a comprehensive way to do that securely for unpriv..
>
> Jason
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> tpmdd-devel mailing list
> tpmdd-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Andreas Fuchs]

Am 10.01.2017 um 21:05 schrieb Jason Gunthorpe:
> On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote:
>> On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein wrote:
>>> The kernel needs a resource manager.  Everyone needs to think VERY
>>> hard and VERY, VERY carefully about what gets put into the kernel.  In
>>> making a decision, put the ABSOLUTE smallest amount of code into the
>>> kernel which allows various 'TPM2 personalities' to be implemented in
>>> userspace and functionally verified and protected by the physical
>>> instance.  The emergence of commodity TEE's (SGX, et.al) should be in
>>> the back of everyone's mind as a factor in the roadmap.
>> Here's my cuts for the kernel:
>>
>> - Kernel virtualizes handle areas. It's mechanical.
>> - Kernel does not virtualize bodies. It's not mechanical.
>> - At least the first version of the RM will not do other than session
>>    isolation for sessions.
>>
>> This keeps the core for RM inside the kernel small and tight.

You need to do virtualization inside bodies, because TPM2_FlushContext 
carries it's handles inside the parameter body.
Yep, huge blunder in the TPM spec, but hey, time for quirks... ;-)

> I think this makes sense.
>
> In addition the kernel should only permit RM operations that are known
> to be 100% correct with the RM.
>
> I think you should stick with your original design basic design,
> except instead of using an ioctl to switch modes, use an ioctl to
> execute the operation:
>
> struct tpm_ioctl_operation {
>     u16 mode;  // == TPM1_RAW,TPM2_RAW,TPM1_RM,TPM2_RM
>     u16 locality;
>     u32 txlen;
>     u32 rxlen;
>     const void *txbuf;
>     void *rxbuf;
> };

could we please get an ioctl, that switches the "mode" of the fd entirely.
I'd like to see the write()/read() support still intact.
All my current code uses main-loop based poll on the fd and I don't want
to be force to start using threads...

Thanks,
Andreas

>
> The userspace broker would be expected to use a mixture of RM and RAW
> operations.
>
> Let's deal with the idea of another cdev some other day when someone
> can figure out a comprehensive way to do that securely for unpriv..
>
> Jason
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> tpmdd-devel mailing list
> tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Tue, Jan 10, 2017 at 01:05:58PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote:
> > On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein wrote:
> > > The kernel needs a resource manager.  Everyone needs to think VERY
> > > hard and VERY, VERY carefully about what gets put into the kernel.  In
> > > making a decision, put the ABSOLUTE smallest amount of code into the
> > > kernel which allows various 'TPM2 personalities' to be implemented in
> > > userspace and functionally verified and protected by the physical
> > > instance.  The emergence of commodity TEE's (SGX, et.al) should be in
> > > the back of everyone's mind as a factor in the roadmap.
> > 
> > Here's my cuts for the kernel:
> > 
> > - Kernel virtualizes handle areas. It's mechanical.
> > - Kernel does not virtualize bodies. It's not mechanical.
> > - At least the first version of the RM will not do other than session
> >   isolation for sessions.
> > 
> > This keeps the core for RM inside the kernel small and tight.
> 
> I think this makes sense.
> 
> In addition the kernel should only permit RM operations that are known
> to be 100% correct with the RM.
> 
> I think you should stick with your original design basic design,
> except instead of using an ioctl to switch modes, use an ioctl to
> execute the operation:
> 
> struct tpm_ioctl_operation {
>    u16 mode;  // == TPM1_RAW,TPM2_RAW,TPM1_RM,TPM2_RM
>    u16 locality;
>    u32 txlen;
>    u32 rxlen;
>    const void *txbuf;
>    void *rxbuf;
> };
> 
> The userspace broker would be expected to use a mixture of RM and RAW
> operations.
> 
> Let's deal with the idea of another cdev some other day when someone
> can figure out a comprehensive way to do that securely for unpriv..

James, what do you think about this proposal?

/Jarkko

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Tue, Jan 10, 2017 at 01:05:58PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote:
> > On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein wrote:
> > > The kernel needs a resource manager.  Everyone needs to think VERY
> > > hard and VERY, VERY carefully about what gets put into the kernel.  In
> > > making a decision, put the ABSOLUTE smallest amount of code into the
> > > kernel which allows various 'TPM2 personalities' to be implemented in
> > > userspace and functionally verified and protected by the physical
> > > instance.  The emergence of commodity TEE's (SGX, et.al) should be in
> > > the back of everyone's mind as a factor in the roadmap.
> > 
> > Here's my cuts for the kernel:
> > 
> > - Kernel virtualizes handle areas. It's mechanical.
> > - Kernel does not virtualize bodies. It's not mechanical.
> > - At least the first version of the RM will not do other than session
> >   isolation for sessions.
> > 
> > This keeps the core for RM inside the kernel small and tight.
> 
> I think this makes sense.
> 
> In addition the kernel should only permit RM operations that are known
> to be 100% correct with the RM.
> 
> I think you should stick with your original design basic design,
> except instead of using an ioctl to switch modes, use an ioctl to
> execute the operation:
> 
> struct tpm_ioctl_operation {
>    u16 mode;  // == TPM1_RAW,TPM2_RAW,TPM1_RM,TPM2_RM
>    u16 locality;
>    u32 txlen;
>    u32 rxlen;
>    const void *txbuf;
>    void *rxbuf;
> };
> 
> The userspace broker would be expected to use a mixture of RM and RAW
> operations.
> 
> Let's deal with the idea of another cdev some other day when someone
> can figure out a comprehensive way to do that securely for unpriv..

James, what do you think about this proposal?

/Jarkko


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Tue, Jan 10, 2017 at 02:29:08PM -0500, Ken Goldman wrote:
> On 1/9/2017 6:16 PM, Jarkko Sakkinen wrote:
> > 
> > Here's my cuts for the kernel:
> > 
> > - Kernel virtualizes handle areas. It's mechanical.
> > - Kernel does not virtualize bodies. It's not mechanical.
> > - At least the first version of the RM will not do other than session
> >   isolation for sessions.
> 
> Is it correct that "bodies" are the parameter area of the commands and
> responses?
> 
> if so, eventually something should virtualize getcapability.  It may be
> safer in user space, but it can mask RM issues.

body == command / response - (header + handle area)

/Jarkko

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Wed, 2017-01-11 at 13:34 +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 10, 2017 at 01:05:58PM -0700, Jason Gunthorpe wrote:
> > On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote:
> > > On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein
> > > wrote:
> > > > The kernel needs a resource manager.  Everyone needs to think 
> > > > VERY hard and VERY, VERY carefully about what gets put into the
> > > > kernel.  In making a decision, put the ABSOLUTE smallest amount 
> > > > of code into the kernel which allows various 'TPM2 
> > > > personalities' to be implemented in userspace and functionally 
> > > > verified and protected by the physical instance.  The emergence 
> > > > of commodity TEE's (SGX, et.al) should be in the back of
> > > > everyone's mind as a factor in the roadmap.
> > > 
> > > Here's my cuts for the kernel:
> > > 
> > > - Kernel virtualizes handle areas. It's mechanical.
> > > - Kernel does not virtualize bodies. It's not mechanical.
> > > - At least the first version of the RM will not do other than
> > > session
> > >   isolation for sessions.
> > > 
> > > This keeps the core for RM inside the kernel small and tight.
> > 
> > I think this makes sense.
> > 
> > In addition the kernel should only permit RM operations that are 
> > known to be 100% correct with the RM.
> > 
> > I think you should stick with your original design basic design,
> > except instead of using an ioctl to switch modes, use an ioctl to
> > execute the operation:
> > 
> > struct tpm_ioctl_operation {
> >    u16 mode;  // == TPM1_RAW,TPM2_RAW,TPM1_RM,TPM2_RM
> >    u16 locality;
> >    u32 txlen;
> >    u32 rxlen;
> >    const void *txbuf;
> >    void *rxbuf;
> > };
> > 
> > The userspace broker would be expected to use a mixture of RM and 
> > RAW operations.
> > 
> > Let's deal with the idea of another cdev some other day when 
> > someone can figure out a comprehensive way to do that securely for
> > unpriv..
> 
> James, what do you think about this proposal?

I don't think it's a good idea for the reasons stated before:

RAW access means the ability to DoS the TPM simply by exhausting
handles.  Therefore, I think most applications only get RM access.  If
you adopt this proposal, then, if you're only opening a single fd, we
can't go by the unix permissions (even the RM only applications need to
open it), so we'd need some permissions infrastructure within the
kernel to reject RAW access from RM only users.  That's why having
multiple devices is much better because we can use the usual UNIX
mechanism to separate access from raw and rm.  I'm less sure about
localities, but there may be the same issue at some point (not all
applications get access to all localities).  It would be good to get
the localities use case sorted out before adding it to an ioctl based
interfaces.

James

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Wed, 2017-01-11 at 13:34 +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 10, 2017 at 01:05:58PM -0700, Jason Gunthorpe wrote:
> > On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote:
> > > On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein
> > > wrote:
> > > > The kernel needs a resource manager.  Everyone needs to think 
> > > > VERY hard and VERY, VERY carefully about what gets put into the
> > > > kernel.  In making a decision, put the ABSOLUTE smallest amount 
> > > > of code into the kernel which allows various 'TPM2 
> > > > personalities' to be implemented in userspace and functionally 
> > > > verified and protected by the physical instance.  The emergence 
> > > > of commodity TEE's (SGX, et.al) should be in the back of
> > > > everyone's mind as a factor in the roadmap.
> > > 
> > > Here's my cuts for the kernel:
> > > 
> > > - Kernel virtualizes handle areas. It's mechanical.
> > > - Kernel does not virtualize bodies. It's not mechanical.
> > > - At least the first version of the RM will not do other than
> > > session
> > >   isolation for sessions.
> > > 
> > > This keeps the core for RM inside the kernel small and tight.
> > 
> > I think this makes sense.
> > 
> > In addition the kernel should only permit RM operations that are 
> > known to be 100% correct with the RM.
> > 
> > I think you should stick with your original design basic design,
> > except instead of using an ioctl to switch modes, use an ioctl to
> > execute the operation:
> > 
> > struct tpm_ioctl_operation {
> >    u16 mode;  // == TPM1_RAW,TPM2_RAW,TPM1_RM,TPM2_RM
> >    u16 locality;
> >    u32 txlen;
> >    u32 rxlen;
> >    const void *txbuf;
> >    void *rxbuf;
> > };
> > 
> > The userspace broker would be expected to use a mixture of RM and 
> > RAW operations.
> > 
> > Let's deal with the idea of another cdev some other day when 
> > someone can figure out a comprehensive way to do that securely for
> > unpriv..
> 
> James, what do you think about this proposal?

I don't think it's a good idea for the reasons stated before:

RAW access means the ability to DoS the TPM simply by exhausting
handles.  Therefore, I think most applications only get RM access.  If
you adopt this proposal, then, if you're only opening a single fd, we
can't go by the unix permissions (even the RM only applications need to
open it), so we'd need some permissions infrastructure within the
kernel to reject RAW access from RM only users.  That's why having
multiple devices is much better because we can use the usual UNIX
mechanism to separate access from raw and rm.  I'm less sure about
localities, but there may be the same issue at some point (not all
applications get access to all localities).  It would be good to get
the localities use case sorted out before adding it to an ioctl based
interfaces.

James



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Ken Goldman]

On 1/11/2017 5:00 AM, Andreas Fuchs wrote:
>
> You need to do virtualization inside bodies, because TPM2_FlushContext
> carries it's handles inside the parameter body.
> Yep, huge blunder in the TPM spec, but hey, time for quirks... ;-)

It's not huge, not even a blunder.  The TPM spec Part 3 has a note 
explaining why the TPM side does it that way.

For the TSS and resource manager, simply treat flushHandle as a handle 
(in the handle area rather than in the parameter/body area).  It all 
just works.  I modified the TSS as a test, and there's no issue at all.



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Wed, Jan 11, 2017 at 07:39:53AM -0800, James Bottomley wrote:
 
> RAW access means the ability to DoS the TPM simply by exhausting
> handles.  Therefore, I think most applications only get RM access.

Re-read what Jarkko is proposing. He is not making a complete safe &
secure RM in the kernel. He is making a tool to allow userspace and
the kernel to share the TPM sanely.

It is not an access control tool, it is not a security tool, it is not
intended to support safe unpriv userspace access.

So there is no reason to have a different access control model in
userspace, it is not a fundamentally different security environment
from the existing raw device.

A future project to provide an unpriv safe cdev from the kernel is
something different.

Jason

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Wed, Jan 11, 2017 at 07:39:53AM -0800, James Bottomley wrote:
 
> RAW access means the ability to DoS the TPM simply by exhausting
> handles.  Therefore, I think most applications only get RM access.

Re-read what Jarkko is proposing. He is not making a complete safe &
secure RM in the kernel. He is making a tool to allow userspace and
the kernel to share the TPM sanely.

It is not an access control tool, it is not a security tool, it is not
intended to support safe unpriv userspace access.

So there is no reason to have a different access control model in
userspace, it is not a fundamentally different security environment
from the existing raw device.

A future project to provide an unpriv safe cdev from the kernel is
something different.

Jason

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Wed, Jan 11, 2017 at 11:00:43AM +0100, Andreas Fuchs wrote:

> could we please get an ioctl, that switches the "mode" of the fd entirely.
> I'd like to see the write()/read() support still intact.
> All my current code uses main-loop based poll on the fd and I don't want
> to be force to start using threads...

We currently do not support poll in the kernel for /dev/tpmX.

ie we do not supply a poll method for 'struct file_operations'.

Even worse, the current implementation blocks returning from write()
until the TPM has completed its work, so it doesn't even make sense to
combine it with poll.

Jason

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Wed, Jan 11, 2017 at 11:00:43AM +0100, Andreas Fuchs wrote:

> could we please get an ioctl, that switches the "mode" of the fd entirely.
> I'd like to see the write()/read() support still intact.
> All my current code uses main-loop based poll on the fd and I don't want
> to be force to start using threads...

We currently do not support poll in the kernel for /dev/tpmX.

ie we do not supply a poll method for 'struct file_operations'.

Even worse, the current implementation blocks returning from write()
until the TPM has completed its work, so it doesn't even make sense to
combine it with poll.

Jason

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Wed, 2017-01-11 at 10:56 -0700, Jason Gunthorpe wrote:
> On Wed, Jan 11, 2017 at 07:39:53AM -0800, James Bottomley wrote:
> 
> > RAW access means the ability to DoS the TPM simply by exhausting
> > handles.  Therefore, I think most applications only get RM access.
> 
> Re-read what Jarkko is proposing. He is not making a complete safe &
> secure RM in the kernel. He is making a tool to allow userspace and
> the kernel to share the TPM sanely.
> 
> It is not an access control tool, it is not a security tool, it is 
> not intended to support safe unpriv userspace access.
> 
> So there is no reason to have a different access control model in
> userspace, it is not a fundamentally different security environment
> from the existing raw device.
> 
> A future project to provide an unpriv safe cdev from the kernel is
> something different.

Right, but we're going around in circles.  I'm currently researching
what it would take to be daemonless, so an ioctl which requires an
access broker daemon would obviously be something I'd object to.

Basically, though, I think you can do both: we can add an ioctl and the
differing device hooks.  I just think for that case RAW vs RM would be
redundant.

James

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Stefan Berger]

On 01/11/2017 01:03 PM, Jason Gunthorpe wrote:
> On Wed, Jan 11, 2017 at 11:00:43AM +0100, Andreas Fuchs wrote:
>
>> could we please get an ioctl, that switches the "mode" of the fd entirely.
>> I'd like to see the write()/read() support still intact.
>> All my current code uses main-loop based poll on the fd and I don't want
>> to be force to start using threads...
> We currently do not support poll in the kernel for /dev/tpmX.
>
> ie we do not supply a poll method for 'struct file_operations'.
>
> Even worse, the current implementation blocks returning from write()
> until the TPM has completed its work, so it doesn't even make sense to
> combine it with poll.

Newer applications could issue an ioctl() after the open() to unblock 
the write().

     Stefan

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Stefan Berger]

On 01/11/2017 01:03 PM, Jason Gunthorpe wrote:
> On Wed, Jan 11, 2017 at 11:00:43AM +0100, Andreas Fuchs wrote:
>
>> could we please get an ioctl, that switches the "mode" of the fd entirely.
>> I'd like to see the write()/read() support still intact.
>> All my current code uses main-loop based poll on the fd and I don't want
>> to be force to start using threads...
> We currently do not support poll in the kernel for /dev/tpmX.
>
> ie we do not supply a poll method for 'struct file_operations'.
>
> Even worse, the current implementation blocks returning from write()
> until the TPM has completed its work, so it doesn't even make sense to
> combine it with poll.

Newer applications could issue an ioctl() after the open() to unblock 
the write().

     Stefan


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Wed, Jan 11, 2017 at 10:25:57AM -0800, James Bottomley wrote:

> Right, but we're going around in circles.  I'm currently researching
> what it would take to be daemonless, so an ioctl which requires an
> access broker daemon would obviously be something I'd object to.

Well, when we figure out a security model that works for that and can
be implemented in the kernel then lets add the new cdev.

But that is *explicitly* not what Jarkko is doing, no reason to jump
the gun.

> Basically, though, I think you can do both: we can add an ioctl and the
> differing device hooks.  I just think for that case RAW vs RM would be
> redundant.

Right, some future new cdev would only support ioctl and only the RM
path, but for priv use having both concurrently available makes sense
as a userspace broker producing a full RM will need to using both paths.

Jason

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Wed, Jan 11, 2017 at 01:27:30PM -0500, Stefan Berger wrote:
> On 01/11/2017 01:03 PM, Jason Gunthorpe wrote:
> >On Wed, Jan 11, 2017 at 11:00:43AM +0100, Andreas Fuchs wrote:
> >
> >>could we please get an ioctl, that switches the "mode" of the fd entirely.
> >>I'd like to see the write()/read() support still intact.
> >>All my current code uses main-loop based poll on the fd and I don't want
> >>to be force to start using threads...
> >We currently do not support poll in the kernel for /dev/tpmX.
> >
> >ie we do not supply a poll method for 'struct file_operations'.
> >
> >Even worse, the current implementation blocks returning from write()
> >until the TPM has completed its work, so it doesn't even make sense to
> >combine it with poll.
> 
> Newer applications could issue an ioctl() after the open() to unblock the
> write().

The ioctl api I outlined could support poll by having userspace set
the rxbuf = NULL.

The kernel would then launch the tx async and provide poll support to
allow read() to return the result once the tpm has finished.

This can be added as a new capability down the road..

Jason

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Ken Goldman]

On 1/5/2017 2:20 PM, Jason Gunthorpe wrote:
>
> I'd rather give up features (eg policy sessions, if necessary) for the
> unpriv fd than give up security of the unpriv fd.

Please don't give up policy.  Nearly every use case of that we think of 
for TPM 2.0 uses policy sessions.

E.g.,

In 1.2, PCR authorization was built in to the object.  In 2.0, it's a 
policy.

In 1.2, key types were restricted to certain commands.  In 2.0, it's a 
policy.

Then there are all the new use cases - time restricted keys, use count 
restricted keys, keys with a PIN, etc., all use policy.

Even use of the EK primary key requires a policy, and that's needed for 
salt (getting the first password in securely) and attestation (proof 
that the TPM is authentic).

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Ken Goldman]

On 1/5/2017 2:20 PM, Jason Gunthorpe wrote:
>
> I'd rather give up features (eg policy sessions, if necessary) for the
> unpriv fd than give up security of the unpriv fd.

Please don't give up policy.  Nearly every use case of that we think of 
for TPM 2.0 uses policy sessions.

E.g.,

In 1.2, PCR authorization was built in to the object.  In 2.0, it's a 
policy.

In 1.2, key types were restricted to certain commands.  In 2.0, it's a 
policy.

Then there are all the new use cases - time restricted keys, use count 
restricted keys, keys with a PIN, etc., all use policy.

Even use of the EK primary key requires a policy, and that's needed for 
salt (getting the first password in securely) and attestation (proof 
that the TPM is authentic).



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Ken Goldman]

On 1/6/2017 3:43 AM, Andreas Fuchs wrote:
> Am 05.01.2017 um 19:06 schrieb James Bottomley:
>
> Then how about blocking
> TPM2_GetCapabilities(TPM_CAP_HANDLES, 0x80000000) ?

Even just for debugging, this is a really useful command.

Won't the RM have a mapping from TPM to RM handle for
transient objects anyway?




------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Ken Goldman]

On 1/3/2017 7:17 PM, Jason Gunthorpe wrote:
>
> Well, by policy you mean 'know the owner password' which at least I am
> *very* nervous about exposing beyond the super user - certainly in my
> embedded systems.

For TPM 2.0, the "owner" is mostly just the controller of the storage
hierarchy.  It's not a "super user", and is less privileged that even 
the TPM 1.2 owner.

For example, the TPM 2.0 owner cannot run TPM2_Clear.



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Fri, Jan 06, 2017 at 09:59:57AM +0100, Andreas Fuchs wrote:

> 1. PolicyPCR is an essential feature of TPM used all over the place,
> so we need support for policy sessions.
> 2. PolicySigned allows authentication of the user via SmartCard.

Are smart cards 0666 in linux?

> The all-defeating reason for having in-kernel-RM is trusted keyrings
> or IMA/EVM appraise/protect or similar. They will want to use sealing
> to PCRs which in turn requires policy sessions from inside the kernel
> and thus RM inside the kernel to play nicely with the TSS.

Yes. I had hoped the in-kernel-RM could also provide safe 0666 access,
but lets move on from that idea and focus on kernel/user TPM
application co-existence...

> And IMHO nobody wants the kernel security modules to call back to a
> userspace RM-daemon.

Yep.

> If everyone agrees with this presumption the only question becomes
> how to do this, such that we don't need a second RM in userspace
> for the 99% of use cases.

Yep.

> P.S. This fact should also be given some thought when discussing the
> priviledged 0600 node, i.e. /dev/tpm0 without the s in the middle.

We are stuck with the non-RM interface for compat. There could be a
kernel option/module option/sysctl/whatever of some kind to disable it
I guess.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Andreas Fuchs]

Am 06.01.2017 um 01:36 schrieb James Bottomley:
> On Thu, 2017-01-05 at 16:50 -0700, Jason Gunthorpe wrote:
>> On Thu, Jan 05, 2017 at 02:58:46PM -0800, James Bottomley wrote:
>>> On Thu, 2017-01-05 at 15:21 -0700, Jason Gunthorpe wrote:
>>>> On Thu, Jan 05, 2017 at 11:55:49AM -0800, James Bottomley wrote:
>>>>
>>>>> We don't really have that choice: Keys require authorization,
>>>>> so you have to have an auth session.
>>>> I know, this is why I suggested a combo op (kernel level
>>>> atomicity is clearly DOS safe)..
>>> Transactions are a hard thing to guarantee to be DoS safe and the
>>> more complex they get, the more difficult they are to police within
>>> the kernel.  Plus we have to keep the R/W interface for backwards
>>> compatibility now that we have it and I just don't see how we could
>>> layer transactions into it without having some sort of in-kernel
>>> emulator.
>> Again, this was only to make the unpriv FD usable and safe against
>> session DOS and that FD wouldn't use the legacy r/w interface. I
>> don't care if root can DOS the TPM via /dev/tpm0. combo ops would
>> need to be simple enough to reason about. (in my TPM libaries API
>> calls are combo'd with session anyhow, and that works quite well for
>> my use models)
> In Ken's TSS2 they are for simple authorisation.  However, policy auth
> is where it gets tricky and right at the moment I believe I need policy
> based authorisation for keys.

I don't think this is TSS-specific. It also holds true for the TCG-TSS.

The thing is that you will need both, HMAC and Policy Sessions in
standard userspace applications (not only the exotic ones)...
... and they must not be time-based leases, because other IO or
user-UI might happen.

Reasons:
1. PolicyPCR is an essential feature of TPM used all over the place,
so we need support for policy sessions.
2. PolicySigned allows authentication of the user via SmartCard.
So the application will have to challenge back using the challenge
from the TPM. So no timeouts please.
3. HMAC-sessions could also be handled via authentication tokens
that take the cpHash and session as challenge and provide an
HMAC. Again we'd have IO and user interaction.

In summary, in TCG we came to the conclusion that kicking out
sessions is the best approach. IMHO session quotas per process,
user, cgroup is even better, but was not possible in the TCG spec
for a user-space cross-OS RM (no notion of such capabilities).

We spent several f2f-meetings, confcalls and emails on this topic
inside the TCG. I'd advice everyone to look into the RM-spec and
coming updates, and especially TCG members to look into potential
unrelease documents on these issues. Feel free to contact me as
well for any TCG-insights.

>>>> Lets stick with the user space broker process and just introduce
>>>> enough kernel RM to enable co-existance with kernel users and
>>>> clean -up on crash. This should be enough to make a user space
>>>> broker much simpler.
>>> I wouldn't go that far.  I'm still planning a userspace tss2
>>> without any access broker daemon, but let's see how far I get on
>>> top of the RM.  I think building in stages is a good way to get
>>> actual use experience to guide the next stage.
>> I'm sure you can implement what you are doing on top of the RM -
>> that isn't a question in my mind.
>>
>> My question has always been how does your plugin deliver messages to
>> the kernel RM in a way that does not compromise the security of the
>> TPM system.
> So currently, it doesn't: I have to either run as root or run a udev
> script to give me access to the device, neither of which will work out
> of the box for distributions because of the security risks you
> identified.  I think this is OK for now because the security issue only
> has to be sorted out before we make this ready for general release
> (i.e. advise the distros how to expose the TPM) and we need to gather
> use case data before we do that.

The all-defeating reason for having in-kernel-RM is trusted keyrings
or IMA/EVM appraise/protect or similar. They will want to use sealing
to PCRs which in turn requires policy sessions from inside the kernel
and thus RM inside the kernel to play nicely with the TSS. TCG's TSS
had to add an ugly quirk into its spec in order to work with current
trusted keyrings uapi that I really want to deprecate.
And IMHO nobody wants the kernel security modules to call back
to a userspace RM-daemon.

If everyone agrees with this presumption the only question becomes
how to do this, such that we don't need a second RM in userspace
for the 99% of use cases.

P.S. This fact should also be given some thought when discussing the
priviledged 0600 node, i.e. /dev/tpm0 without the s in the middle.

Cheers,
Andreas




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Andreas Fuchs]

Am 05.01.2017 um 19:06 schrieb James Bottomley:
> On Thu, 2017-01-05 at 10:27 -0700, Jason Gunthorpe wrote:
>> On Thu, Jan 05, 2017 at 03:52:02PM +0000, Fuchs, Andreas wrote:
>>> Great to see this coming along so well. Thanks a lot to Jarkko !
>>> The TPM allows an application to get the list of currently loaded
>>> handles TPM2_GetCapabilities(TPM_CAP_HANDLES).  It would be great
>>> to have the RM be as transparent to userspace as possible. The RM
>>> spec of TCG therefore says that you need to intercept and override
>>> this
>> I'd rather just ban unnecessary stuff like this on the RM fd.
>> Tracking active handles can be done in userspace by the app
>> itself. Debugging can be done by using the non-RM fd or debugfs.
> Yes, we basically agreed on not doing this.  The only handles that
> actually need translating are the transient 0x80 ones.  Since the RM
> effectively segregates them, you can't see anyone else's, so the only
> query could be about the application's own transient handles and it's
> difficult to see how it could lose track of them and want to issue this
> query.  So the best course is to leave it unimplemented (less code) and
> see if anyone complains because they have an actual use case.

Then how about blocking
TPM2_GetCapabilities(TPM_CAP_HANDLES, 0x80000000) ?

My concern is with a consistent view, so you either get the correct
result or no result, but please no false results...

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Thu, Jan 05, 2017 at 02:58:46PM -0800, James Bottomley wrote:
> On Thu, 2017-01-05 at 15:21 -0700, Jason Gunthorpe wrote:
> > On Thu, Jan 05, 2017 at 11:55:49AM -0800, James Bottomley wrote:
> > 
> > > We don't really have that choice: Keys require authorization, so 
> > > you have to have an auth session.
> > 
> > I know, this is why I suggested a combo op (kernel level atomicity
> > is clearly DOS safe)..
> 
> Transactions are a hard thing to guarantee to be DoS safe and the more
> complex they get, the more difficult they are to police within the
> kernel.  Plus we have to keep the R/W interface for backwards
> compatibility now that we have it and I just don't see how we could
> layer transactions into it without having some sort of in-kernel
> emulator.

Again, this was only to make the unpriv FD usable and safe against
session DOS and that FD wouldn't use the legacy r/w interface. I don't
care if root can DOS the TPM via /dev/tpm0. combo ops would need to be
simple enough to reason about. (in my TPM libaries API calls are
combo'd with session anyhow, and that works quite well for my use
models)

> > Lets stick with the user space broker process and just introduce
> > enough kernel RM to enable co-existance with kernel users and clean
> > -up on crash. This should be enough to make a user space broker much
> > simpler.
> 
> I wouldn't go that far.  I'm still planning a userspace tss2 without
> any access broker daemon, but let's see how far I get on top of the RM.
>  I think building in stages is a good way to get actual use experience
> to guide the next stage.

I'm sure you can implement what you are doing on top of the RM -
that isn't a question in my mind.

My question has always been how does your plugin deliver messages to
the kernel RM in a way that does not compromise the security of the
TPM system.

> > So Jarkko's uapi is basically fine.. No need for a kernel white
> > list/etc
> 
> I suspect we'll eventually get to needing one, but I'm happy to
> begin

IMHO the problem with trousers as a broker is just how horribly
complex it was.

With the kernel RM this problem becomes very simple:

 - 1:1 relationship between incoming clients and kernel fds (Jarkko's
   existing design allows a broker to safely create many RM fds)
 - Trivial inspection of messages to determine op and check whitelist
   (just the first couple bytes give you the opcode, easy to deep
    inspect things like get capability)
 - No marshal/demarshal, no virtualization, no crypto.
   (kernel does virtualization, client does marshal and crypto)
   
I'm not sure what reason would be big enough to put it in the kernel
when we seem to have irreconcilable use models for the security policy
it needs to implement...

Maybe that is OK, but it isn't what I was hoping for at the start :)

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Thu, 2017-01-05 at 15:21 -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 11:55:49AM -0800, James Bottomley wrote:
> 
> > We don't really have that choice: Keys require authorization, so 
> > you have to have an auth session.
> 
> I know, this is why I suggested a combo op (kernel level atomicity
> is clearly DOS safe)..

Transactions are a hard thing to guarantee to be DoS safe and the more
complex they get, the more difficult they are to police within the
kernel.  Plus we have to keep the R/W interface for backwards
compatibility now that we have it and I just don't see how we could
layer transactions into it without having some sort of in-kernel
emulator.

> > If you want things like PCR sealed or time limited keys, you don't
> > really have a choice on policy sessions either.
> 
> .. and advanced stuff like is what I was talking about giving up for
> unpriv if it can't be allowed safely ...
> 
> > I think we've got to the point where arguing about our divergent 
> > use requirements shows the default should be 0600 and every command
> > enabled so that whatever changes the device to 0666 also applies 
> > the command
> 
> Well, that is what we already have with /dev/tpm0.

Except that doesn't have the RM.

> I'm very surprised by this level of disagreement, so I'm inclined to
> drop the idea that the kernel can directly support a 0666 cdev at
> all.

Great.  We'll keep it at 0600 and let userspace sort it out; that way
policy becomes flexible too.

> Lets stick with the user space broker process and just introduce
> enough kernel RM to enable co-existance with kernel users and clean
> -up on crash. This should be enough to make a user space broker much
> simpler.

I wouldn't go that far.  I'm still planning a userspace tss2 without
any access broker daemon, but let's see how far I get on top of the RM.
 I think building in stages is a good way to get actual use experience
to guide the next stage.

> So Jarkko's uapi is basically fine.. No need for a kernel white
> list/etc

I suspect we'll eventually get to needing one, but I'm happy to begin
without and see what that experience tells us before we try to build
it.  This is actually a better way of doing stuff because we can add to
an API based on what we find in the field; the hard thing is pulling
back an API that doesn't work.

> I had really hoped we could have a secure default 0666 cdev that
> would be able to support the basic use of your user space plugins
> without a daemon :(

I think we can; I just don't think we can define a single in-kernel use
policy that supports everyone's use case, so punting to userspace and
letting it sort out the desired policy for the platform will work for
everyone.

James


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Thu, Jan 05, 2017 at 11:55:49AM -0800, James Bottomley wrote:

> We don't really have that choice: Keys require authorization, so you
> have to have an auth session.

I know, this is why I suggested a combo op (kernel level atomicity
is clearly DOS safe)..

> If you want things like PCR sealed or time limited keys, you don't
> really have a choice on policy sessions either.

.. and advanced stuff like is what I was talking about giving up for
unpriv if it can't be allowed safely ...

> I think we've got to the point where arguing about our divergent use
> requirements shows the default should be 0600 and every command enabled
> so that whatever changes the device to 0666 also applies the command

Well, that is what we already have with /dev/tpm0.

I'm very surprised by this level of disagreement, so I'm inclined to
drop the idea that the kernel can directly support a 0666 cdev at all.

Lets stick with the user space broker process and just introduce
enough kernel RM to enable co-existance with kernel users and clean-up
on crash. This should be enough to make a user space broker much
simpler.

So Jarkko's uapi is basically fine.. No need for a kernel white list/etc

I had really hoped we could have a secure default 0666 cdev that would
be able to support the basic use of your user space plugins without a
daemon :(

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Thu, Jan 05, 2017 at 10:33:43AM -0800, James Bottomley wrote:

> > A combo ioctl that could setup the session, issue an operation in it
> > and then delete the session, for instance.
> 
> This would work for encryption or HMAC sessions, but probably not for
> policy sessions, because they can have an arbitrarily large command
> sequence to construct them.

I'd rather give up features (eg policy sessions, if necessary) for the
unpriv fd than give up security of the unpriv fd.

We always have the out that special stuff can go down the priv path.

> The other issue we're likely to run into if we do it this way is
> delayed error reporting.

Not sure I follow.

> How about a more traditional approach which would be leasing (basically
> what we use for NFS).  Any application opening a session would have

Doesn't this just change the DOS vector? Now the attacker has to delay
execution of TPM commands long enough to force session leases to time
out. That isn't too hard to do, asking the TPM to make a RSA key can
take seconds, for instance.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Thu, 2017-01-05 at 10:27 -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 03:52:02PM +0000, Fuchs, Andreas wrote:
> > Great to see this coming along so well. Thanks a lot to Jarkko !
> 
> > The TPM allows an application to get the list of currently loaded
> > handles TPM2_GetCapabilities(TPM_CAP_HANDLES).  It would be great 
> > to have the RM be as transparent to userspace as possible. The RM 
> > spec of TCG therefore says that you need to intercept and override
> > this
> 
> I'd rather just ban unnecessary stuff like this on the RM fd.
> Tracking active handles can be done in userspace by the app
> itself. Debugging can be done by using the non-RM fd or debugfs.

Yes, we basically agreed on not doing this.  The only handles that
actually need translating are the transient 0x80 ones.  Since the RM
effectively segregates them, you can't see anyone else's, so the only
query could be about the application's own transient handles and it's
difficult to see how it could lose track of them and want to issue this
query.  So the best course is to leave it unimplemented (less code) and
see if anyone complains because they have an actual use case.

James



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Thu, Jan 05, 2017 at 03:52:02PM +0000, Fuchs, Andreas wrote:
> Great to see this coming along so well. Thanks a lot to Jarkko !

> The TPM allows an application to get the list of currently loaded
> handles TPM2_GetCapabilities(TPM_CAP_HANDLES).  It would be great to
> have the RM be as transparent to userspace as possible. The RM spec
> of TCG therefore says that you need to intercept and override this

I'd rather just ban unnecessary stuff like this on the RM fd.
Tracking active handles can be done in userspace by the app
itself. Debugging can be done by using the non-RM fd or debugfs.

IMHO we need to focus narrowly on enabling *specific* unpriviledged
user space use models and safe co-existence with kernel users.

> - Constant session handles (hurray):

> Sessions do not change their handles on contextsave/contextload, so
> you do not need to virtualize session handles.

The kernel still needs to track them, so they can be cleaned up and
access controlled.

> - Session Limits (here it gets ugly):

> Even thought the TPM supports the same swapping-scheme for sessions
> as it does for transient objects, it only allows for a limited
> number of session to be opened (64 in case of PC-Client), called
> active sessions.  This means that a single process can still DoS the
> TPM if it allocates 64 sessions, or 64 processes can DoS the TPM if

Well, if we have an unpriv fd then it should not be able to DOS the
system - that would suggest either that FD cannot use sessions or we
need some kernel solution to guarentee the DOS is not possible.

A combo ioctl that could setup the session, issue an operation in it
and then delete the session, for instance.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Fuchs, Andreas]

Great to see this coming along so well. Thanks a lot to Jarkko !
I just wanted to point out a few things I deem important at this point:

- Number of virtual handles:
>From what I see there are currently 14 slots for virtual objects in the RFC (if I'm mistaking, please correct me).
I'd advice to ask the TPM2_GetCapabilities(TPM_CAP_TPM_PROPERTIES, TPM_PT_HR_TRANSIENT_MIN or TPM_PT_HR_TRANSIENT_AVAIL)
[Note: there is no actual max, i.e. the TPM will allow more transient objects that e.g. 3 if they are small] 
and provide each TPM space with the same amount as the TPM will tell them is available.
If an application needs more objects, I'd see a per-fd mini-RM module inside the TSS-libraries handling that job quite well.
Same would apply for Session with TPM_PT_HR_LOADED_MIN and TPM_PT_HR_LOADED_AVAIL.
This will reduce the memory consumption inside the kernel and provide userspace with a consistent view on the GetCapabilities vs its actual Allocations.

- Enumeration of loaded (virtual) handles:
The TPM allows an application to get the list of currently loaded handles TPM2_GetCapabilities(TPM_CAP_HANDLES).
It would be great to have the RM be as transparent to userspace as possible. The RM spec of TCG therefore says that you need to intercept and override this command (unless it is run in an authentication session where you cannot override it, which is disadviced). It's a design choice, but I'd advice for it after long discussions.

- Constant session handles (hurray):
Sessions do not change their handles on contextsave/contextload, so you do not need to virtualize session handles.
In fact you must not do so, because cpHash-calculation needs to know the TPM's handle number for sessions on at least 1 command.
So this simplifies session handling inside the kernel since you do not need to alter the handle area for session handles.

- Session Limits (here it gets ugly):
Even thought the TPM supports the same swapping-scheme for sessions as it does for transient objects, it only allows for a limited number of session to be opened (64 in case of PC-Client), called active sessions.
This means that a single process can still DoS the TPM if it allocates 64 sessions, or 64 processes can DoS the TPM if they allocate 1 session each.
There are two principle solutions:
a) Limit the number of active sessions per fd, process, user and hope for the best. Of course this will not really protect you from DoS'ed TPMs.
b) Kick out old sessions whenever new sessions are requested and TPM is currently full (the TCG RM spec approach). Of course applications need to handle "randomly vanishing" hmac sessions in this case.

- Session ungaping (here it gets REALLY ugly):
The TPM has some scheme for handling sessions that are swapped (contextSaved) out. In this scheme, it can run into the case where it will deny actions on a session handle with a TPM2_RC_GAP error.
This error means that the time between last usage of the oldest session and the current session is too far apart.
The reaction needs to be that the RM loads this oldest sesssion (or in my implementation all swaped sessions) into the TPM and contextsave them back right away.
This becomes especially ugly, when enabling the ability of userspace to contextsave a session on one fd and contextload this session on another fd (or even from another process).


I hope your can parse what I wrote, feel free to ask for more details on any point.
I'll be more than happy to help concepting around these problems but atm unfortunately I'm unable to help with actual code ... for reasons...

Best regards,
Andreas





________________________________________
From: Jarkko Sakkinen [jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org]
Sent: Monday, January 02, 2017 14:22
To: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Cc: linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; open list
Subject: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

This patch set adds support for TPM spaces that provide a context
for isolating and swapping transient objects. This patch set does
not yet include support for isolating policy and HMAC sessions but
it is trivial to add once the basic approach is settled (and that's
why I created an RFC patch set).

There's a test script for trying out TPM spaces in

  git://git.infradead.org/users/jjs/tpm2-scripts.git

A simple smoke test can be run by

  sudo python -m unittest -v tpm2_smoke.SpaceTest

Jarkko Sakkinen (4):
  tpm: migrate struct tpm_buf to struct tpm_chip
  tpm: validate TPM 2.0 commands
  tpm: export tpm2_flush_context_cmd
  tpm: add the infrastructure for TPM space for TPM 2.0

 drivers/char/tpm/Makefile        |   2 +-
 drivers/char/tpm/tpm-chip.c      |  15 ++
 drivers/char/tpm/tpm-dev.c       |  80 ++++++++++-
 drivers/char/tpm/tpm-interface.c |  93 +++++++++----
 drivers/char/tpm/tpm-sysfs.c     |   2 +-
 drivers/char/tpm/tpm.h           | 106 ++++++++------
 drivers/char/tpm/tpm2-cmd.c      | 232 ++++++++++++++++---------------
 drivers/char/tpm/tpm2-space.c    | 288 +++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/tpm.h         |  23 ++++
 9 files changed, 662 insertions(+), 179 deletions(-)
 create mode 100644 drivers/char/tpm/tpm2-space.c
 create mode 100644 include/uapi/linux/tpm.h

--
2.9.3


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Wed, Jan 04, 2017 at 10:57:51AM -0800, James Bottomley wrote:

> > You are doing all this work to get the user space side in shape, I'd
> > like to see matching kernel support. To me that means out-of-the-box
> > a user can just use your plugins, the plugins will access /dev/tmps
> > and everything will work fine for RSA key storage.
> 
> Actually, not necessarily; you're not considering the setup issue:
> right at the moment users get delivered TPMs mostly in the cleared

I have no problem with users being instructed to do 'sudo
tpm2-provision' or having that happen via GUI using the usual
privilege escalation techniques.

> state (thankfully they no longer have to clear via bios).  So the first
> thing a new user has to do is set all the authorizations and create an
> SRK equivalent primary object at 0x81000001.  I think in the interests
> of best practice we want to make that as easy as possible; saying they
> have to do this as root and use a different device is problematic.

The device names should never be exposed to the user. The user should
specify a chip number (default to 0) and the tools should select the
correct available device to do what the user is asking.

First try /dev/tpms and elevate filter, then try /dev/tpmX, then fail.

> You can say they don't have to use a different device because the
> filter can be lifted for root, but then how do I lock down root apps
> for this untrusted root setup secure boot has going on?

Presumably the same way you lock down /dev/tpm0 today?

selinux I guess?

> I suppose we could use TPMA_PERMANENT for this. The first three bits
> indicate whether the authorizations are set, so if they're all clear,
> we can assume an unowned TPM and lift the filter?  A sort of trust on
> first use model.

I feel tpm provisioning is something that should only be done by the
system owner, and that means root in unix parlance.

I don't want random end-users provisioning the TPM in my server, for
instance.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Wed, 2017-01-04 at 11:31 -0700, Jason Gunthorpe wrote:
> On Wed, Jan 04, 2017 at 06:53:03AM -0800, James Bottomley wrote:
> 
> > > > But this is not trousers, this is an in-kernel 0666 char dev 
> > > > that will be active on basically every Linux system with a TPM. 
> > > > I think we have a duty to be very conservative here.
> > 
> > Just to note on this that trousers *is* effectively an 0666 kernel
> > device: all tcsd does is run with root privileges on the real 
> > /dev/tpm0 and mediate the calls.  It doesn't seem to police them at
> > all.
> 
> That may be, but IHMO trousers is simply not relevant. Real systems 
> do not seem to use trousers. I don't use it. Google doesn't use it. 
> You report it is crashy.
> 
> To me it just doesn't represent a reasonable way to use the TPM
> hardware.

It basically represents the only current way until there's a new API,
so all our current key handling tools use it.  Given how I slammed it
in Plumbers, I'd be the last one to defend its actual API as usable ...
we just don't have another (yet).

> > For localities, assuming they can have real meaning in terms of the
> > protection model, I think one device per locality is better than an
> > ioctl because device policy is settable in underspace via the UNIX 
> > ACL and hence locality policy is too.
> 
> Yes.
> 
> > I also think the command filter actually needs more thought.  Right 
> > at the moment, if we go with the current proposals, the kernel will
> > create two devices: /dev/tpm<n> and /dev/tpms<n>.  By default 
> > they'll both be root owned and 0600, so the current patch 
> > adequately protects the TPM.
> 
> Yes, but, considering the goals here I'd rather see the default 
> kernel permissions for tpms be 0666 ....
> 
> You are doing all this work to get the user space side in shape, I'd
> like to see matching kernel support. To me that means out-of-the-box
> a user can just use your plugins, the plugins will access /dev/tmps
> and everything will work fine for RSA key storage.

Actually, not necessarily; you're not considering the setup issue:
right at the moment users get delivered TPMs mostly in the cleared
state (thankfully they no longer have to clear via bios).  So the first
thing a new user has to do is set all the authorizations and create an
SRK equivalent primary object at 0x81000001.  I think in the interests
of best practice we want to make that as easy as possible; saying they
have to do this as root and use a different device is problematic.

You can say they don't have to use a different device because the
filter can be lifted for root, but then how do I lock down root apps
for this untrusted root setup secure boot has going on?

I suppose we could use TPMA_PERMANENT for this. The first three bits
indicate whether the authorizations are set, so if they're all clear,
we can assume an unowned TPM and lift the filter?  A sort of trust on
first use model.

James


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Wed, Jan 04, 2017 at 06:53:03AM -0800, James Bottomley wrote:

> > > But this is not trousers, this is an in-kernel 0666 char dev that 
> > > will be active on basically every Linux system with a TPM. I think 
> > > we have a duty to be very conservative here.
> 
> Just to note on this that trousers *is* effectively an 0666 kernel
> device: all tcsd does is run with root privileges on the real /dev/tpm0
> and mediate the calls.  It doesn't seem to police them at all.

That may be, but IHMO trousers is simply not relevant. Real systems do
not seem to use trousers. I don't use it. Google doesn't use it. You
report it is crashy.

To me it just doesn't represent a reasonable way to use the TPM
hardware.

> For localities, assuming they can have real meaning in terms of the
> protection model, I think one device per locality is better than an
> ioctl because device policy is settable in underspace via the UNIX ACL
> and hence locality policy is too.

Yes.

> I also think the command filter actually needs more thought.  Right at
> the moment, if we go with the current proposals, the kernel will create
> two devices: /dev/tpm<n> and /dev/tpms<n>.  By default they'll both be
> root owned and 0600, so the current patch adequately protects the TPM.

Yes, but, considering the goals here I'd rather see the default kernel
permissions for tpms be 0666 ....

You are doing all this work to get the user space side in shape, I'd
like to see matching kernel support. To me that means out-of-the-box
a user can just use your plugins, the plugins will access /dev/tmps
and everything will work fine for RSA key storage.

No messing with udev, no opt-in to TPM usage, no daemon to install,
no chmod on a dev node. It Just Works.

> Now if we look at use cases, for my laptop, where I'm the only user, I
> want unrestricted access  to the TPM.  I can achieve that by making
> /dev/tpms0 0666 (or changing its ownership to me).

This usecase is already handled by making /dev/tmp0 accessible to the
user. Keeping the 'enable RM' ioctl makes that a little wonky but
entirely workable..

> Jason's use case is devices running non-root apps that need restricted
> TPM access.  For them, a single filter on /dev/tpms0 might work,
> although there might be unrestricted apps needing a broader range of
> tpm access (perhaps not all running as root?)

Yes, I have a range of usage restrictions.

As an example: My systems support key migration, so I want to make it
very hard for an attacker to use the migration machinery to steal an
RSA key. The user controls the migration password, I hope it is
strong, but even so the system is currently desgined so that only a
ssh user can even issue migration commands to the tpm. Someone hacking
a network daemon simply cannot.

This is the sort of defence in depth I think is imporant in a security
system like this.

> For the cloud use case, we're going to have a variety of applications
> each with a variety of restrictions (for instance, the orchestration
> system is definitely going to need PCR extensions if it's doing
> attestations, but the guests might not want this) etc.

To me a design for how the PCRs actually need to work is what is
missing here. I only minimially understand this use case...

And it seems like a big leap that orchestration software *needs*
unprivileged TPM access.

> I think all this points to multiple potential users each with their own
> filter, so I think the actual architecture for the filter is an ioctl
> which adds a new filtered device connected to the RM which may be
> executed many times.

Maybe, but that also seems like over kill.. It entirely depends on
what the PCR use model actually is.

Here is an alternative starting idea:

- Introduce /dev/tpms a single cdev node that can talk to all chips
  and all localities.
- By default it is 0666
- By default it has a very strong filter allowing only key load,
  some key ops and any thing else we can identify as unambiguously safe.
- It has a root-only ioctl that can change the filter (op, chip)
- It has a root-only ioctl that can change the locality
- Keep the enable-RM ioctl on /dev/tmpX, except that enable-RM
  would switch the /dev/tpm0 FD to only use the above uAPI and
  set an all-permissive filter.

The followup would be a TPM namespace design that meets the needs of
people working on containers and related. We already know we need this
today for IMA in containers and vtpm isolation.

TPM namespaces would basically control the filtering options on
/dev/tmps and set the default TPM. So one could run orchestration
software unprivileged inside a TPM namespace with greater access.

This should be enough stuff for people to explore different security
models in user space.

The root-only ioctls and /dev/tpm0 are enough to let user space create
FDs with whatever properties are needed and pass them to unprivileged,
eg via fd passing or via open-as-root/drop privs techniques.

The default configuration is enough to enable the RSA key model that
we actually do understand well and almost have code for :) I think
this is very important..

We don't introduce any new security risks we don't understand.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Wed, Jan 04, 2017 at 02:58:10PM +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 03, 2017 at 02:54:45PM -0700, Jason Gunthorpe wrote:
> > On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote:
> > 
> > > OK, so I put a patch together that does this (see below). It all works
> > > nicely (with a udev script that sets the resource manager device to
> > > 0666):
> > > 
> > > jejb@jarvis:~> ls -l /dev/tpm*
> > > crw------- 1 root root  10,   224 Jan  2 20:54 /dev/tpm0
> > > crw-rw-rw- 1 root root 246, 65536 Jan  2 20:54 /dev/tpm0rm
> > > 
> > > I've modified the tss to connect to /dev/tpm0rm by default and it all
> > > seems to work.
> > > 
> > > The patch applies on top of your tabrm branch, by the way.
> > 
> > If we are making a new /dev/ node we should think more carefully about
> > the design.
> > 
> > - Do we need a cdev node for every chip? What about just '/dev/tpm' and
> >   we encode the chip number in the message. Since the exclusive
> >   locking is gone this is very doable.
> 
> What about backwards compatiblity? Or would this be just for /dev/tpms?
> We can consider this.

Yes, just for the new char dev.

> > - Should we get rid of the read/write protocol and use ioctl instead?
> >   As I understand it ioctl is more usable with seccomp and related
> >   schemes? I could see passing a TPM FD into a sandbox and wanting the
> >   sandbox only able to do do decrypt/encrypt operations, for instance.
> 
> Are you suggesting that command/response transaction would be handled
> by ioctl instead of read/write pair. Would make sense looking at how
> read/write is managed now (it is more or less of a hack because it
> actually is a transction).

Yes.

> > - Something to identify tpm chips and help match key data with the
> >   proper chip.
> 
> Hey, here's what I propose. I take some of the ideas (not all there
> have been so many) and bake a v2 of the RFC. Lets see where we are
> at then. I won't add any reviewed/tested-by's before we are in the
> same line with "big ideas" nor do I create a non-RFC patch set.

Usually with something like this there will be lots of dicussion
around the uapi portion - that is the portion we have to reatin
backwards compatability with forever - so there is a natural need to
make sure it is sane.

This is why I'm so cautious to limit what is possible because it is
easier to add new stuff then take stuff away.

So design your patch set to keep the uapi stuff as distinct and
well-described as possible - the other parts are much easier to review
and agree on.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Wed, 2017-01-04 at 14:50 +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 03, 2017 at 05:17:32PM -0700, Jason Gunthorpe wrote:
> > On Tue, Jan 03, 2017 at 02:39:58PM -0800, James Bottomley wrote:
[...]
> > > > Even if TPM 2 has a stronger password based model, I still
> > > > think the kernel should hard prevent those sorts of actions
> > > > even if the user knows the TPM password.
> > > 
> > > That would make us different from TPM1.2: there, if you know the 
> > > owner authorisation, trousers will pretty much let you do
> > > anything.
> > 
> > Well, I also think trousers is wrong to do that. :)
> > 
> > But this is not trousers, this is an in-kernel 0666 char dev that 
> > will be active on basically every Linux system with a TPM. I think 
> > we have a duty to be very conservative here.

Just to note on this that trousers *is* effectively an 0666 kernel
device: all tcsd does is run with root privileges on the real /dev/tpm0
and mediate the calls.  It doesn't seem to police them at all.

I realise you want better than this, and I definitely think this is a
worthy goal, but the point I want to make is that an 0666 device and
trousers are basically equivalent.

> > This is why I want to see a command white list in Jarkko's patches 
> > to start. Every command exposed needs a very careful security 
> > analysis first, and we should start with only the commands we know 
> > are safe :\
> > 
> > > > Realistically people in less senstive environments will want to 
> > > > use the well known TPM passwords and still have reasonable 
> > > > safety in their unprivileged accounts.
> > > 
> > > Can we not do most of this with localities?  In theory locality 0 
> > > is supposed to be only the bios and the boot manager and the OS 
> > > gets to access 1-3.  We could reserve one for the internal kernel 
> > > and still have a couple for userspace (I'll have to go back and 
> > > check numbers; I seem to remember there were odd restrictions on 
> > > which PCR you can reset and extend in which locality).  If we 
> > > have two devices (one for each locality) we could define a UNIX 
> > > ACL on the devices to achieve what you want.
> > 
> > Good point, yes, localities should be thought about when designing
> > this new RM char dev uAPI...
> > 
> > Our support for localities in the kernel today uses some really 
> > gross sysfs file and is basically insane, IMHO.
> > 
> > Maybe there should be a /dev/tpmrm for each locality? If so then 
> > only the safe one with unwritable localities can be 0666 by
> > default..
> 
> Do you see that it would be possible to have ioctl for setting the
> locality, or is it out of the question? I'm planning to have an ioctl
> for the whitelist anyway.

For localities, assuming they can have real meaning in terms of the
protection model, I think one device per locality is better than an
ioctl because device policy is settable in underspace via the UNIX ACL
and hence locality policy is too.  If we have an ioctl, we then have to
introduce a "who's allowed to do this?" policy in the kernel.

I also think the command filter actually needs more thought.  Right at
the moment, if we go with the current proposals, the kernel will create
two devices: /dev/tpm<n> and /dev/tpms<n>.  By default they'll both be
root owned and 0600, so the current patch adequately protects the TPM.

I think we go with this now and do the filter later.

On the filter design:

Now if we look at use cases, for my laptop, where I'm the only user, I
want unrestricted access  to the TPM.  I can achieve that by making
/dev/tpms0 0666 (or changing its ownership to me).

Jason's use case is devices running non-root apps that need restricted
TPM access.  For them, a single filter on /dev/tpms0 might work,
although there might be unrestricted apps needing a broader range of
tpm access (perhaps not all running as root?)

For the cloud use case, we're going to have a variety of applications
each with a variety of restrictions (for instance, the orchestration
system is definitely going to need PCR extensions if it's doing
attestations, but the guests might not want this) etc.

I think all this points to multiple potential users each with their own
filter, so I think the actual architecture for the filter is an ioctl
which adds a new filtered device connected to the RM which may be
executed many times.  That way the creator of the device can decide the
filter policy and the use policy via the standard device UNIX ACL and
you can have lots of them to make this fine grained.  It could also be
done with something /dev/ptmx like, so perhaps a filesystem may be the
answer as well?

If you want, I can commit to building this once we have all the
requirements and we can get Jarkko's patch set reviewed now without it.

James


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Tue, Jan 03, 2017 at 02:54:45PM -0700, Jason Gunthorpe wrote:
> On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote:
> 
> > OK, so I put a patch together that does this (see below). It all works
> > nicely (with a udev script that sets the resource manager device to
> > 0666):
> > 
> > jejb@jarvis:~> ls -l /dev/tpm*
> > crw------- 1 root root  10,   224 Jan  2 20:54 /dev/tpm0
> > crw-rw-rw- 1 root root 246, 65536 Jan  2 20:54 /dev/tpm0rm
> > 
> > I've modified the tss to connect to /dev/tpm0rm by default and it all
> > seems to work.
> > 
> > The patch applies on top of your tabrm branch, by the way.
> 
> If we are making a new /dev/ node we should think more carefully about
> the design.
> 
> - Do we need a cdev node for every chip? What about just '/dev/tpm' and
>   we encode the chip number in the message. Since the exclusive
>   locking is gone this is very doable.

What about backwards compatiblity? Or would this be just for /dev/tpms?
We can consider this.

> - Should we get rid of the read/write protocol and use ioctl instead?
>   As I understand it ioctl is more usable with seccomp and related
>   schemes? I could see passing a TPM FD into a sandbox and wanting the
>   sandbox only able to do do decrypt/encrypt operations, for instance.

Are you suggesting that command/response transaction would be handled
by ioctl instead of read/write pair. Would make sense looking at how
read/write is managed now (it is more or less of a hack because it
actually is a transction).

> - Something to identify tpm chips and help match key data with the
>   proper chip.

Hey, here's what I propose. I take some of the ideas (not all there
have been so many) and bake a v2 of the RFC. Lets see where we are
at then. I won't add any reviewed/tested-by's before we are in the
same line with "big ideas" nor do I create a non-RFC patch set.

> Jason

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Tue, Jan 03, 2017 at 05:17:32PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 03, 2017 at 02:39:58PM -0800, James Bottomley wrote:
> 
> > > I think we should also consider TPM 1.2 support in all of this, it is
> > > still a very popular peice of hardware and it is equally able to
> > > support a RM.
> > 
> > I've been running with the openssl and gnome-keyring patches in 1.2 for
> > months now.  The thing about 1.2 is that the volatile store is much
> > larger, so there's a lot less of a need for a RM.  It's only a
> > requirement in 2.0 because most shipping TPMs only seem to have room
> > for about 3 objects.
> 
> It would be great if the 1.2 RM could support just enough to allow RSA
> key operations from userspace, without key virtualization. That would
> allow the plugins that already exist to move to the RM interface and
> we can get rid of the hard dependency on trousers.
> 
> I honestly don't think this should be much work beyond what Jarkko has
> already done...
> 
> > > So, in general, I'd prefer to see the unprivileged char dev hard
> > > prevented by the kernel from doing certain things:
> > > 
> > > - Wipe the TPM
> > > - Manipulate the SRK, nvram, tpm flags, change passwords etc
> > > - Read back the EK
> > 
> > These are all things that the TPM itself is capable of enforcing a
> > policy for.  I think we should aim for correct setup of the TPM in the
> > first place so it enforces the policy in a standard manner rather than
> > having an artificial policy enforcement in the kernel.
> 
> Well, by policy you mean 'know the owner password' which at least I am
> *very* nervous about exposing beyond the super user - certainly in my
> embedded systems.
> 
> On a desktop I think these actions should be protected by the usual
> 'sudo' scheme dbus has *in addition* to the owner password.
> 
> It is rare that anyone would want to do these actions this seems like
> the right choice from a security perspective.
> 
> > > - Write to PCRs
> > 
> > The design of a TPM is mostly that it's up to user space to deal with
> > this.  Userspace can, of course, kill the TPM ability to quote and seal
> > to PCRs by inappropriately extending them.  However, there are a lot of
> > responsible applications that want to use PCRs in userspace; for
> > instance cloud boot and attestation.  We don't really want to restrict
> > their ability arbitrarily.
> 
> The entire RM model is that of a sandbox, so if extending the PCR is
> viewable by other RM clients it must be prevented. We don't want a
> user to be able to DOS other users by extending a PCR and breaking
> system attestation or unsealing.
> 
> Like you say below localities may be part of the answer here, and I
> also recall that various PCRs become read-only at certain localities.
> 
> However, until we figure out a security model for writing PCRs I think
> the RM has to ban them.
> 
> > > Even if TPM 2 has a stronger password based model, I still think the
> > > kernel should hard prevent those sorts of actions even if the user
> > > knows the TPM password.
> > 
> > That would make us different from TPM1.2: there, if you know the owner
> > authorisation, trousers will pretty much let you do anything.
> 
> Well, I also think trousers is wrong to do that. :)
> 
> But this is not trousers, this is an in-kernel 0666 char dev that will
> be active on basically every Linux system with a TPM. I think we have
> a duty to be very conservative here.
> 
> This is why I want to see a command white list in Jarkko's patches to
> start. Every command exposed needs a very careful security analysis
> first, and we should start with only the commands we know are safe :\
> 
> > > Realistically people in less senstive environments will want to use
> > > the well known TPM passwords and still have reasonable safety in 
> > > their unprivileged accounts.
> > 
> > Can we not do most of this with localities?  In theory locality 0 is
> > supposed to be only the bios and the boot manager and the OS gets to
> > access 1-3.  We could reserve one for the internal kernel and still
> > have a couple for userspace (I'll have to go back and check numbers; I
> > seem to remember there were odd restrictions on which PCR you can reset
> > and extend in which locality).  If we have two devices (one for each
> > locality) we could define a UNIX ACL on the devices to achieve what you
> > want.
> 
> Good point, yes, localities should be thought about when designing
> this new RM char dev uAPI...
> 
> Our support for localities in the kernel today uses some really gross
> sysfs file and is basically insane, IMHO.
> 
> Maybe there should be a /dev/tpmrm for each locality? If so then only
> the safe one with unwritable localities can be 0666 by default..

Do you see that it would be possible to have ioctl for setting the
locality, or is it out of the question? I'm planning to have an ioctl
for the whitelist anyway.

> Jason

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Tue, Jan 03, 2017 at 02:47:02PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 03, 2017 at 08:36:10AM -0800, James Bottomley wrote:
> 
> > > I'm not sure about this. Why you couldn't have a very thin daemon 
> > > that prepares the file descriptor and sends it through UDS socket to 
> > > a client.
> > 
> > So I'm a bit soured on daemons from the trousers experience: tcsd
> > crashed regularly and when it did it took all the TPM connections down
> > irrecoverably.  I'm not saying we can't write a stateless daemon to fix
> > most of the trousers issues, but I think it's valuable first to ask the
> > question, "can we manage without a daemon at all?"  I actually think
> > the answer is "yes", so I'm interested in seeing how far that line of
> > research gets us.
> 
> There is clearly no need for a daemon to be involved when working on
> simple tasks like key load and key sign/enc/dec actions, adding such a
> thing only increases the complexity.
> 
> If we discover a reason to have a daemon down the road then it should
> work in some way where the user space can call out to the daemon over
> a different path than the kernel. (eg dbus or something)
> 
> > Do you have a link to the presentation?  The Plumbers etherpad doesn't
> > contain it.  I've been trying to work out whether a properly set up TPM
> > actually does need any protections at all.  As far as I can tell, once
> > you've set all the hierarchy authorities and the lockout one, you're
> > pretty well protected.
> 
> I think we should also consider TPM 1.2 support in all of this, it is
> still a very popular peice of hardware and it is equally able to
> support a RM.

I'm not against considering TPM 1.2 support but getting both in the
same patch set would be too much.

> 
> So, in general, I'd prefer to see the unprivileged char dev hard
> prevented by the kernel from doing certain things:
> 
> - Wipe the TPM
> - Manipulate the SRK, nvram, tpm flags, change passwords etc
> - Read back the EK
> - Write to PCRs
> - etc.

I rather have an ioctl where you can supply a list of CCs that you
want to allow a client to do.

/Jarkko

> Even if TPM 2 has a stronger password based model, I still think the
> kernel should hard prevent those sorts of actions even if the user
> knows the TPM password.
> 
> Realistically people in less senstive environments will want to use
> the well known TPM passwords and still have reasonable safety in their
> unprivileged accounts.
> 
> Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Tue, Jan 03, 2017 at 04:29:59PM -0800, James Bottomley wrote:
> On Tue, 2017-01-03 at 17:17 -0700, Jason Gunthorpe wrote:
> > On Tue, Jan 03, 2017 at 02:39:58PM -0800, James Bottomley wrote:
> > 
> > > > I think we should also consider TPM 1.2 support in all of this, 
> > > > it is still a very popular peice of hardware and it is equally 
> > > > able to support a RM.
> > > 
> > > I've been running with the openssl and gnome-keyring patches in 1.2 
> > > for months now.  The thing about 1.2 is that the volatile store is 
> > > much larger, so there's a lot less of a need for a RM.  It's only a
> > > requirement in 2.0 because most shipping TPMs only seem to have 
> > > room for about 3 objects.
> > 
> > It would be great if the 1.2 RM could support just enough to allow 
> > RSA key operations from userspace, without key virtualization. That 
> > would allow the plugins that already exist to move to the RM 
> > interface and we can get rid of the hard dependency on trousers.
> [getting long, let's divide into separate issues]
> 
> They actually already do: Trousers, for all its annoying complexity,
> doesn't actually implement a resource manager, so we should be able to
> do all the RSA operations we want today with the current 1.2 interface
> and no RM.

The current interface cannot be used by unprivileged users. I want to
see the kernel provide an unprivileged safe interface for both TPM 1.2
and TPM 2.0

> The difficulty is no API ... unless you want to speak at
> the TPM command level and do all the HMAC calculations yourself.

I think the openssl RSA method could certainly do the TPM command
level with not really a big problem.

That would avoid all these crazy dependencies and debate :|

I have a very good idea what that would look like for tpm 1.2 and I
would estimate < 500 lines....

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Tue, 2017-01-03 at 17:17 -0700, Jason Gunthorpe wrote:
> On Tue, Jan 03, 2017 at 02:39:58PM -0800, James Bottomley wrote:
> 
> > > I think we should also consider TPM 1.2 support in all of this, 
> > > it is still a very popular peice of hardware and it is equally 
> > > able to support a RM.
> > 
> > I've been running with the openssl and gnome-keyring patches in 1.2 
> > for months now.  The thing about 1.2 is that the volatile store is 
> > much larger, so there's a lot less of a need for a RM.  It's only a
> > requirement in 2.0 because most shipping TPMs only seem to have 
> > room for about 3 objects.
> 
> It would be great if the 1.2 RM could support just enough to allow 
> RSA key operations from userspace, without key virtualization. That 
> would allow the plugins that already exist to move to the RM 
> interface and we can get rid of the hard dependency on trousers.
[getting long, let's divide into separate issues]

They actually already do: Trousers, for all its annoying complexity,
doesn't actually implement a resource manager, so we should be able to
do all the RSA operations we want today with the current 1.2 interface
and no RM.  The difficulty is no API ... unless you want to speak at
the TPM command level and do all the HMAC calculations yourself.

James


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Tue, Jan 03, 2017 at 05:21:28PM -0500, Ken Goldman wrote:
> On 1/3/2017 4:47 PM, Jason Gunthorpe wrote:
> >
> > I think we should also consider TPM 1.2 support in all of this, it is
> > still a very popular piece of hardware and it is equally able to
> > support a RM.
> 
> I suspect that TPM 2.0 and TPM 1.2 are so different that there may be 
> little or no code in common.

Sure, but the uapi should make sense for both versions, ie, I don't want
to see a tpm 2.0 specific char dev.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Tue, 2017-01-03 at 14:47 -0700, Jason Gunthorpe wrote:
> On Tue, Jan 03, 2017 at 08:36:10AM -0800, James Bottomley wrote:
> 
> > > I'm not sure about this. Why you couldn't have a very thin daemon
> > > that prepares the file descriptor and sends it through UDS socket 
> > > to a client.
> > 
> > So I'm a bit soured on daemons from the trousers experience: tcsd
> > crashed regularly and when it did it took all the TPM connections 
> > down irrecoverably.  I'm not saying we can't write a stateless 
> > daemon to fix most of the trousers issues, but I think it's 
> > valuable first to ask the question, "can we manage without a daemon 
> > at all?"  I actually think the answer is "yes", so I'm interested 
> > in seeing how far that line of research gets us.
> 
> There is clearly no need for a daemon to be involved when working on
> simple tasks like key load and key sign/enc/dec actions, adding such 
> a thing only increases the complexity.
> 
> If we discover a reason to have a daemon down the road then it should
> work in some way where the user space can call out to the daemon over
> a different path than the kernel. (eg dbus or something)

Agreed ... I think the only reason I can currently see for needing a
daemon is if we need it to sort out access security (which I'm hoping
we don't).

> > Do you have a link to the presentation?  The Plumbers etherpad 
> > doesn't contain it.  I've been trying to work out whether a 
> > properly set up TPM actually does need any protections at all.  As 
> > far as I can tell, once you've set all the hierarchy authorities 
> > and the lockout one, you're pretty well protected.
> 
> I think we should also consider TPM 1.2 support in all of this, it is
> still a very popular peice of hardware and it is equally able to
> support a RM.

I've been running with the openssl and gnome-keyring patches in 1.2 for
months now.  The thing about 1.2 is that the volatile store is much
larger, so there's a lot less of a need for a RM.  It's only a
requirement in 2.0 because most shipping TPMs only seem to have room
for about 3 objects.

> So, in general, I'd prefer to see the unprivileged char dev hard
> prevented by the kernel from doing certain things:
> 
> - Wipe the TPM
> - Manipulate the SRK, nvram, tpm flags, change passwords etc
> - Read back the EK

These are all things that the TPM itself is capable of enforcing a
policy for.  I think we should aim for correct setup of the TPM in the
first place so it enforces the policy in a standard manner rather than
having an artificial policy enforcement in the kernel.

> - Write to PCRs

The design of a TPM is mostly that it's up to user space to deal with
this.  Userspace can, of course, kill the TPM ability to quote and seal
to PCRs by inappropriately extending them.  However, there are a lot of
responsible applications that want to use PCRs in userspace; for
instance cloud boot and attestation.  We don't really want to restrict
their ability arbitrarily.

> - etc.

> 
> Even if TPM 2 has a stronger password based model, I still think the
> kernel should hard prevent those sorts of actions even if the user
> knows the TPM password.

That would make us different from TPM1.2: there, if you know the owner
authorisation, trousers will pretty much let you do anything.

> Realistically people in less senstive environments will want to use
> the well known TPM passwords and still have reasonable safety in 
> their unprivileged accounts.

Can we not do most of this with localities?  In theory locality 0 is
supposed to be only the bios and the boot manager and the OS gets to
access 1-3.  We could reserve one for the internal kernel and still
have a couple for userspace (I'll have to go back and check numbers; I
seem to remember there were odd restrictions on which PCR you can reset
and extend in which locality).  If we have two devices (one for each
locality) we could define a UNIX ACL on the devices to achieve what you
want.

James


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Ken Goldman]

On 1/3/2017 4:47 PM, Jason Gunthorpe wrote:
>
> I think we should also consider TPM 1.2 support in all of this, it is
> still a very popular peice of hardware and it is equally able to
> support a RM.

I suspect that TPM 2.0 is different enough from 1.2 that there may be 
little common code.

My immediate need is for 2.0, since 1.2 does have tcsd.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Ken Goldman]

On 1/3/2017 4:47 PM, Jason Gunthorpe wrote:
>
> I think we should also consider TPM 1.2 support in all of this, it is
> still a very popular piece of hardware and it is equally able to
> support a RM.

I suspect that TPM 2.0 and TPM 1.2 are so different that there may be 
little or no code in common.

My immediate need is for a 2.0 resource manager, since it's a gap in the 
technology, while 1.2 does have tcsd.




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Ken Goldman]

On 1/3/2017 11:36 AM, James Bottomley wrote:
> To be honest I can't see much use for getting the transient handles
> and all the other handles you'd be interested in aren't virtualized.

Probably the biggest use case for enumerating handles is NV indexes,
where one is looking for EK certificates or the templates used to create 
EK's.

Another is likely to be enumerating persistent objects, followed by a 
readpublic to see if a storage key with the correct algorithm exists.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote:

> OK, so I put a patch together that does this (see below). It all works
> nicely (with a udev script that sets the resource manager device to
> 0666):
> 
> jejb@jarvis:~> ls -l /dev/tpm*
> crw------- 1 root root  10,   224 Jan  2 20:54 /dev/tpm0
> crw-rw-rw- 1 root root 246, 65536 Jan  2 20:54 /dev/tpm0rm
> 
> I've modified the tss to connect to /dev/tpm0rm by default and it all
> seems to work.
> 
> The patch applies on top of your tabrm branch, by the way.

If we are making a new /dev/ node we should think more carefully about
the design.

- Do we need a cdev node for every chip? What about just '/dev/tpm' and
  we encode the chip number in the message. Since the exclusive
  locking is gone this is very doable.
- Should we get rid of the read/write protocol and use ioctl instead?
  As I understand it ioctl is more usable with seccomp and related
  schemes? I could see passing a TPM FD into a sandbox and wanting the
  sandbox only able to do do decrypt/encrypt operations, for instance.
- Something to identify tpm chips and help match key data with the
  proper chip.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jason Gunthorpe]

On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote:
> On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > This patch set adds support for TPM spaces that provide a context
> > for isolating and swapping transient objects. This patch set does
> > not yet include support for isolating policy and HMAC sessions but
> > it is trivial to add once the basic approach is settled (and that's
> > why I created an RFC patch set).
> 
> The approach looks fine to me.  The only basic query I have is about
> the default: shouldn't it be with resource manager on rather than off? 
>  I can't really think of a use case that wants the RM off (even if
> you're running your own, having another doesn't hurt anything, and it's
> still required to share with in-kernel uses).

I haven't looked too closely at TPM 2.0 stuff, but at least for 1.2 we
should have a kernel white-list of allowed commands within a RM
context, so having the RM on by default would break all of the user
space.

I really think the only way forward here is a new char dev that is
safe for unprivileged/concurrent use and migrate the user space stack
to use it instead.

> And with that, I've TPM 2 enabled both gnome-keyring and openssl:
> 
> https://build.opensuse.org/package/show/home:jejb1:Tumbleweed/gnome-keyring
> https://build.opensuse.org/package/show/home:jejb1:Tumbleweed/openssl_tpm_engine
 
> I'm running them in production on my day to day laptop and so far
> everything's working nicely (better than 1.2, in fact, since tcsd
> periodically crashes necessitating a restart of everything).

You granted your unprivileged user access to /dev/tpm0 then? FYI I
think that is a dangerous idea..

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Tue, 2017-01-03 at 21:14 +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 03, 2017 at 08:36:02PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Jan 03, 2017 at 08:14:55AM -0800, James Bottomley wrote:
> > > On Tue, 2017-01-03 at 15:41 +0200, Jarkko Sakkinen wrote:
[...]
> > > > Just thinking how to split up the non-RFC patch set. This was 
> > > > also what Jason suggested if I understood his remark correctly.
> > > 
> > > SUre ... let's get agreement on how we move forward first.  How 
> > > the patch is activated by the user has to be sorted out as well
> > > before it can go in, but it doesn't have to be the first thing we 
> > > do.  I'm happy to continue playing with the interfaces to see 
> > > what works and what doesn't.  My main current feedback is that I 
> > > think separate devices works way better than an ioctl becuase the 
> > > separate devices approach allows differing system policies for 
> > > who accesses the RM backed TPM vs who accesses the raw one.
> > 
> > I think I see your point. I would rather name the device as tpms0 
> > but otherwise I think we could do it in the way you suggest...

I'm not at all wedded to the name tpm0rm, so tpms0 is fine by me.

> I think one more stronger argument for tpms0 is that it keeps tpm0
> intact. Those who don't care about tpms0 don't have to worry about it
> causing regressions. Also it makes it cleaner to put the whole 
> feature under a compilation flag, which would make to me because that 
> gives distributions a choice to not enable in-kernel RM when it first 
> hits the mainline.

I wouldn't go that far: one of the evils we cause for distros is too
many compile options.  In this case, I can't think of a good reason to
have an option to disable this now the feature is segregated on to a
separate device.  If we get a regression, only users of the new device
will notice.  If it's a compile option, this is the same if the distro
enables it and if it's disabled, no user can test out the feature (and
distros eventually get complaints about it not working).

James



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Tue, Jan 03, 2017 at 08:36:02PM +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 03, 2017 at 08:14:55AM -0800, James Bottomley wrote:
> > On Tue, 2017-01-03 at 15:41 +0200, Jarkko Sakkinen wrote:
> > > On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote:
> > > > On Mon, 2017-01-02 at 13:40 -0800, James Bottomley wrote:
> > > > > On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote:
> > > > > > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley
> > > > > > wrote:
> > > > > > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > > > > > > > This patch set adds support for TPM spaces that provide a 
> > > > > > > > context for isolating and swapping transient objects. This 
> > > > > > > > patch set does not yet include support for isolating policy 
> > > > > > > > and HMAC sessions but it is trivial to add once the basic
> > > > > > > > approach is settled (and that's why I created an RFC patch
> > > > > > > > set).
> > > > > > > 
> > > > > > > The approach looks fine to me.  The only basic query I have 
> > > > > > > is about the default: shouldn't it be with resource manager 
> > > > > > > on rather than off?  I can't really think of a use case that
> > > > > > > wants the RM off (even if you're running your own, having 
> > > > > > > another doesn't hurt anything, and it's still required to 
> > > > > > > share with in-kernel uses).
> > > > > > 
> > > > > > This is a valid question and here's a longish explanation.
> > > > > > 
> > > > > > In TPM2_GetCapability and maybe couple of other commands you 
> > > > > > can get handles in the response body. I do not want to have 
> > > > > > special cases in the kernel for response bodies because there 
> > > > > > is no a generic way to do the substitution. What's worse, new 
> > > > > > commands in the standard future revisions could have such 
> > > > > > commands requiring special cases. In addition, vendor specific 
> > > > > > commans could have handles in the response bodies.
> > > > > 
> > > > > OK, in general I buy this ... what you're effectively saying is 
> > > > > that we need a non-RM interface for certain management type
> > > > > commands.
> > > > > 
> > > > > However, let me expand a bit on why I'm fretting about the non-RM 
> > > > > use case.  Right at the moment, we have a single TPM device which 
> > > > > you use for access to the kernel TPM.  The current tss2 just 
> > > > > makes direct use of this, meaning it has to have 0666 
> > > > > permissions.  This means that any local user can simply DoS the 
> > > > > TPM by running us out of transient resources if they don't 
> > > > > activate the RM.  If they get a connection always via the RM, 
> > > > > this isn't a worry.  Perhaps the best way of fixing this is to 
> > > > > expose two separate device nodes: one raw to the TPM which we 
> > > > > could keep at 0600 and one with an always RM connection
> > > > > which we can set to 0666.  That would mean that access to the non
> > > > > -RM connection is either root only or governed by a system set
> > > > > ACL.
> > > > 
> > > > OK, so I put a patch together that does this (see below). It all 
> > > > works nicely (with a udev script that sets the resource manager 
> > > > device to 0666):
> > > 
> > > This is not yet a comment about this suggestion but I guess one thing
> > > is clear: the stuff in tpm2-space.c and tpm-interface.c changes are 
> > > the thing that we can mostly agree on and the area of argumentation 
> > > is the user space interface to it?
> > 
> > Agreed.  As I've already said, the space and interface code is working
> > well for me in production on my laptop.
> > 
> > > Just thinking how to split up the non-RFC patch set. This was also 
> > > what Jason suggested if I understood his remark correctly.
> > 
> > SUre ... let's get agreement on how we move forward first.  How the
> > patch is activated by the user has to be sorted out as well before it
> > can go in, but it doesn't have to be the first thing we do.  I'm happy
> > to continue playing with the interfaces to see what works and what
> > doesn't.  My main current feedback is that I think separate devices
> > works way better than an ioctl becuase the separate devices approach
> > allows differing system policies for who accesses the RM backed TPM vs
> > who accesses the raw one.
> 
> I think I see your point. I would rather name the device as tpms0 but
> otherwise I think we could do it in the way you suggest...

I think one more stronger argument for tpms0 is that it keeps tpm0
intact. Those who don't care about tpms0 don't have to worry about it
causing regressions. Also it makes it cleaner to put the whole feature
under a compilation flag, which would make to me because that gives
distributions a choice to not enable in-kernel RM when it first hits the
mainline.

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Tue, Jan 03, 2017 at 08:14:55AM -0800, James Bottomley wrote:
> On Tue, 2017-01-03 at 15:41 +0200, Jarkko Sakkinen wrote:
> > On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote:
> > > On Mon, 2017-01-02 at 13:40 -0800, James Bottomley wrote:
> > > > On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote:
> > > > > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley
> > > > > wrote:
> > > > > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > > > > > > This patch set adds support for TPM spaces that provide a 
> > > > > > > context for isolating and swapping transient objects. This 
> > > > > > > patch set does not yet include support for isolating policy 
> > > > > > > and HMAC sessions but it is trivial to add once the basic
> > > > > > > approach is settled (and that's why I created an RFC patch
> > > > > > > set).
> > > > > > 
> > > > > > The approach looks fine to me.  The only basic query I have 
> > > > > > is about the default: shouldn't it be with resource manager 
> > > > > > on rather than off?  I can't really think of a use case that
> > > > > > wants the RM off (even if you're running your own, having 
> > > > > > another doesn't hurt anything, and it's still required to 
> > > > > > share with in-kernel uses).
> > > > > 
> > > > > This is a valid question and here's a longish explanation.
> > > > > 
> > > > > In TPM2_GetCapability and maybe couple of other commands you 
> > > > > can get handles in the response body. I do not want to have 
> > > > > special cases in the kernel for response bodies because there 
> > > > > is no a generic way to do the substitution. What's worse, new 
> > > > > commands in the standard future revisions could have such 
> > > > > commands requiring special cases. In addition, vendor specific 
> > > > > commans could have handles in the response bodies.
> > > > 
> > > > OK, in general I buy this ... what you're effectively saying is 
> > > > that we need a non-RM interface for certain management type
> > > > commands.
> > > > 
> > > > However, let me expand a bit on why I'm fretting about the non-RM 
> > > > use case.  Right at the moment, we have a single TPM device which 
> > > > you use for access to the kernel TPM.  The current tss2 just 
> > > > makes direct use of this, meaning it has to have 0666 
> > > > permissions.  This means that any local user can simply DoS the 
> > > > TPM by running us out of transient resources if they don't 
> > > > activate the RM.  If they get a connection always via the RM, 
> > > > this isn't a worry.  Perhaps the best way of fixing this is to 
> > > > expose two separate device nodes: one raw to the TPM which we 
> > > > could keep at 0600 and one with an always RM connection
> > > > which we can set to 0666.  That would mean that access to the non
> > > > -RM connection is either root only or governed by a system set
> > > > ACL.
> > > 
> > > OK, so I put a patch together that does this (see below). It all 
> > > works nicely (with a udev script that sets the resource manager 
> > > device to 0666):
> > 
> > This is not yet a comment about this suggestion but I guess one thing
> > is clear: the stuff in tpm2-space.c and tpm-interface.c changes are 
> > the thing that we can mostly agree on and the area of argumentation 
> > is the user space interface to it?
> 
> Agreed.  As I've already said, the space and interface code is working
> well for me in production on my laptop.
> 
> > Just thinking how to split up the non-RFC patch set. This was also 
> > what Jason suggested if I understood his remark correctly.
> 
> SUre ... let's get agreement on how we move forward first.  How the
> patch is activated by the user has to be sorted out as well before it
> can go in, but it doesn't have to be the first thing we do.  I'm happy
> to continue playing with the interfaces to see what works and what
> doesn't.  My main current feedback is that I think separate devices
> works way better than an ioctl becuase the separate devices approach
> allows differing system policies for who accesses the RM backed TPM vs
> who accesses the raw one.

I think I see your point. I would rather name the device as tpms0 but
otherwise I think we could do it in the way you suggest...

> James

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Tue, 2017-01-03 at 15:51 +0200, Jarkko Sakkinen wrote:
> On Mon, Jan 02, 2017 at 01:40:48PM -0800, James Bottomley wrote:
> > On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote:
> > > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote:
> > > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > > > > This patch set adds support for TPM spaces that provide a 
> > > > > context for isolating and swapping transient objects. This 
> > > > > patch set does not yet include support for isolating policy 
> > > > > and HMAC sessions but it is trivial to add once the basic 
> > > > > approach is settled (and that's why I created an RFC patch
> > > > > set).
> > > > 
> > > > The approach looks fine to me.  The only basic query I have is 
> > > > about the default: shouldn't it be with resource manager on 
> > > > rather than off?  I can't really think of a use case that wants 
> > > > the RM off (even if you're running your own, having another 
> > > > doesn't hurt anything, and it's still required to share with in
> > > > -kernel uses).
> > > 
> > > This is a valid question and here's a longish explanation.
> > > 
> > > In TPM2_GetCapability and maybe couple of other commands you can 
> > > get handles in the response body. I do not want to have special 
> > > cases in the kernel for response bodies because there is no a 
> > > generic way to do the substitution. What's worse, new commands in 
> > > the standard future revisions could have such commands requiring 
> > > special cases. In addition, vendor specific commans could have 
> > > handles in the response bodies.
> > 
> > OK, in general I buy this ... what you're effectively saying is 
> > that we need a non-RM interface for certain management type
> > commands.
> 
> Not only that.
> 
> Doing virtualization for commands like GetCapability is just a better
> fit for doing in the user space. You could have a thin translation 
> layer in your TSS library for example to handle these specific
> messages.

Yes, we could do it that way too.  To be honest I can't see much use
for getting the transient handles and all the other handles you'd be
interested in aren't virtualized.

> > However, let me expand a bit on why I'm fretting about the non-RM 
> > use case.  Right at the moment, we have a single TPM device which 
> > you use for access to the kernel TPM.  The current tss2 just makes 
> > direct use of this, meaning it has to have 0666 permissions.  This 
> > means that any local user can simply DoS the TPM by running us out 
> > of transient resources if they don't activate the RM.  If they get 
> > a connection always via the RM, this isn't a worry.  Perhaps the 
> > best way of fixing this is to expose two separate device nodes: one 
> > raw to the TPM which we could keep at 0600 and one with an always 
> > RM connection which we can set to 0666.  That would mean that 
> > access to the non-RM connection is either root only or governed by
> > a system set ACL.
> 
> I'm not sure about this. Why you couldn't have a very thin daemon 
> that prepares the file descriptor and sends it through UDS socket to 
> a client.

So I'm a bit soured on daemons from the trousers experience: tcsd
crashed regularly and when it did it took all the TPM connections down
irrecoverably.  I'm not saying we can't write a stateless daemon to fix
most of the trousers issues, but I think it's valuable first to ask the
question, "can we manage without a daemon at all?"  I actually think
the answer is "yes", so I'm interested in seeing how far that line of
research gets us.

>   The non-RFC version will also have whitelisting ioctl for
> further restricting the file descriptor to only specific TPM
> commands.
> 
> This is also architecture I preseted in my LSS presentation and I 
> think it makes sense especially when I add the whitelisting to the
> pack.

Do you have a link to the presentation?  The Plumbers etherpad doesn't
contain it.  I've been trying to work out whether a properly set up TPM
actually does need any protections at all.  As far as I can tell, once
you've set all the hierarchy authorities and the lockout one, you're
pretty well protected.

> > James
> 
> I'm more dilated to keep things way they are now. I'll stick to that 
> at least with the first non-RFC version and hopefully get the tpm2
> -space.c part reviewed as I split that stuff to a separate commit.

Sure, we need the patch in an acceptable form first.  I'll keep
worrying about the systems implications, but I can layer playing with
those on top of what you do.

James



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Tue, 2017-01-03 at 15:41 +0200, Jarkko Sakkinen wrote:
> On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote:
> > On Mon, 2017-01-02 at 13:40 -0800, James Bottomley wrote:
> > > On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote:
> > > > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley
> > > > wrote:
> > > > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > > > > > This patch set adds support for TPM spaces that provide a 
> > > > > > context for isolating and swapping transient objects. This 
> > > > > > patch set does not yet include support for isolating policy 
> > > > > > and HMAC sessions but it is trivial to add once the basic
> > > > > > approach is settled (and that's why I created an RFC patch
> > > > > > set).
> > > > > 
> > > > > The approach looks fine to me.  The only basic query I have 
> > > > > is about the default: shouldn't it be with resource manager 
> > > > > on rather than off?  I can't really think of a use case that
> > > > > wants the RM off (even if you're running your own, having 
> > > > > another doesn't hurt anything, and it's still required to 
> > > > > share with in-kernel uses).
> > > > 
> > > > This is a valid question and here's a longish explanation.
> > > > 
> > > > In TPM2_GetCapability and maybe couple of other commands you 
> > > > can get handles in the response body. I do not want to have 
> > > > special cases in the kernel for response bodies because there 
> > > > is no a generic way to do the substitution. What's worse, new 
> > > > commands in the standard future revisions could have such 
> > > > commands requiring special cases. In addition, vendor specific 
> > > > commans could have handles in the response bodies.
> > > 
> > > OK, in general I buy this ... what you're effectively saying is 
> > > that we need a non-RM interface for certain management type
> > > commands.
> > > 
> > > However, let me expand a bit on why I'm fretting about the non-RM 
> > > use case.  Right at the moment, we have a single TPM device which 
> > > you use for access to the kernel TPM.  The current tss2 just 
> > > makes direct use of this, meaning it has to have 0666 
> > > permissions.  This means that any local user can simply DoS the 
> > > TPM by running us out of transient resources if they don't 
> > > activate the RM.  If they get a connection always via the RM, 
> > > this isn't a worry.  Perhaps the best way of fixing this is to 
> > > expose two separate device nodes: one raw to the TPM which we 
> > > could keep at 0600 and one with an always RM connection
> > > which we can set to 0666.  That would mean that access to the non
> > > -RM connection is either root only or governed by a system set
> > > ACL.
> > 
> > OK, so I put a patch together that does this (see below). It all 
> > works nicely (with a udev script that sets the resource manager 
> > device to 0666):
> 
> This is not yet a comment about this suggestion but I guess one thing
> is clear: the stuff in tpm2-space.c and tpm-interface.c changes are 
> the thing that we can mostly agree on and the area of argumentation 
> is the user space interface to it?

Agreed.  As I've already said, the space and interface code is working
well for me in production on my laptop.

> Just thinking how to split up the non-RFC patch set. This was also 
> what Jason suggested if I understood his remark correctly.

SUre ... let's get agreement on how we move forward first.  How the
patch is activated by the user has to be sorted out as well before it
can go in, but it doesn't have to be the first thing we do.  I'm happy
to continue playing with the interfaces to see what works and what
doesn't.  My main current feedback is that I think separate devices
works way better than an ioctl becuase the separate devices approach
allows differing system policies for who accesses the RM backed TPM vs
who accesses the raw one.

James


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Mon, Jan 02, 2017 at 01:40:48PM -0800, James Bottomley wrote:
> On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote:
> > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote:
> > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > > > This patch set adds support for TPM spaces that provide a context
> > > > for isolating and swapping transient objects. This patch set does
> > > > not yet include support for isolating policy and HMAC sessions 
> > > > but it is trivial to add once the basic approach is settled (and
> > > > that's why I created an RFC patch set).
> > > 
> > > The approach looks fine to me.  The only basic query I have is 
> > > about the default: shouldn't it be with resource manager on rather 
> > > than off?  I can't really think of a use case that wants the RM off 
> > > (even if you're running your own, having another doesn't hurt 
> > > anything, and it's still required to share with in-kernel uses).
> > 
> > This is a valid question and here's a longish explanation.
> > 
> > In TPM2_GetCapability and maybe couple of other commands you can get
> > handles in the response body. I do not want to have special cases in 
> > the kernel for response bodies because there is no a generic way to 
> > do the substitution. What's worse, new commands in the standard 
> > future revisions could have such commands requiring special cases. In
> > addition, vendor specific commans could have handles in the response
> > bodies.
> 
> OK, in general I buy this ... what you're effectively saying is that we
> need a non-RM interface for certain management type commands.

Not only that.

Doing virtualization for commands like GetCapability is just a better
fit for doing in the user space. You could have a thin translation layer
in your TSS library for example to handle these specific messages.

> However, let me expand a bit on why I'm fretting about the non-RM use
> case.  Right at the moment, we have a single TPM device which you use
> for access to the kernel TPM.  The current tss2 just makes direct use
> of this, meaning it has to have 0666 permissions.  This means that any
> local user can simply DoS the TPM by running us out of transient
> resources if they don't activate the RM.  If they get a connection
> always via the RM, this isn't a worry.  Perhaps the best way of fixing
> this is to expose two separate device nodes: one raw to the TPM which
> we could keep at 0600 and one with an always RM connection which we can
> set to 0666.  That would mean that access to the non-RM connection is
> either root only or governed by a system set ACL.

I'm not sure about this. Why you couldn't have a very thin daemon that
prepares the file descriptor and sends it through UDS socket to a
client.  The non-RFC version will also have whitelisting ioctl for
further restricting the file descriptor to only specific TPM commands.

This is also architecture I preseted in my LSS presentation and I think
it makes sense especially when I add the whitelisting to the pack.

> James

I'm more dilated to keep things way they are now. I'll stick to that at
least with the first non-RFC version and hopefully get the tpm2-space.c
part reviewed as I split that stuff to a separate commit.

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote:
> On Mon, 2017-01-02 at 13:40 -0800, James Bottomley wrote:
> > On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote:
> > > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote:
> > > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > > > > This patch set adds support for TPM spaces that provide a 
> > > > > context for isolating and swapping transient objects. This 
> > > > > patch set does not yet include support for isolating policy and 
> > > > > HMAC sessions but it is trivial to add once the basic approach 
> > > > > is settled (and that's why I created an RFC patch set).
> > > > 
> > > > The approach looks fine to me.  The only basic query I have is 
> > > > about the default: shouldn't it be with resource manager on 
> > > > rather than off?  I can't really think of a use case that wants 
> > > > the RM off (even if you're running your own, having another 
> > > > doesn't hurt anything, and it's still required to share with in
> > > > -kernel uses).
> > > 
> > > This is a valid question and here's a longish explanation.
> > > 
> > > In TPM2_GetCapability and maybe couple of other commands you can 
> > > get handles in the response body. I do not want to have special 
> > > cases in the kernel for response bodies because there is no a 
> > > generic way to do the substitution. What's worse, new commands in 
> > > the standard future revisions could have such commands requiring 
> > > special cases. In addition, vendor specific commans could have 
> > > handles in the response bodies.
> > 
> > OK, in general I buy this ... what you're effectively saying is that 
> > we need a non-RM interface for certain management type commands.
> > 
> > However, let me expand a bit on why I'm fretting about the non-RM use
> > case.  Right at the moment, we have a single TPM device which you use
> > for access to the kernel TPM.  The current tss2 just makes direct use
> > of this, meaning it has to have 0666 permissions.  This means that 
> > any local user can simply DoS the TPM by running us out of transient
> > resources if they don't activate the RM.  If they get a connection
> > always via the RM, this isn't a worry.  Perhaps the best way of 
> > fixing this is to expose two separate device nodes: one raw to the 
> > TPM which we could keep at 0600 and one with an always RM connection 
> > which we can set to 0666.  That would mean that access to the non-RM 
> > connection is either root only or governed by a system set ACL.
> 
> OK, so I put a patch together that does this (see below). It all works
> nicely (with a udev script that sets the resource manager device to
> 0666):

This is not yet a comment about this suggestion but I guess one thing
is clear: the stuff in tpm2-space.c and tpm-interface.c changes are the
thing that we can mostly agree on and the area of argumentation is the
user space interface to it?

Just thinking how to split up the non-RFC patch set. This was also what
Jason suggested if I understood his remark correctly.

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[James Bottomley]

On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote:
> On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote:
> > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > > This patch set adds support for TPM spaces that provide a context
> > > for isolating and swapping transient objects. This patch set does
> > > not yet include support for isolating policy and HMAC sessions 
> > > but it is trivial to add once the basic approach is settled (and
> > > that's why I created an RFC patch set).
> > 
> > The approach looks fine to me.  The only basic query I have is 
> > about the default: shouldn't it be with resource manager on rather 
> > than off?  I can't really think of a use case that wants the RM off 
> > (even if you're running your own, having another doesn't hurt 
> > anything, and it's still required to share with in-kernel uses).
> 
> This is a valid question and here's a longish explanation.
> 
> In TPM2_GetCapability and maybe couple of other commands you can get
> handles in the response body. I do not want to have special cases in 
> the kernel for response bodies because there is no a generic way to 
> do the substitution. What's worse, new commands in the standard 
> future revisions could have such commands requiring special cases. In
> addition, vendor specific commans could have handles in the response
> bodies.

OK, in general I buy this ... what you're effectively saying is that we
need a non-RM interface for certain management type commands.

However, let me expand a bit on why I'm fretting about the non-RM use
case.  Right at the moment, we have a single TPM device which you use
for access to the kernel TPM.  The current tss2 just makes direct use
of this, meaning it has to have 0666 permissions.  This means that any
local user can simply DoS the TPM by running us out of transient
resources if they don't activate the RM.  If they get a connection
always via the RM, this isn't a worry.  Perhaps the best way of fixing
this is to expose two separate device nodes: one raw to the TPM which
we could keep at 0600 and one with an always RM connection which we can
set to 0666.  That would mean that access to the non-RM connection is
either root only or governed by a system set ACL.

James


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley wrote:
> On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote:
> > This patch set adds support for TPM spaces that provide a context
> > for isolating and swapping transient objects. This patch set does
> > not yet include support for isolating policy and HMAC sessions but
> > it is trivial to add once the basic approach is settled (and that's
> > why I created an RFC patch set).
> 
> The approach looks fine to me.  The only basic query I have is about
> the default: shouldn't it be with resource manager on rather than off? 
>  I can't really think of a use case that wants the RM off (even if
> you're running your own, having another doesn't hurt anything, and it's
> still required to share with in-kernel uses).

This is a valid question and here's a longish explanation.

In TPM2_GetCapability and maybe couple of other commands you can get
handles in the response body. I do not want to have special cases in the
kernel for response bodies because there is no a generic way to do the
substitution. What's worse, new commands in the standard future
revisions could have such commands requiring special cases. In addition,
vendor specific commans could have handles in the response bodies.

It's better to leverage that to the user space. I would do only simple
and fail-safe stuff in the kernel.

Turning RM on by default would raise a backwards compatibility issue.

> 
> > There's a test script for trying out TPM spaces in
> > 
> >   git://git.infradead.org/users/jjs/tpm2-scripts.git
> > 
> > A simple smoke test can be run by
> > 
> >   sudo python -m unittest -v tpm2_smoke.SpaceTest   
> 
> I've also added an enabling patch to the tss
> 
> https://build.opensuse.org/package/view_file/home:jejb1:Tumbleweed/tss2/0002-tssProperties-add-TPM_USE_RESOURCE_MANAGER.patch?expand=1
> 
> And with that, I've TPM 2 enabled both gnome-keyring and openssl:
> 
> https://build.opensuse.org/package/show/home:jejb1:Tumbleweed/gnome-keyring
> https://build.opensuse.org/package/show/home:jejb1:Tumbleweed/openssl_tpm_engine
> 
> I'm running them in production on my day to day laptop and so far
> everything's working nicely (better than 1.2, in fact, since tcsd
> periodically crashes necessitating a restart of everything).

Great, thanks for doing this!

> So you can definitely add my Tested-By.

Thank you.

> James

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

This patch set adds support for TPM spaces that provide a context
for isolating and swapping transient objects. This patch set does
not yet include support for isolating policy and HMAC sessions but
it is trivial to add once the basic approach is settled (and that's
why I created an RFC patch set).

There's a test script for trying out TPM spaces in

  git://git.infradead.org/users/jjs/tpm2-scripts.git

A simple smoke test can be run by

  sudo python -m unittest -v tpm2_smoke.SpaceTest   

Jarkko Sakkinen (4):
  tpm: migrate struct tpm_buf to struct tpm_chip
  tpm: validate TPM 2.0 commands
  tpm: export tpm2_flush_context_cmd
  tpm: add the infrastructure for TPM space for TPM 2.0

 drivers/char/tpm/Makefile        |   2 +-
 drivers/char/tpm/tpm-chip.c      |  15 ++
 drivers/char/tpm/tpm-dev.c       |  80 ++++++++++-
 drivers/char/tpm/tpm-interface.c |  93 +++++++++----
 drivers/char/tpm/tpm-sysfs.c     |   2 +-
 drivers/char/tpm/tpm.h           | 106 ++++++++------
 drivers/char/tpm/tpm2-cmd.c      | 232 ++++++++++++++++---------------
 drivers/char/tpm/tpm2-space.c    | 288 +++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/tpm.h         |  23 ++++
 9 files changed, 662 insertions(+), 179 deletions(-)
 create mode 100644 drivers/char/tpm/tpm2-space.c
 create mode 100644 include/uapi/linux/tpm.h

-- 
2.9.3

[PATCH RFC 0/4] RFC: in-kernel resource manager

[Jarkko Sakkinen]

This patch set adds support for TPM spaces that provide a context
for isolating and swapping transient objects. This patch set does
not yet include support for isolating policy and HMAC sessions but
it is trivial to add once the basic approach is settled (and that's
why I created an RFC patch set).

There's a test script for trying out TPM spaces in

  git://git.infradead.org/users/jjs/tpm2-scripts.git

A simple smoke test can be run by

  sudo python -m unittest -v tpm2_smoke.SpaceTest   

Jarkko Sakkinen (4):
  tpm: migrate struct tpm_buf to struct tpm_chip
  tpm: validate TPM 2.0 commands
  tpm: export tpm2_flush_context_cmd
  tpm: add the infrastructure for TPM space for TPM 2.0

 drivers/char/tpm/Makefile        |   2 +-
 drivers/char/tpm/tpm-chip.c      |  15 ++
 drivers/char/tpm/tpm-dev.c       |  80 ++++++++++-
 drivers/char/tpm/tpm-interface.c |  93 +++++++++----
 drivers/char/tpm/tpm-sysfs.c     |   2 +-
 drivers/char/tpm/tpm.h           | 106 ++++++++------
 drivers/char/tpm/tpm2-cmd.c      | 232 ++++++++++++++++---------------
 drivers/char/tpm/tpm2-space.c    | 288 +++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/tpm.h         |  23 ++++
 9 files changed, 662 insertions(+), 179 deletions(-)
 create mode 100644 drivers/char/tpm/tpm2-space.c
 create mode 100644 include/uapi/linux/tpm.h

-- 
2.9.3