linux-kernel - Re: [tpmdd-devel] [PATCH 1/2] tpm2: add session handle isolation to tpm spaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 19 Jan 2017 07:11:23 -0500
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     tpmdd-devel@...ts.sourceforge.net,
        linux-security-module@...r.kernel.org,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH 1/2] tpm2: add session handle isolation to
 tpm spaces

On Thu, 2017-01-19 at 13:58 +0200, Jarkko Sakkinen wrote:
> On Wed, Jan 18, 2017 at 10:09:46AM -0500, James Bottomley wrote:
> > sessions should be isolated during each instance of a tpm space. 
> >  This means that spaces shouldn't be able to see each other's 
> > sessions and also when a space is closed, all the sessions 
> > belonging to it should be flushed.
> > 
> > This is implemented by adding a session_tbl to the space to track 
> > the created session handles.  Sessions can be flushed either by not
> > setting the continueSession attribute in the session table or by an
> > explicit flush.  In the first case we have to mark the session as
> > being ready to flush and explicitly forget it if the command 
> > completes successfully and in the second case we have to intercept 
> > the flush instruction and clear the session from our table.
> 
> You could do this without these nasty corner cases by arbage 
> collecting when a command emits a new session handle.

I could for this patch set.  However, the global session accounting RFC
requires strict accounting, because it needs to know exactly when to
retry a command that failed because we were out of sessions and because
we don't want to needlessly evict a session if there was one available
which we didn't see because of lazy accounting.  It would be a lot of
churn to do it lazily in this patch set and then switch to strict in
that one, so I chose to account sessions strictly always.

> When a session handle is created check if any of the spaces contain 
> it and remove from the array. No special cases needed.
> 
> This will render the need to do any kind of interception whatsoever
> unneeded.

It can be done either way for these two patches, but I think, for the
reason above, it should begin life as it will go on (i.e. strict
accounting).  It's not that much extra code to do it and it's easier to
follow the flow of the three patches.

James