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. Cheers, Andreas ________________________________________ 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/
