On Sun, Oct 04, 2015 at 06:57:42PM +0000, Fuchs, Andreas wrote: > Hi Jarkko, > > thanks for the clearification... > > However, I'd recommend against doing so. > > Furthermore, if there is a resource-manager running in userspace, > applications only get virtual handles and TPM might be empty > actually... > > If that's what you're aiming for, I'd recommend passing the pointer to > a context-saved-blob and have the kernel load the key this way. That > ensures no problems with resource-manager and handle-mixups.
TPM 1.x interface has the same race if you do not use the default value for the 'keyhandle' option. In practice a processs in TCB (or root) would do all the keyctl magic so I do not see huge issue here. It can be orchestrated by the OS/distribution. From my point of view you are over-engineering in wrong place. It would be easy to add a way to provide the sealing key as blob later on if the simple approach chosen would not be sufficient. I'm confident that for 99% of all real-world use cases the interface provided by the patch set is sufficient. > Cheers, > Andreas /Jarkko > From: Jarkko Sakkinen [jarkko.sakki...@linux.intel.com] > Sent: Saturday, October 03, 2015 12:26 > To: Fuchs, Andreas > Cc: tpmdd-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org; David > Howells; gre...@linuxfoundation.org; open list:KEYS-TRUSTED; open > list:KEYS-TRUSTED; James Morris; David Safford; a...@linux-foundation.org; > Serge E. Hallyn > Subject: Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM > 2.0 chips > > On Sat, Oct 03, 2015 at 10:00:59AM +0000, Fuchs, Andreas wrote: > > Hi Jarkko, > > > > [snip] > > > > diff --git a/security/keys/trusted.h b/security/keys/trusted.h > > index ff001a5..fc32c47 100644 > > --- a/security/keys/trusted.h > > +++ b/security/keys/trusted.h > > @@ -12,6 +12,13 @@ > > #define TPM_RETURN_OFFSET 6 > > #define TPM_DATA_OFFSET 10 > > > > +/* Transient object handles start from 0x80000000 in TPM 2.0, which makes > > it > > + * a sane default. > > + */ > > + > > +#define TPM1_SRKHANDLE 0x40000000 > > +#define TPM2_SRKHANDLE 0x80000000 > > + > > #define LOAD32(buffer, offset) (ntohl(*(uint32_t *)&buffer[offset])) > > #define LOAD32N(buffer, offset) (*(uint32_t *)&buffer[offset]) > > #define LOAD16(buffer, offset) (ntohs(*(uint16_t *)&buffer[offset])) > > > > This TPM2_SRKHANDLE is unfortunately wrong. > > > > Transient handles are assigned and returned by the TPM following the > > commands TPM2_CreatePrimary, TPM2_LoadObject and TPM2_ContextLoad. You > > can only use transient handles as returned by the TPM in order to > > refer to the corresponding object created inside the TPM via these > > commands. They can never assumed to be constant. The fact that TPMs > > return 0x80000000 for the first loaded Object and 0x80000001 for the > > second is merely a coincidence... ;-) > > > > TPM2 also has no (single) SRK anymore. You have to create your own SRK > > / Storage Primary Keys via TPM2_CreatePrimary and use the transient > > handle returned from there. This however requires SH-authorization, > > usually via Policy IMHO, so not easy to manage. So IMHO, this might be > > something for the future but for the moment relying on a persistent > > key would be better... > > > > For persistent SRKs it should become a convention to have those > > around. Those handles start with 0x81000000 and the SRKs (or Storage > > primary Keys) shall live within 0x81000000 to 0x8100FFFF (see > > http://www.trustedcomputinggroup.org/resources/registry_of_reserved_tpm_20_handles_and_localities) > > > > I'd recommend to rely on the existence of a handle inside this range > > with an empty auth-value. So maybe install a persistent SRK to > > 0x81000000 via TPM2_EvictControl and then use this from within the > > kernel for anything following. > > P.S. You should check for the key's TPMA_OBJECT to have fixedTPM SET. > > I don't know if there is an actual test for owner-generated SRK > > testing. I'll ask around though... > > > > Note: you can query for handles in this range via > > TPM2_GetCapability(TPM_CAP_HANDLES, 0x81000000) and then look for > > fitting keys. > > > > > > Feel free to discuss other approaches. > > I'm fully aware of all what you said. My take was to use 0x800000000 as > a default value if you don't the handle ID explicitly in 'description' > parameter of the add_key() syscall. > > > Cheers, > > Andreas > > /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
