linux-kernel - RE: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

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:	Mon, 5 Oct 2015 14:13:15 +0000
From:	"Fuchs, Andreas" <andreas.fuchs@....fraunhofer.de>
To:	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
CC:	"tpmdd-devel@...ts.sourceforge.net" 
	<tpmdd-devel@...ts.sourceforge.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"open list:KEYS-TRUSTED" <linux-security-module@...r.kernel.org>,
	"open list:KEYS-TRUSTED" <keyrings@...r.kernel.org>,
	James Morris <james.l.morris@...cle.com>,
	"David Safford" <safford@...ibm.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	"josh@...htripplet.org" <josh@...htripplet.org>,
	"richard.l.maliszewski@...el.com" <richard.l.maliszewski@...el.com>,
	"monty.wiseman@...el.com" <monty.wiseman@...el.com>,
	"will.c.arthur@...el.com" <will.c.arthur@...el.com>
Subject: RE: [tpmdd-devel] [PATCH 4/4] keys,	trusted: seal/unseal with TPM
 2.0 chips

> > I was just pointing out, that the proposed patch will not fit in with
> > the current approach in TSS2.0, before this user-facing kernel API is
> > set in stone and _corrected_ new syscalls need to be added later.
> 
> Why you would want new system calls? Do you know how hard it is to get
> new system calls accepted? It's usually nearly impossible to get new
> system calls in. You are going wrong direction there.
> 
> I do not see why couldn't survive in TSS 2.0 implementation for a while
> without in-kernel access broker even if the world isn't perfect and
> improve from that when the support becomes available. I'm not frankly
> following your rationale here.
> 
> On the other hand I see use for the kernel images without access broker
> in small embdedded devices.
> 
> I CC'd to Will Arthur as he has been working with TSS 2.0 for along
> time just in case.
> 
> > Also, the pseudo-code proposal should be a proper minimal access broker
> > that should solve most accesses to TPM transient objects down the road.
> > Session-brokering is a different beast of course.
> 
> I don't mean to be rude but pseudo code doesn't matter much. We know
> what is required from an access broker in terms of TPM 2.0 commands and
> locking. Only working code matters at this point.
> 
> I still don't see why you couldn't add access broker later on. The patch
> set does not make the API worse than it is right now.

OK, I guess we got stuck in the follow-up discussions and missed the points. 

My 1st point is:

TPM1.2's 0x40000000 SRK handle was a well-known, singleton, always-present
key, that could be relied upon.

TPM2.0's 0x80000000 is a temporary, TPM-assigned, context-specific handle,
that cannot be relied upon.

Therefore, I think your patch should not use it.

Instead, I'd recommend using the closest equivalent to an SRK that TPM2.0
has to offer, which is within the range 0x81000000 to 0x8100FFFF.
(see http://www.trustedcomputinggroup.org/resources/registry_of_reserved_tpm_20_handles_and_localities)
You might want to use TPM2_GetCapability() to find the correct one.

Also User-Space could reference any of these handles in the 
0x81000000-0x81FFFFFF range. This would be fine.

My 2nd point is:

It is IMHO a bad idea to allow user-space to provide transient handles as
parameter to the TPM, because TSS2.0 will virtualize handles and /dev/tpm0
is single-access only.
Instead I'd recommend passing context-saved-blobs to the kernel.

Then you brought up the valid point that this requires kernel-space resource
broker and I provided some sketch-idea in pseudo-code for discussion of
general approach. I did not know that the access broker was solved already.

Conclusion

I would just like to prevent having an API that expects (and defaults to)
transient handles be set in stone for the kernel, since it will not meet
reality... ;-)

@Will: Hope you're doing fine... Maybe we can discuss the TSS-side of things
tomorrow...

Cheers,
Andreas--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/