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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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,
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,
Am 09.01.2017 um 23:39 schrieb Jarkko Sakkinen:
On Thu, Jan 05, 2017 at 03:52:02PM +, Fuchs, Andreas wrote:
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
Am 09.01.2017 um 23:39 schrieb Jarkko Sakkinen:
On Thu, Jan 05, 2017 at 03:52:02PM +, Fuchs, Andreas wrote:
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
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
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
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
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
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
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
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
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
On Thu, Jan 05, 2017 at 03:52:02PM +, Fuchs, Andreas wrote:
> 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
On Thu, Jan 05, 2017 at 03:52:02PM +, Fuchs, Andreas wrote:
> 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
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
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
On Thu, Jan 05, 2017 at 04:36:42PM -0800, James Bottomley wrote:
> I'm seriously pissed of with trousers and will port the trousers based
> TPM1.2 RSA key patches I've done to whatever direct connect API you
> come up with (just send me a link to the git tree or package or
> whatever), so this
On Thu, Jan 05, 2017 at 04:36:42PM -0800, James Bottomley wrote:
> I'm seriously pissed of with trousers and will port the trousers based
> TPM1.2 RSA key patches I've done to whatever direct connect API you
> come up with (just send me a link to the git tree or package or
> whatever), so this
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:
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:
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 +, 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
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 +, 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
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
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
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
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
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
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
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
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
On Thu, 2017-01-05 at 12:20 -0700, Jason Gunthorpe wrote:
> 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
On Thu, 2017-01-05 at 12:20 -0700, Jason Gunthorpe wrote:
> 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
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
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
On Thu, 2017-01-05 at 10:27 -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 03:52:02PM +, Fuchs, Andreas wrote:
[...]
> > - 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
On Thu, 2017-01-05 at 10:27 -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 03:52:02PM +, Fuchs, Andreas wrote:
[...]
> > - 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
On Thu, 2017-01-05 at 10:27 -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 03:52:02PM +, 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
On Thu, 2017-01-05 at 10:27 -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 03:52:02PM +, 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
On Thu, Jan 05, 2017 at 03:52:02PM +, 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
On Thu, Jan 05, 2017 at 03:52:02PM +, 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
... for reasons...
Best regards,
Andreas
From: Jarkko Sakkinen [jarkko.sakki...@linux.intel.com]
Sent: Monday, January 02, 2017 14:22
To: tpmdd-de...@lists.sourceforge.net
Cc: linux-security-mod...@vger.kernel.org; open list
Subject: [tpmdd-devel] [PA
... for reasons...
Best regards,
Andreas
From: Jarkko Sakkinen [jarkko.sakki...@linux.intel.com]
Sent: Monday, January 02, 2017 14:22
To: tpmdd-de...@lists.sourceforge.net
Cc: linux-security-mod...@vger.kernel.org; open list
Subject: [tpmdd-devel] [PA
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
On Tue, Jan 03, 2017 at 09:47:21PM -0800, Andy Lutomirski wrote:
> On 01/02/2017 09:26 PM, 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
On Tue, Jan 03, 2017 at 09:47:21PM -0800, Andy Lutomirski wrote:
> On 01/02/2017 09:26 PM, 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
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):
> >
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):
> >
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
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
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
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
On 01/02/2017 09:26 PM, 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
On 01/02/2017 09:26 PM, 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
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
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
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
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
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.
>
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.
>
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
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
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
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
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.
> >
>
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.
> >
>
On Tue, 2017-01-03 at 14:32 -0700, Jason Gunthorpe 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
On Tue, 2017-01-03 at 14:32 -0700, Jason Gunthorpe 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
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
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
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
>
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
>
1 - 100 of 124 matches
Mail list logo
