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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 17 Feb 2017 03:56:26 -0600 From: "Dr. Greg Wettstein" <greg@...ellic.com> To: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com> Cc: "Dr. Greg Wettstein" <greg@...ellic.com>, Ken Goldman <kgold@...ux.vnet.ibm.com>, linux-kernel@...r.kernel.org, tpmdd-devel@...ts.sourceforge.net Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion 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 current tboot > > code makes a rather naive assumption that it can take a handle slot to > > protect its platform verification secret. Doing resource management > > correctly will require addressing extra-OS environments such as this > > which may have TPM2 state requirement issues. > The current implementation handles stuff created from regular > /dev/tpm0 so I do not think this would be an issue. You can only > access objects from a TPM space that are created within that space. Unless I misunderstand the number of transient objects which can be managed is a characteristic of the hardware and is a limited resource, hence our discussion on the notion of a resource manager to shuttle context in and out of these limited slots. On a Kabylake system, running the following command: getcapability -cap 6 | grep trans After booting into a TXT mediated measured launch environment (MLE) yields the following: TPM_PT 0000010e value 00000003 TPM_PT_HR_TRANSIENT_MIN - the minimum number of transient objects that can be held in TPM RAM TPM_PT 00000207 value 00000002 TPM_PT_HR_TRANSIENT_AVAIL - estimate of the number of additional transient objects that could be loaded into TPM RAM Booting without TXT results in the getcapability call indicating that three slots are available. Based on that and reading the tboot code, we are assuming the occupied slot is the ephemeral primary key generated by tboot which seals the verification secret. In an MLE it is possible to create and then flush a new ephemeral primary key which results in the following getcapability output: TPM_PT 00000207 value 00000003 TPM_PT_HR_TRANSIENT_AVAIL - estimate of the number of additional transient objects that could be loaded into TPM RAM Which is probably going to be pretty surprising to tboot in the event that it tries to re-verify the system state after a suspend event. So based on that it would seem there would need to be some semblance of cooperation between the resource manager and an extra-OS utilization of TPM2 resources such as tboot. Thoughts? > /Jarkko Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@...ellic.com ------------------------------------------------------------------------------ "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynmann
Powered by blists - more mailing lists