On Thu, Feb 16, 2017 at 09:04:47AM -0500, Ken Goldman wrote:
Good morning to everyone, leveraging some time between planes.
> On 2/14/2017 9:38 AM, Dr. Greg Wettstein wrote:
> >
> >I don't think there is any doubt that running cryptographic primitives
> >in userspace is going to be faster then go
On Fri, Feb 17, 2017 at 02:37:12PM +0200, Jarkko Sakkinen wrote:
Hi, I hope the week is ending well for everyone.
> On Fri, Feb 17, 2017 at 03:56:26AM -0600, Dr. Greg Wettstein wrote:
> > On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote:
> >
> > Good morning to everyone.
> >
> >
On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote:
Good morning to everyone.
> On Thu, Feb 16, 2017 at 02:06:42PM -0600, Dr. Greg Wettstein wrote:
> > Just as an aside, has anyone given any thought about TPM2 resource
> > management in things like TXT/tboot environments? The curren
On Fri, Feb 17, 2017 at 03:56:26AM -0600, Dr. Greg Wettstein wrote:
> On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote:
>
> Good morning to everyone.
>
> > On Thu, Feb 16, 2017 at 02:06:42PM -0600, Dr. Greg Wettstein wrote:
> > > Just as an aside, has anyone given any thought about
On Thu, Feb 16, 2017 at 02:06:42PM -0600, Dr. Greg Wettstein wrote:
> Just as an aside, has anyone given any thought about TPM2 resource
> management in things like TXT/tboot environments? The current tboot
> code makes a rather naive assumption that it can take a handle slot to
> protect its plat
On Fri, Feb 10, 2017 at 04:13:05PM -0500, Kenneth Goldman wrote:
Good morning to everyone.
> James Bottomley wrote on
> 02/10/2017 11:46:03 AM:
>
> > > quote: 810 milliseconds
> > > verify signature: 635 milliseconds
For those who may be interested in this sort of thing I grabbed a few
minute
On Tue, 2017-02-14 at 08:38 -0600, Dr. Greg Wettstein wrote:
> On Fri, Feb 10, 2017 at 04:13:05PM -0500, Kenneth Goldman wrote:
>
> Good morning to everyone.
>
> > James Bottomley wrote on
> > 02/10/2017 11:46:03 AM:
> >
> > > > quote: 810 milliseconds
> > > > verify signature: 635 millisecond
On 2/10/2017 11:46 AM, James Bottomley wrote:
> On Fri, 2017-02-10 at 04:03 -0600, Dr. Greg Wettstein wrote:
>> On Feb 9, 11:24am, James Bottomley wrote:
>> quote: 810 milliseconds
>> verify signature: 635 milliseconds
> ...
>
> Part of the way of reducing the latency is not to use the TPM for
> t
On Thu, Feb 09, 2017 at 12:04:26PM -0700, Jason Gunthorpe wrote:
Jarkko Sakkinen wrote on 02/10/2017
03:48:37 AM:
> > This series should focus on allowing a user space RM to co-exist with
> > the in-kernel services - lets try and tackle the idea of a
> > policy-restricted or unpriv-safe cdev when
> > quote: 810 milliseconds
> > verify signature: 635 milliseconds
>
> Part of the way of reducing the latency is not to use the TPM for
> things that don't require secrecy:
Agreed. There are a few times one would verify a signature inside the
TPM,
but they're far from mainstream:
1 - Early i
James Bottomley wrote on
02/10/2017 11:46:03 AM:
> > quote: 810 milliseconds
> > verify signature: 635 milliseconds
>
> Part of the way of reducing the latency is not to use the TPM for
> things that don't require secrecy:
Agreed. There are a few times one would verify a signature inside the
> > It does. My trusted keys implementation actually uses sessions.
>
> But as I read the code, I can't find where the kernel creates a
> session. It looks like the session and hmac are passed in as option
> arguments, aren't they?
A bit of background.
In TPM 1.2, any authorization needed a sess
setting In
-Reply-To: headers like this
In-reply-to: James Bottomley "Re:
[tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion"
(Feb 9, 11:24am)
Not using the message id breaks threading for everyone.
> > On Thu, 2017-02-09 at 03:06 -0600, Dr. Greg Wettstein
On Feb 9, 11:24am, James Bottomley wrote:
} Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global sessi
Good morning to everyone.
> On Thu, 2017-02-09 at 03:06 -0600, Dr. Greg Wettstein wrote:
> > Referring back to Ken's comments about having 20+ clients waiting to
> > get access t
On Thu, Feb 09, 2017 at 12:04:26PM -0700, Jason Gunthorpe wrote:
> On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote:
> > > userspace instance with subsequent relinquishment of privilege. At
> > > that point one has the freedom to implement all sorts of policy.
> >
> > If you look a
On Thu, Feb 09, 2017 at 11:29:51AM -0800, James Bottomley wrote:
> On Thu, 2017-02-09 at 12:04 -0700, Jason Gunthorpe wrote:
> > On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote:
> > > The current patch set does not define policy. The simple policy
> > > addition that could be added
On Thu, 2017-02-09 at 03:06 -0600, Dr. Greg Wettstein wrote:
> On Jan 30, 11:58pm, Jarkko Sakkinen wrote:
> } Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for
> global sessi
>
> Good morning, I hope the day is going well for everyone.
>
> > I'm kind dilating to an opinion that we wou
On Thu, 2017-02-09 at 12:04 -0700, Jason Gunthorpe wrote:
> On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote:
> > The current patch set does not define policy. The simple policy
> > addition that could be added soon is the limit of connections
> > because it is easy to implement in n
On Thu, 2017-02-09 at 03:06 -0600, Dr. Greg Wettstein wrote:
> Referring back to Ken's comments about having 20+ clients waiting to
> get access to the hardware. Even with the focus in TPM2 on having it
> be more of a cryptographic accelerator are we convinced that the
> hardware is ever going to
On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote:
> > userspace instance with subsequent relinquishment of privilege. At
> > that point one has the freedom to implement all sorts of policy.
>
> If you look at the patch set that I sent yesterday it exactly has a
> feature that makes
On Thu, Feb 09, 2017 at 03:06:38AM -0600, Dr. Greg Wettstein wrote:
> On Jan 30, 11:58pm, Jarkko Sakkinen wrote:
> } Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global sessi
>
> Good morning, I hope the day is going well for everyone.
>
> > I'm kind dilating to an opinion that w
On Jan 30, 11:58pm, Jarkko Sakkinen wrote:
} Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global sessi
Good morning, I hope the day is going well for everyone.
> I'm kind dilating to an opinion that we would leave this commit out
> from the first kernel release that will contain
On Tue, 2017-01-31 at 14:28 -0500, Ken Goldman wrote:
> On 1/30/2017 11:04 AM, James Bottomley wrote:
> >
> > This depends what your threat model is. For ssh keys, you worry
> > that someone might be watching, so you use HMAC authority even for
> > a local TPM.
>
> If someone can "watch" my loc
On 1/30/2017 11:04 AM, James Bottomley wrote:
>
> This depends what your threat model is. For ssh keys, you worry
> that someone might be watching, so you use HMAC authority even for a
> local TPM.
If someone can "watch" my local process, they can capture my password
anyway. Does using a passwo
On Mon, Jan 30, 2017 at 02:13:08PM -0800, James Bottomley wrote:
> On Mon, 2017-01-30 at 23:58 +0200, Jarkko Sakkinen wrote:
> > On Mon, Jan 30, 2017 at 08:04:55AM -0800, James Bottomley wrote:
> > > On Sun, 2017-01-29 at 19:52 -0500, Ken Goldman wrote:
> > > > On 1/27/2017 5:04 PM, James Bottomley
On 1/30/2017 5:13 PM, James Bottomley wrote:
>
> But as I read the code, I can't find where the kernel creates a
> session. It looks like the session and hmac are passed in as option
> arguments, aren't they?
A bit of background.
Unlike TPM 1.2, which always required an HMAC, TPM 2.0 has plainte
On Mon, 2017-01-30 at 23:58 +0200, Jarkko Sakkinen wrote:
> On Mon, Jan 30, 2017 at 08:04:55AM -0800, James Bottomley wrote:
> > On Sun, 2017-01-29 at 19:52 -0500, Ken Goldman wrote:
> > > On 1/27/2017 5:04 PM, James Bottomley wrote:
> > >
> > > > > Beware the nasty corner case:
> > > > >
> > > >
On Mon, Jan 30, 2017 at 08:04:55AM -0800, James Bottomley wrote:
> On Sun, 2017-01-29 at 19:52 -0500, Ken Goldman wrote:
> > On 1/27/2017 5:04 PM, James Bottomley wrote:
> >
> > > > Beware the nasty corner case:
> > > >
> > > > - Application asks for a session and gets 0200
> > > >
> > > > -
On Sun, 2017-01-29 at 19:52 -0500, Ken Goldman wrote:
> On 1/27/2017 5:04 PM, James Bottomley wrote:
>
> > > Beware the nasty corner case:
> > >
> > > - Application asks for a session and gets 0200
> > >
> > > - Time elapses and 0200 gets forcibly flushed
> > >
> > > - Later, app comes
On 1/27/2017 5:04 PM, James Bottomley wrote:
>> Beware the nasty corner case:
>>
>> - Application asks for a session and gets 0200
>>
>> - Time elapses and 0200 gets forcibly flushed
>>
>> - Later, app comes back, asks for a second session and again gets
>> 0200.
>>
>> - App gets very
On Fri, 2017-01-27 at 16:35 -0700, Jason Gunthorpe wrote:
> On Fri, Jan 27, 2017 at 02:04:59PM -0800, James Bottomley wrote:
>
> > if I look at the code I've written, I don't know what the session
> > number is, I just save sessionHandle in a variable for later use
> > (lets say to v1). If I got
On Fri, Jan 27, 2017 at 02:04:59PM -0800, James Bottomley wrote:
> if I look at the code I've written, I don't know what the session
> number is, I just save sessionHandle in a variable for later use (lets
> say to v1). If I got the same session number returned at a later time
> and placed it in
On Fri, 2017-01-27 at 16:42 -0500, Ken Goldman wrote:
> On 1/18/2017 3:48 PM, James Bottomley wrote:
> > In a TPM2, sessions can be globally exhausted once there are
> > TPM_PT_ACTIVE_SESSION_MAX of them (even if they're all context
> > saved).
> > The Strategy for handling this is to keep a global
On Fri, 2017-01-27 at 16:20 -0500, Ken Goldman wrote:
> On 1/19/2017 7:41 AM, Jarkko Sakkinen wrote:
> >
> > I actually think that the very best solution would be such that
> > sessions would be *always* lease based. So when you create a
> > session you would always loose within a time limit.
> >
On 1/18/2017 3:48 PM, James Bottomley wrote:
> In a TPM2, sessions can be globally exhausted once there are
> TPM_PT_ACTIVE_SESSION_MAX of them (even if they're all context saved).
> The Strategy for handling this is to keep a global count of all the
> sessions along with their creation time. Then
On 1/19/2017 7:41 AM, Jarkko Sakkinen wrote:
>
> I actually think that the very best solution would be such that
> sessions would be *always* lease based. So when you create a
> session you would always loose within a time limit.
>
> There would not be any special victim selection mechanism. You
>
On Thu, Jan 19, 2017 at 07:59:04AM -0500, James Bottomley wrote:
> On Thu, 2017-01-19 at 14:25 +0200, Jarkko Sakkinen wrote:
> > On Wed, Jan 18, 2017 at 03:48:09PM -0500, James Bottomley wrote:
> > > In a TPM2, sessions can be globally exhausted once there are
> > > TPM_PT_ACTIVE_SESSION_MAX of the
On Thu, 2017-01-19 at 14:25 +0200, Jarkko Sakkinen wrote:
> On Wed, Jan 18, 2017 at 03:48:09PM -0500, James Bottomley wrote:
> > In a TPM2, sessions can be globally exhausted once there are
> > TPM_PT_ACTIVE_SESSION_MAX of them (even if they're all context
> > saved).
> > The Strategy for handling
On Thu, Jan 19, 2017 at 02:25:33PM +0200, Jarkko Sakkinen wrote:
> On Wed, Jan 18, 2017 at 03:48:09PM -0500, James Bottomley wrote:
> > In a TPM2, sessions can be globally exhausted once there are
> > TPM_PT_ACTIVE_SESSION_MAX of them (even if they're all context saved).
> > The Strategy for handli
On Wed, Jan 18, 2017 at 03:48:09PM -0500, James Bottomley wrote:
> In a TPM2, sessions can be globally exhausted once there are
> TPM_PT_ACTIVE_SESSION_MAX of them (even if they're all context saved).
> The Strategy for handling this is to keep a global count of all the
> sessions along with their
40 matches
Mail list logo
