Re: [PATCH v15 0/5] TPM 2.0 trusted key rework

[Jarkko Sakkinen <jarkko@kernel.org>]

On Fri, Feb 19, 2021 at 10:35:00AM -0800, James Bottomley wrote:
> On Fri, 2021-02-19 at 20:24 +0200, Jarkko Sakkinen wrote:
> > On Wed, Jan 27, 2021 at 11:06:12AM -0800, James Bottomley wrote:
> > > v15: fix 0day sign issue and add reviews and testeds
> > > 
> > > General cover letter minus policy bit:
> > > 
> > > This patch updates the trusted key code to export keys in the ASN.1
> > > format used by current TPM key tools (openssl_tpm2_engine and
> > > openconnect).  The current code will try to load keys containing
> > > policy, but being unable to formulate the policy commands necessary
> > > to
> > > load them, the unseal will always fail unless the policy is
> > > executed
> > > in user space and a pre-formed policy session passed in.
> > > 
> > > The key format is designed to be compatible with our two openssl
> > > engine implementations as well as with the format used by
> > > openconnect.
> > > I've added seal/unseal to my engine so I can use it for
> > > interoperability testing and I'll later use this for sealed
> > > symmetric
> > > keys via engine:
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/
> > > 
> > > James
> > > 
> > > ---
> > > 
> > > James Bottomley (5):
> > >   lib: add ASN.1 encoder
> > >   oid_registry: Add TCG defined OIDS for TPM keys
> > >   security: keys: trusted: fix TPM2 authorizations
> > >   security: keys: trusted: use ASN.1 TPM2 key format for the blobs
> > >   security: keys: trusted: Make sealed key properly interoperable
> > 
> > This is online again in the master branch. 
> > 
> > I've mangled the commits as follows:
> > 
> > 1. Fixed my emails to jarkko@kernel.org.
> > 2. Adjusted the Makefile, i.e. separate lines for each entry.
> > 3. Fixed the checkpatch issues.
> > 
> > I guess we could potentially re-consider this to rc2 pull? With all
> > the mangling required, did not make sense to include this to the
> > first pull.
> 
> The way I usually do this in SCSI, because stuff always happens
> immediately before the merge window that causes some pull material to
> be held over, is an early push, which you've done followed by a late
> push on the Friday before the merge window closes of the rest of the
> stuff.  This is an example from the last but one merge window:
> 
> https://lore.kernel.org/linux-scsi/fdee2336d2a7eada3749e07c3cc6ea682f8200b3.camel@HansenPartnership.com/
> https://lore.kernel.org/linux-scsi/4affd2a9c347e5f1231485483bf852737ea08151.camel@HansenPartnership.com/
> 
> Linus seems to be happy with this pattern as long as it's well
> explained.
> 
> James

OK, thanks, I'll keep this in mind.

/Jarkko