| Message ID | 20221111151451.v5.4.Ieb1215f598bc9df56b0e29e5977eae4fcca25e15@changeid (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | Encrypted Hibernation | expand |
On Fri, Nov 11, 2022 at 03:16:29PM -0800, Evan Green wrote: > diff --git a/security/keys/trusted-keys/tpm2key.asn1 b/security/keys/trusted-keys/tpm2key.asn1 > index f57f869ad60068..608f8d9ca95fa8 100644 > --- a/security/keys/trusted-keys/tpm2key.asn1 > +++ b/security/keys/trusted-keys/tpm2key.asn1 > @@ -7,5 +7,18 @@ TPMKey ::= SEQUENCE { > emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL, > parent INTEGER ({tpm2_key_parent}), > pubkey OCTET STRING ({tpm2_key_pub}), > - privkey OCTET STRING ({tpm2_key_priv}) > + privkey OCTET STRING ({tpm2_key_priv}), > + --- > + --- A TPM2B_CREATION_DATA struct as returned from the TPM2_Create command. > + --- > + creationData [1] EXPLICIT OCTET STRING OPTIONAL ({tpm2_key_creation_data}), > + --- > + --- A TPM2B_DIGEST of the creationHash as returned from the TPM2_Create > + --- command. > + --- > + creationHash [2] EXPLICIT OCTET STRING OPTIONAL ({tpm2_key_creation_hash}), > + --- > + --- A TPMT_TK_CREATION ticket as returned from the TPM2_Create command. > + --- > + creationTk [3] EXPLICIT OCTET STRING OPTIONAL ({tpm2_key_creation_tk}) > } The commit that added this file claimed: "The benefit of the ASN.1 format is that it's a standard and thus the exported key can be used by userspace tools (openssl_tpm2_engine, openconnect and tpm2-tss-engine" Are these new fields in compliance with whatever standard that was referring to? Or was that just referring to ASN.1 itself? > +/* Helper function to advance past a __be16 length + buffer safely */ > +static const u8 *get_sized_section(const u8 *src, const u8 *end, u16 *len) > +{ > + u32 length; > + > + if (src + sizeof(u16) > end) > + return NULL; 'end - src < sizeof(u16)', so the pointer isn't advanced past the end. > + > + /* Include the size field in the returned section length. */ > + length = get_unaligned_be16(src) + sizeof(u16); > + *len = length; > + if (*len != length) > + return NULL; > + > + src += *len; > + if (src > end) > + return NULL; > + > + return src; Similarly: if (end - src < *len) return NULL; return src + *len; > + /* > + * The creation ticket (TPMT_TK_CREATION) consists of a 2 byte > + * tag, 4 byte handle, and then a TPM2B_DIGEST, which is a 2 > + * byte length followed by data. > + */ > + if (src + 8 > end) end - src < 8 And actually it really should be 6 instead of 8, to match the code below. get_sized_section() already validates that there are at least 2 more bytes. > + return -EINVAL; > + > + creation_tk = src; > + src = get_sized_section(src + 6, end, &creation_tk_len); > + if (!src) > + return -EINVAL; > + > + creation_tk_len += 6; > + > + } else { > + creation_data_len = 0; > + creation_data = NULL; > + } > > if (!scratch) > return -ENOMEM; > @@ -63,26 +125,81 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, > } > > /* > - * Assume both octet strings will encode to a 2 byte definite length > + * Assume each octet string will encode to a 2 byte definite length. > + * Each optional octet string consumes one extra byte. > * > - * Note: For a well behaved TPM, this warning should never > - * trigger, so if it does there's something nefarious going on > + * Note: For a well behaved TPM, this warning should never trigger, so > + * if it does there's something nefarious going on > */ > - if (WARN(work - scratch + pub_len + priv_len + 14 > SCRATCH_SIZE, > - "BUG: scratch buffer is too small")) > - return -EINVAL; > + if (WARN(work - scratch + pub_len + priv_len + creation_data_len + > + creation_hash_len + creation_tk_len + (7 * 5) + 3 > > + SCRATCH_SIZE, > + "BUG: scratch buffer is too small")) { > + rc = -EINVAL; > + goto err; > + } This appears to be fixing a memory leak in the error case. The same memory leak also still appears above in: if (WARN(IS_ERR(w), "BUG: Boolean failed to encode")) return PTR_ERR(w); Maybe both should be fixed in a separate patch. > + work2 = asn1_encode_octet_string(scratch2, > + end_work2, > + creation_data, > + creation_data_len); > + > + work = asn1_encode_tag(work, > + end_work, > + 1, > + scratch2, > + work2 - scratch2); There's no helper function to do these two steps together? > + > - if (WARN(IS_ERR(work1), "BUG: ASN.1 encoder failed")) > - return PTR_ERR(work1); > + if (WARN(IS_ERR(work1), "BUG: ASN.1 encoder failed")) { > + rc = PTR_ERR(work1); > + goto err; > + } > > return work1 - payload->blob; > +err: > + kfree(scratch); > + return rc; Is this another memory leak fix that is unrelated to the functionality added by this patch? Also, isn't 'scratch' still being leaked in the success case? > static int tpm2_key_decode(struct trusted_key_payload *payload, > - struct trusted_key_options *options, > - u8 **buf) > + struct trusted_key_options *options) > { > + u64 data_len; > int ret; > struct tpm2_key_context ctx; > - u8 *blob; > + u8 *blob, *buf; > > memset(&ctx, 0, sizeof(ctx)); > > @@ -108,21 +231,57 @@ static int tpm2_key_decode(struct trusted_key_payload *payload, > if (ret < 0) > return ret; > > - if (ctx.priv_len + ctx.pub_len > MAX_BLOB_SIZE) > + data_len = ctx.priv_len + ctx.pub_len + ctx.creation_data_len + > + ctx.creation_hash_len + ctx.creation_tk_len; It's unclear why 'data_len' is a u64, given that the value assigned to it always fits in a u32. Perhaps you intended to do the additions with 64-bit numbers so that they can't overflow. But shouldn't the lengths already be bounded by size of the ASN.1 blob before even reaching here, anyway? > + > + if (data_len > MAX_BLOB_SIZE) > return -EINVAL; > > - blob = kmalloc(ctx.priv_len + ctx.pub_len + 4, GFP_KERNEL); > - if (!blob) > + buf = kmalloc(data_len + 4, GFP_KERNEL); > + if (!buf) > return -ENOMEM; It's unclear what the '+ 4' is for. > @@ -229,6 +424,7 @@ int tpm2_seal_trusted(struct tpm_chip *chip, > struct trusted_key_options *options) > { > int blob_len = 0; > + unsigned int offset; > struct tpm_buf buf; > u32 hash; > u32 flags; > @@ -317,13 +513,14 @@ int tpm2_seal_trusted(struct tpm_chip *chip, > rc = -E2BIG; > goto out; > } > - if (tpm_buf_length(&buf) < TPM_HEADER_SIZE + 4 + blob_len) { > + offset = TPM_HEADER_SIZE + 4; > + if (tpm_buf_length(&buf) < offset + blob_len) { > rc = -EFAULT; > goto out; > } > > blob_len = tpm2_key_encode(payload, options, > - &buf.data[TPM_HEADER_SIZE + 4], > + &buf.data[offset], > blob_len); This hunk of the patch doesn't seem to serve any purpose. - Eric
On Sun, 2022-11-13 at 13:20 -0800, Eric Biggers wrote: > On Fri, Nov 11, 2022 at 03:16:29PM -0800, Evan Green wrote: > > diff --git a/security/keys/trusted-keys/tpm2key.asn1 > > b/security/keys/trusted-keys/tpm2key.asn1 > > index f57f869ad60068..608f8d9ca95fa8 100644 > > --- a/security/keys/trusted-keys/tpm2key.asn1 > > +++ b/security/keys/trusted-keys/tpm2key.asn1 > > @@ -7,5 +7,18 @@ TPMKey ::= SEQUENCE { > > emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL, > > parent INTEGER ({tpm2_key_parent}), > > pubkey OCTET STRING ({tpm2_key_pub}), > > - privkey OCTET STRING ({tpm2_key_priv}) > > + privkey OCTET STRING ({tpm2_key_priv}), > > + --- > > + --- A TPM2B_CREATION_DATA struct as returned from the > > TPM2_Create command. > > + --- > > + creationData [1] EXPLICIT OCTET STRING OPTIONAL > > ({tpm2_key_creation_data}), > > + --- > > + --- A TPM2B_DIGEST of the creationHash as returned from the > > TPM2_Create > > + --- command. > > + --- > > + creationHash [2] EXPLICIT OCTET STRING OPTIONAL > > ({tpm2_key_creation_hash}), > > + --- > > + --- A TPMT_TK_CREATION ticket as returned from the > > TPM2_Create command. > > + --- > > + creationTk [3] EXPLICIT OCTET STRING OPTIONAL > > ({tpm2_key_creation_tk}) > > } > > The commit that added this file claimed: > > "The benefit of the ASN.1 format is that it's a standard and > thus the > exported key can be used by userspace tools > (openssl_tpm2_engine, > openconnect and tpm2-tss-engine" > > Are these new fields in compliance with whatever standard that was > referring to? Not really, no. The current use case (and draft standard) is already using [1] for policies and [2] for importable keys: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/doc/draft-bottomley-tpm2-keys.xml I'm actually planning to use [3] for signed policies. There's no reason why you can't use [4] though. Since the creation data, hash and ticket are likely used as a job lot, it strikes me they should be a single numbered optional sequence instead of individually numbered, since you're unlikely to have one without the others. James
On Sun, Nov 13, 2022 at 7:32 PM James Bottomley <jejb@linux.ibm.com> wrote: > > On Sun, 2022-11-13 at 13:20 -0800, Eric Biggers wrote: > > On Fri, Nov 11, 2022 at 03:16:29PM -0800, Evan Green wrote: > > > diff --git a/security/keys/trusted-keys/tpm2key.asn1 > > > b/security/keys/trusted-keys/tpm2key.asn1 > > > index f57f869ad60068..608f8d9ca95fa8 100644 > > > --- a/security/keys/trusted-keys/tpm2key.asn1 > > > +++ b/security/keys/trusted-keys/tpm2key.asn1 > > > @@ -7,5 +7,18 @@ TPMKey ::= SEQUENCE { > > > emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL, > > > parent INTEGER ({tpm2_key_parent}), > > > pubkey OCTET STRING ({tpm2_key_pub}), > > > - privkey OCTET STRING ({tpm2_key_priv}) > > > + privkey OCTET STRING ({tpm2_key_priv}), > > > + --- > > > + --- A TPM2B_CREATION_DATA struct as returned from the > > > TPM2_Create command. > > > + --- > > > + creationData [1] EXPLICIT OCTET STRING OPTIONAL > > > ({tpm2_key_creation_data}), > > > + --- > > > + --- A TPM2B_DIGEST of the creationHash as returned from the > > > TPM2_Create > > > + --- command. > > > + --- > > > + creationHash [2] EXPLICIT OCTET STRING OPTIONAL > > > ({tpm2_key_creation_hash}), > > > + --- > > > + --- A TPMT_TK_CREATION ticket as returned from the > > > TPM2_Create command. > > > + --- > > > + creationTk [3] EXPLICIT OCTET STRING OPTIONAL > > > ({tpm2_key_creation_tk}) > > > } > > > > The commit that added this file claimed: > > > > "The benefit of the ASN.1 format is that it's a standard and > > thus the > > exported key can be used by userspace tools > > (openssl_tpm2_engine, > > openconnect and tpm2-tss-engine" > > > > Are these new fields in compliance with whatever standard that was > > referring to? > > Not really, no. The current use case (and draft standard) is already > using [1] for policies and [2] for importable keys: > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/doc/draft-bottomley-tpm2-keys.xml > > I'm actually planning to use [3] for signed policies. There's no > reason why you can't use [4] though. Since the creation data, hash and > ticket are likely used as a job lot, it strikes me they should be a > single numbered optional sequence instead of individually numbered, > since you're unlikely to have one without the others. Thanks, I was hoping James might pipe up and tell me what to do. Grouping them as a single numbered optional sequence sounds reasonable to me. Is your draft too far along to squeeze this in? If it is and I'm on my own to draft up and submit this, I would definitely appreciate any pointers on getting started you might have. I notice the draft and the code seem to be out of alignment. I'm unfamiliar with this process, is the idea to get through all the iterations and land the standard, then fix up the code? What happens to existing data handed out in the old format? -Evan
On Mon, 2022-11-14 at 08:32 -0800, Evan Green wrote: > On Sun, Nov 13, 2022 at 7:32 PM James Bottomley <jejb@linux.ibm.com> > wrote: > > > > On Sun, 2022-11-13 at 13:20 -0800, Eric Biggers wrote: > > > On Fri, Nov 11, 2022 at 03:16:29PM -0800, Evan Green wrote: > > > > diff --git a/security/keys/trusted-keys/tpm2key.asn1 > > > > b/security/keys/trusted-keys/tpm2key.asn1 > > > > index f57f869ad60068..608f8d9ca95fa8 100644 > > > > --- a/security/keys/trusted-keys/tpm2key.asn1 > > > > +++ b/security/keys/trusted-keys/tpm2key.asn1 > > > > @@ -7,5 +7,18 @@ TPMKey ::= SEQUENCE { > > > > emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL, > > > > parent INTEGER ({tpm2_key_parent}), > > > > pubkey OCTET STRING ({tpm2_key_pub}), > > > > - privkey OCTET STRING ({tpm2_key_priv}) > > > > + privkey OCTET STRING ({tpm2_key_priv}), > > > > + --- > > > > + --- A TPM2B_CREATION_DATA struct as returned from the > > > > TPM2_Create command. > > > > + --- > > > > + creationData [1] EXPLICIT OCTET STRING OPTIONAL > > > > ({tpm2_key_creation_data}), > > > > + --- > > > > + --- A TPM2B_DIGEST of the creationHash as returned from > > > > the > > > > TPM2_Create > > > > + --- command. > > > > + --- > > > > + creationHash [2] EXPLICIT OCTET STRING OPTIONAL > > > > ({tpm2_key_creation_hash}), > > > > + --- > > > > + --- A TPMT_TK_CREATION ticket as returned from the > > > > TPM2_Create command. > > > > + --- > > > > + creationTk [3] EXPLICIT OCTET STRING OPTIONAL > > > > ({tpm2_key_creation_tk}) > > > > } > > > > > > The commit that added this file claimed: > > > > > > "The benefit of the ASN.1 format is that it's a standard > > > and thus the > > > exported key can be used by userspace tools > > > (openssl_tpm2_engine, > > > openconnect and tpm2-tss-engine" > > > > > > Are these new fields in compliance with whatever standard that > > > was referring to? > > > > Not really, no. The current use case (and draft standard) is > > already using [1] for policies and [2] for importable keys: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/doc/draft-bottomley-tpm2-keys.xml > > > > I'm actually planning to use [3] for signed policies. There's no > > reason why you can't use [4] though. Since the creation data, hash > > and ticket are likely used as a job lot, it strikes me they should > > be a single numbered optional sequence instead of individually > > numbered, since you're unlikely to have one without the others. > > Thanks, I was hoping James might pipe up and tell me what to do. > Grouping them as a single numbered optional sequence sounds > reasonable to me. Is your draft too far along to squeeze this in? Not at all. The draft only becomes frozen once I submit it to the IETF which, so far thanks to lack of any reviewers I haven't done (That's why I was also thinking of adding signed policies). > If it is and I'm on my own to draft up and submit this, I would > definitely appreciate any pointers on getting started you might have. > > I notice the draft and the code seem to be out of alignment. The kernel code is out of alignment just because development moves a bit slowly. Policy based keys were submitted a long time ago as part of the original move to interoperable sealed keys based on ASN.1: https://lore.kernel.org/all/20200616160229.8018-7-James.Bottomley@HansenPartnership.com/ But eventually the policy part was split out and forgotten about. I think the only complete implementation of the draft standard is the openssl_tpm2_engine. > I'm unfamiliar with this process, is the idea to get through all the > iterations and land the standard, then fix up the code? What happens > to existing data handed out in the old format? No, it doesn't matter at all. That's the whole point of using ASN.1 explicit optionals: the ASN.1 is always backwards compatible. If I ever submit the draft, there'll have to be a new RFC to add new explicit optionals, but keys conforming to the old RFC will still be valid under the new one. Of course, since openssl_tpm2_engine is the complete reference implementation that means I'll have to add the creation PCRs implementation to it ... unless you'd like to do it? Regards, James
On Mon, Nov 14, 2022 at 8:56 AM James Bottomley <jejb@linux.ibm.com> wrote: > > On Mon, 2022-11-14 at 08:32 -0800, Evan Green wrote: > > On Sun, Nov 13, 2022 at 7:32 PM James Bottomley <jejb@linux.ibm.com> > > wrote: > > > > > > On Sun, 2022-11-13 at 13:20 -0800, Eric Biggers wrote: > > > > On Fri, Nov 11, 2022 at 03:16:29PM -0800, Evan Green wrote: > > > > > diff --git a/security/keys/trusted-keys/tpm2key.asn1 > > > > > b/security/keys/trusted-keys/tpm2key.asn1 > > > > > index f57f869ad60068..608f8d9ca95fa8 100644 > > > > > --- a/security/keys/trusted-keys/tpm2key.asn1 > > > > > +++ b/security/keys/trusted-keys/tpm2key.asn1 > > > > > @@ -7,5 +7,18 @@ TPMKey ::= SEQUENCE { > > > > > emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL, > > > > > parent INTEGER ({tpm2_key_parent}), > > > > > pubkey OCTET STRING ({tpm2_key_pub}), > > > > > - privkey OCTET STRING ({tpm2_key_priv}) > > > > > + privkey OCTET STRING ({tpm2_key_priv}), > > > > > + --- > > > > > + --- A TPM2B_CREATION_DATA struct as returned from the > > > > > TPM2_Create command. > > > > > + --- > > > > > + creationData [1] EXPLICIT OCTET STRING OPTIONAL > > > > > ({tpm2_key_creation_data}), > > > > > + --- > > > > > + --- A TPM2B_DIGEST of the creationHash as returned from > > > > > the > > > > > TPM2_Create > > > > > + --- command. > > > > > + --- > > > > > + creationHash [2] EXPLICIT OCTET STRING OPTIONAL > > > > > ({tpm2_key_creation_hash}), > > > > > + --- > > > > > + --- A TPMT_TK_CREATION ticket as returned from the > > > > > TPM2_Create command. > > > > > + --- > > > > > + creationTk [3] EXPLICIT OCTET STRING OPTIONAL > > > > > ({tpm2_key_creation_tk}) > > > > > } > > > > > > > > The commit that added this file claimed: > > > > > > > > "The benefit of the ASN.1 format is that it's a standard > > > > and thus the > > > > exported key can be used by userspace tools > > > > (openssl_tpm2_engine, > > > > openconnect and tpm2-tss-engine" > > > > > > > > Are these new fields in compliance with whatever standard that > > > > was referring to? > > > > > > Not really, no. The current use case (and draft standard) is > > > already using [1] for policies and [2] for importable keys: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/doc/draft-bottomley-tpm2-keys.xml > > > > > > I'm actually planning to use [3] for signed policies. There's no > > > reason why you can't use [4] though. Since the creation data, hash > > > and ticket are likely used as a job lot, it strikes me they should > > > be a single numbered optional sequence instead of individually > > > numbered, since you're unlikely to have one without the others. > > > > Thanks, I was hoping James might pipe up and tell me what to do. > > Grouping them as a single numbered optional sequence sounds > > reasonable to me. Is your draft too far along to squeeze this in? > > Not at all. The draft only becomes frozen once I submit it to the IETF > which, so far thanks to lack of any reviewers I haven't done (That's > why I was also thinking of adding signed policies). > > > If it is and I'm on my own to draft up and submit this, I would > > definitely appreciate any pointers on getting started you might have. > > > > I notice the draft and the code seem to be out of alignment. > > The kernel code is out of alignment just because development moves a > bit slowly. Policy based keys were submitted a long time ago as part > of the original move to interoperable sealed keys based on ASN.1: > > https://lore.kernel.org/all/20200616160229.8018-7-James.Bottomley@HansenPartnership.com/ > > But eventually the policy part was split out and forgotten about. I > think the only complete implementation of the draft standard is the > openssl_tpm2_engine. > > > I'm unfamiliar with this process, is the idea to get through all the > > iterations and land the standard, then fix up the code? What happens > > to existing data handed out in the old format? > > No, it doesn't matter at all. That's the whole point of using ASN.1 > explicit optionals: the ASN.1 is always backwards compatible. If I > ever submit the draft, there'll have to be a new RFC to add new > explicit optionals, but keys conforming to the old RFC will still be > valid under the new one. Ah I see, with the optionals in mind things do line up again. > > Of course, since openssl_tpm2_engine is the complete reference > implementation that means I'll have to add the creation PCRs > implementation to it ... unless you'd like to do it? I am willing to help as I'm the one making the mess. How does it sequence along with your draft submission (before, after, simultaneous)?
On Mon, 2022-11-14 at 09:43 -0800, Evan Green wrote: > On Mon, Nov 14, 2022 at 8:56 AM James Bottomley <jejb@linux.ibm.com> > wrote: [...] > > Of course, since openssl_tpm2_engine is the complete reference > > implementation that means I'll have to add the creation PCRs > > implementation to it ... unless you'd like to do it? > > I am willing to help as I'm the one making the mess. How does it > sequence along with your draft submission (before, after, > simultaneous)? At the moment, just send patches. The openssl_tpm2_engine is developed on a groups.io mailing list: https://groups.io/g/openssl-tpm2-engine/ You need an IETF specific tool (xml2rfc) to build the rfc from the xml, but it's available in most distros as python3-xml2rfc. If you don't want to learn the IETF XML I can help you code up the patch to add that to the draft spec. Regards, James
On Mon, 2022-11-14 at 13:00 -0500, James Bottomley wrote: > On Mon, 2022-11-14 at 09:43 -0800, Evan Green wrote: > > On Mon, Nov 14, 2022 at 8:56 AM James Bottomley > > <jejb@linux.ibm.com> > > wrote: > [...] > > > Of course, since openssl_tpm2_engine is the complete reference > > > implementation that means I'll have to add the creation PCRs > > > implementation to it ... unless you'd like to do it? > > > > I am willing to help as I'm the one making the mess. How does it > > sequence along with your draft submission (before, after, > > simultaneous)? > > At the moment, just send patches. The openssl_tpm2_engine is > developed on a groups.io mailing list: > > https://groups.io/g/openssl-tpm2-engine/ > > You need an IETF specific tool (xml2rfc) to build the rfc from the > xml, but it's available in most distros as python3-xml2rfc. If you > don't want to learn the IETF XML I can help you code up the patch to > add that to the draft spec. Just as a heads up, the patch series implementing signed policy (and thus taking option [3]) is on the mailing list for review: https://groups.io/g/openssl-tpm2-engine/message/296 With apologies for the awful lack of threading in the groups.io interface. So you don't have to build the RFC yourself, I published the proposed update on my website: https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.txt If you want to use option [4] for the creation data, it's available. Regards, James
On Fri, Dec 2, 2022 at 1:03 PM James Bottomley <jejb@linux.ibm.com> wrote: > > On Mon, 2022-11-14 at 13:00 -0500, James Bottomley wrote: > > On Mon, 2022-11-14 at 09:43 -0800, Evan Green wrote: > > > On Mon, Nov 14, 2022 at 8:56 AM James Bottomley > > > <jejb@linux.ibm.com> > > > wrote: > > [...] > > > > Of course, since openssl_tpm2_engine is the complete reference > > > > implementation that means I'll have to add the creation PCRs > > > > implementation to it ... unless you'd like to do it? > > > > > > I am willing to help as I'm the one making the mess. How does it > > > sequence along with your draft submission (before, after, > > > simultaneous)? > > > > At the moment, just send patches. The openssl_tpm2_engine is > > developed on a groups.io mailing list: > > > > https://groups.io/g/openssl-tpm2-engine/ > > > > You need an IETF specific tool (xml2rfc) to build the rfc from the > > xml, but it's available in most distros as python3-xml2rfc. If you > > don't want to learn the IETF XML I can help you code up the patch to > > add that to the draft spec. > > Just as a heads up, the patch series implementing signed policy (and > thus taking option [3]) is on the mailing list for review: > > https://groups.io/g/openssl-tpm2-engine/message/296 > > With apologies for the awful lack of threading in the groups.io > interface. > > So you don't have to build the RFC yourself, I published the proposed > update on my website: > > https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html > https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.txt > > If you want to use option [4] for the creation data, it's available. Perfect, thanks James! -Evan
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h index 4eb64548a74f1a..209086fed240a5 100644 --- a/include/keys/trusted-type.h +++ b/include/keys/trusted-type.h @@ -22,15 +22,23 @@ #define MAX_BLOB_SIZE 512 #define MAX_PCRINFO_SIZE 64 #define MAX_DIGEST_SIZE 64 +#define MAX_CREATION_DATA 412 +#define MAX_TK 76 struct trusted_key_payload { struct rcu_head rcu; unsigned int key_len; unsigned int blob_len; + unsigned int creation_len; + unsigned int creation_hash_len; + unsigned int tk_len; unsigned char migratable; unsigned char old_format; unsigned char key[MAX_KEY_SIZE + 1]; unsigned char blob[MAX_BLOB_SIZE]; + unsigned char *creation; + unsigned char *creation_hash; + unsigned char *tk; }; struct trusted_key_options { diff --git a/security/keys/trusted-keys/tpm2key.asn1 b/security/keys/trusted-keys/tpm2key.asn1 index f57f869ad60068..608f8d9ca95fa8 100644 --- a/security/keys/trusted-keys/tpm2key.asn1 +++ b/security/keys/trusted-keys/tpm2key.asn1 @@ -7,5 +7,18 @@ TPMKey ::= SEQUENCE { emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL, parent INTEGER ({tpm2_key_parent}), pubkey OCTET STRING ({tpm2_key_pub}), - privkey OCTET STRING ({tpm2_key_priv}) + privkey OCTET STRING ({tpm2_key_priv}), + --- + --- A TPM2B_CREATION_DATA struct as returned from the TPM2_Create command. + --- + creationData [1] EXPLICIT OCTET STRING OPTIONAL ({tpm2_key_creation_data}), + --- + --- A TPM2B_DIGEST of the creationHash as returned from the TPM2_Create + --- command. + --- + creationHash [2] EXPLICIT OCTET STRING OPTIONAL ({tpm2_key_creation_hash}), + --- + --- A TPMT_TK_CREATION ticket as returned from the TPM2_Create command. + --- + creationTk [3] EXPLICIT OCTET STRING OPTIONAL ({tpm2_key_creation_tk}) } diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c index 2b2c8eb258d5bd..ff2aede8986236 100644 --- a/security/keys/trusted-keys/trusted_tpm2.c +++ b/security/keys/trusted-keys/trusted_tpm2.c @@ -28,24 +28,86 @@ static struct tpm2_hash tpm2_hash_map[] = { static u32 tpm2key_oid[] = { 2, 23, 133, 10, 1, 5 }; +/* Helper function to advance past a __be16 length + buffer safely */ +static const u8 *get_sized_section(const u8 *src, const u8 *end, u16 *len) +{ + u32 length; + + if (src + sizeof(u16) > end) + return NULL; + + /* Include the size field in the returned section length. */ + length = get_unaligned_be16(src) + sizeof(u16); + *len = length; + if (*len != length) + return NULL; + + src += *len; + if (src > end) + return NULL; + + return src; +} + static int tpm2_key_encode(struct trusted_key_payload *payload, struct trusted_key_options *options, - u8 *src, u32 len) + const u8 *src, u32 len) { const int SCRATCH_SIZE = PAGE_SIZE; + const u8 *end = src + len; u8 *scratch = kmalloc(SCRATCH_SIZE, GFP_KERNEL); u8 *work = scratch, *work1; u8 *end_work = scratch + SCRATCH_SIZE; - u8 *priv, *pub; + const u8 *priv, *pub; + const u8 *creation_data = NULL, *creation_hash = NULL, *creation_tk = NULL; + u16 creation_data_len, creation_hash_len = 0, creation_tk_len = 0; u16 priv_len, pub_len; + int rc; - priv_len = get_unaligned_be16(src) + 2; priv = src; + src = get_sized_section(src, end, &priv_len); + if (!src) + return -EINVAL; - src += priv_len; - - pub_len = get_unaligned_be16(src) + 2; pub = src; + src = get_sized_section(src, end, &pub_len); + if (!src) + return -EINVAL; + + creation_data = src; + src = get_sized_section(src, end, &creation_data_len); + if (!src) + return -EINVAL; + + /* + * If the creation data has content, pull out the creation hash and + * ticket as well. Otherwise pretend it doesn't exist. + */ + if (creation_data_len > sizeof(u16)) { + creation_hash = src; + src = get_sized_section(src, end, &creation_hash_len); + if (!src) + return -EINVAL; + + /* + * The creation ticket (TPMT_TK_CREATION) consists of a 2 byte + * tag, 4 byte handle, and then a TPM2B_DIGEST, which is a 2 + * byte length followed by data. + */ + if (src + 8 > end) + return -EINVAL; + + creation_tk = src; + src = get_sized_section(src + 6, end, &creation_tk_len); + if (!src) + return -EINVAL; + + creation_tk_len += 6; + + } else { + creation_data_len = 0; + creation_data = NULL; + } if (!scratch) return -ENOMEM; @@ -63,26 +125,81 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, } /* - * Assume both octet strings will encode to a 2 byte definite length + * Assume each octet string will encode to a 2 byte definite length. + * Each optional octet string consumes one extra byte. * - * Note: For a well behaved TPM, this warning should never - * trigger, so if it does there's something nefarious going on + * Note: For a well behaved TPM, this warning should never trigger, so + * if it does there's something nefarious going on */ - if (WARN(work - scratch + pub_len + priv_len + 14 > SCRATCH_SIZE, - "BUG: scratch buffer is too small")) - return -EINVAL; + if (WARN(work - scratch + pub_len + priv_len + creation_data_len + + creation_hash_len + creation_tk_len + (7 * 5) + 3 > + SCRATCH_SIZE, + "BUG: scratch buffer is too small")) { + rc = -EINVAL; + goto err; + } work = asn1_encode_integer(work, end_work, options->keyhandle); work = asn1_encode_octet_string(work, end_work, pub, pub_len); work = asn1_encode_octet_string(work, end_work, priv, priv_len); + if (creation_data_len) { + u8 *scratch2 = kmalloc(SCRATCH_SIZE, GFP_KERNEL); + u8 *work2; + u8 *end_work2 = scratch2 + SCRATCH_SIZE; + + if (!scratch2) { + rc = -ENOMEM; + goto err; + } + + work2 = asn1_encode_octet_string(scratch2, + end_work2, + creation_data, + creation_data_len); + + work = asn1_encode_tag(work, + end_work, + 1, + scratch2, + work2 - scratch2); + + work2 = asn1_encode_octet_string(scratch2, + end_work2, + creation_hash, + creation_hash_len); + + work = asn1_encode_tag(work, + end_work, + 2, + scratch2, + work2 - scratch2); + + work2 = asn1_encode_octet_string(scratch2, + end_work2, + creation_tk, + creation_tk_len); + + work = asn1_encode_tag(work, + end_work, + 3, + scratch2, + work2 - scratch2); + + kfree(scratch2); + } work1 = payload->blob; work1 = asn1_encode_sequence(work1, work1 + sizeof(payload->blob), scratch, work - scratch); - if (WARN(IS_ERR(work1), "BUG: ASN.1 encoder failed")) - return PTR_ERR(work1); + if (WARN(IS_ERR(work1), "BUG: ASN.1 encoder failed")) { + rc = PTR_ERR(work1); + goto err; + } return work1 - payload->blob; +err: + kfree(scratch); + return rc; } struct tpm2_key_context { @@ -91,15 +208,21 @@ struct tpm2_key_context { u32 pub_len; const u8 *priv; u32 priv_len; + const u8 *creation_data; + u32 creation_data_len; + const u8 *creation_hash; + u32 creation_hash_len; + const u8 *creation_tk; + u32 creation_tk_len; }; static int tpm2_key_decode(struct trusted_key_payload *payload, - struct trusted_key_options *options, - u8 **buf) + struct trusted_key_options *options) { + u64 data_len; int ret; struct tpm2_key_context ctx; - u8 *blob; + u8 *blob, *buf; memset(&ctx, 0, sizeof(ctx)); @@ -108,21 +231,57 @@ static int tpm2_key_decode(struct trusted_key_payload *payload, if (ret < 0) return ret; - if (ctx.priv_len + ctx.pub_len > MAX_BLOB_SIZE) + data_len = ctx.priv_len + ctx.pub_len + ctx.creation_data_len + + ctx.creation_hash_len + ctx.creation_tk_len; + + if (data_len > MAX_BLOB_SIZE) return -EINVAL; - blob = kmalloc(ctx.priv_len + ctx.pub_len + 4, GFP_KERNEL); - if (!blob) + buf = kmalloc(data_len + 4, GFP_KERNEL); + if (!buf) return -ENOMEM; - *buf = blob; + blob = buf; options->keyhandle = ctx.parent; memcpy(blob, ctx.priv, ctx.priv_len); blob += ctx.priv_len; memcpy(blob, ctx.pub, ctx.pub_len); + blob += ctx.pub_len; + if (ctx.creation_data_len) { + memcpy(blob, ctx.creation_data, ctx.creation_data_len); + blob += ctx.creation_data_len; + } + if (ctx.creation_hash_len) { + memcpy(blob, ctx.creation_hash, ctx.creation_hash_len); + blob += ctx.creation_hash_len; + } + + if (ctx.creation_tk_len) { + memcpy(blob, ctx.creation_tk, ctx.creation_tk_len); + blob += ctx.creation_tk_len; + } + + /* + * Copy the buffer back into the payload blob since the creation + * info will be used after loading. + */ + payload->blob_len = blob - buf; + memcpy(payload->blob, buf, payload->blob_len); + if (ctx.creation_data_len) { + payload->creation = payload->blob + ctx.priv_len + ctx.pub_len; + payload->creation_len = ctx.creation_data_len; + payload->creation_hash = payload->creation + ctx.creation_data_len; + payload->creation_hash_len = ctx.creation_hash_len; + payload->tk = payload->creation_hash + + payload->creation_hash_len; + + payload->tk_len = ctx.creation_tk_len; + } + + kfree(buf); return 0; } @@ -185,6 +344,42 @@ int tpm2_key_priv(void *context, size_t hdrlen, return 0; } +int tpm2_key_creation_data(void *context, size_t hdrlen, + unsigned char tag, + const void *value, size_t vlen) +{ + struct tpm2_key_context *ctx = context; + + ctx->creation_data = value; + ctx->creation_data_len = vlen; + + return 0; +} + +int tpm2_key_creation_hash(void *context, size_t hdrlen, + unsigned char tag, + const void *value, size_t vlen) +{ + struct tpm2_key_context *ctx = context; + + ctx->creation_hash = value; + ctx->creation_hash_len = vlen; + + return 0; +} + +int tpm2_key_creation_tk(void *context, size_t hdrlen, + unsigned char tag, + const void *value, size_t vlen) +{ + struct tpm2_key_context *ctx = context; + + ctx->creation_tk = value; + ctx->creation_tk_len = vlen; + + return 0; +} + /** * tpm_buf_append_auth() - append TPMS_AUTH_COMMAND to the buffer. * @@ -229,6 +424,7 @@ int tpm2_seal_trusted(struct tpm_chip *chip, struct trusted_key_options *options) { int blob_len = 0; + unsigned int offset; struct tpm_buf buf; u32 hash; u32 flags; @@ -317,13 +513,14 @@ int tpm2_seal_trusted(struct tpm_chip *chip, rc = -E2BIG; goto out; } - if (tpm_buf_length(&buf) < TPM_HEADER_SIZE + 4 + blob_len) { + offset = TPM_HEADER_SIZE + 4; + if (tpm_buf_length(&buf) < offset + blob_len) { rc = -EFAULT; goto out; } blob_len = tpm2_key_encode(payload, options, - &buf.data[TPM_HEADER_SIZE + 4], + &buf.data[offset], blob_len); out: @@ -370,13 +567,11 @@ static int tpm2_load_cmd(struct tpm_chip *chip, int rc; u32 attrs; - rc = tpm2_key_decode(payload, options, &blob); - if (rc) { - /* old form */ - blob = payload->blob; + rc = tpm2_key_decode(payload, options); + if (rc) payload->old_format = 1; - } + blob = payload->blob; /* new format carries keyhandle but old format doesn't */ if (!options->keyhandle) return -EINVAL; @@ -433,8 +628,6 @@ static int tpm2_load_cmd(struct tpm_chip *chip, (__be32 *) &buf.data[TPM_HEADER_SIZE]); out: - if (blob != payload->blob) - kfree(blob); tpm_buf_destroy(&buf); if (rc > 0)
In addition to the private key and public key, the TPM2_Create command may also return creation data, a creation hash, and a creation ticket. These fields allow the TPM to attest to the contents of a specified set of PCRs at the time the trusted key was created. Encrypted hibernation will use this to ensure that PCRs settable only by the kernel were set properly at the time of creation, indicating this is an authentic hibernate key. Encode these additional parameters into the ASN.1 created to represent the key blob. The new fields are made optional so that they don't bloat key blobs which don't need them, and to ensure interoperability with old blobs. Signed-off-by: Evan Green <evgreen@chromium.org> --- Changes in v5: - Factored some math out to a helper function (Kees) - Constified src in tpm2_key_encode(). Changes in v3: - Fix SoB and -- note ordering (Kees) - Add comments describing the TPM2 spec type names for the new fields in tpm2key.asn1 (Kees) - Add len buffer checks in tpm2_key_encode() (Kees) This is a replacement for Matthew's original patch here: https://patchwork.kernel.org/patch/12096489/ That patch was written before the exported key format was switched to ASN.1. This patch accomplishes the same thing (saving, loading, and getting pointers to the creation data) while utilizing the new ASN.1 format. --- include/keys/trusted-type.h | 8 + security/keys/trusted-keys/tpm2key.asn1 | 15 +- security/keys/trusted-keys/trusted_tpm2.c | 253 +++++++++++++++++++--- 3 files changed, 245 insertions(+), 31 deletions(-)