| Message ID | 20240523131931.22350-1-jarkko@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RESEND] KEYS: trusted: Use ASN.1 encoded OID | expand |
On Thu, 2024-05-23 at 16:19 +0300, Jarkko Sakkinen wrote: > There's no reason to encode OID_TPMSealedData at run-time, as it > never changes. > > Replace it with the encoded version, which has exactly the same size: > > 67 81 05 0A 01 05 > > Include OBJECT IDENTIFIER (0x06) tag and length as the epilogue so > that the OID can be simply copied to the blob. This is true, but if we're going to do this, we should expand the OID registry functions (in lib/oid_registry.c) to do something like encode_OID. The registry already contains the hex above minus the two prefixes (which are easy to add). I also note: > @ -51,8 +52,8 @@ static int tpm2_key_encode(struct > trusted_key_payload *payload, > if (!scratch) > return -ENOMEM; > > - work = asn1_encode_oid(work, end_work, tpm2key_oid, > - asn1_oid_len(tpm2key_oid)); > + work = memcpy(work, OID_TPMSealedData_ASN1, > sizeof(OID_TPMSealedData_ASN1)); > + work += sizeof(OID_TPMSealedData_ASN1); You lost the actually fits check. This is somewhat irrelevant for TPM keys because the OID is first in the structure and thus will never overflow, but it might matter for other uses. James
On Thu May 23, 2024 at 4:38 PM EEST, James Bottomley wrote: > On Thu, 2024-05-23 at 16:19 +0300, Jarkko Sakkinen wrote: > > There's no reason to encode OID_TPMSealedData at run-time, as it > > never changes. > > > > Replace it with the encoded version, which has exactly the same size: > > > > 67 81 05 0A 01 05 > > > > Include OBJECT IDENTIFIER (0x06) tag and length as the epilogue so > > that the OID can be simply copied to the blob. > > This is true, but if we're going to do this, we should expand the OID > registry functions (in lib/oid_registry.c) to do something like > encode_OID. The registry already contains the hex above minus the two > prefixes (which are easy to add). Yes, I do agree with this idea, and I named variable the I named it to make it obvious that generation is possible. It would be best to have a single source, which could be just a CSV file with entries like: <Name>,<OID number> And then in scripts/ there should be a script that takes this source and generates oid_registry.gen.{h,c}. The existing oid_registry.h should really just include oid_registry.gen.h then to make this transparent change. And then in the series where OID's are encoded per-subsystem patch that takes pre-encoded OID into use. Happy to review such patch set if it is pushed forward. > > @ -51,8 +52,8 @@ static int tpm2_key_encode(struct > > trusted_key_payload *payload, > > if (!scratch) > > return -ENOMEM; > > > > - work = asn1_encode_oid(work, end_work, tpm2key_oid, > > - asn1_oid_len(tpm2key_oid)); > > + work = memcpy(work, OID_TPMSealedData_ASN1, > > sizeof(OID_TPMSealedData_ASN1)); > > + work += sizeof(OID_TPMSealedData_ASN1); > > You lost the actually fits check. This is somewhat irrelevant for TPM > keys because the OID is first in the structure and thus will never > overflow, but it might matter for other uses. Yep, it is irrelevant IMHO, there is 8 bytes, and also its location never changes. > James BR, Jarkko
On Thu, 2024-05-23 at 16:54 +0300, Jarkko Sakkinen wrote: > On Thu May 23, 2024 at 4:38 PM EEST, James Bottomley wrote: > > On Thu, 2024-05-23 at 16:19 +0300, Jarkko Sakkinen wrote: > > > There's no reason to encode OID_TPMSealedData at run-time, as it > > > never changes. > > > > > > Replace it with the encoded version, which has exactly the same > > > size: > > > > > > 67 81 05 0A 01 05 > > > > > > Include OBJECT IDENTIFIER (0x06) tag and length as the epilogue > > > so > > > that the OID can be simply copied to the blob. > > > > This is true, but if we're going to do this, we should expand the > > OID > > registry functions (in lib/oid_registry.c) to do something like > > encode_OID. The registry already contains the hex above minus the > > two > > prefixes (which are easy to add). > > Yes, I do agree with this idea, and I named variable the I named > it to make it obvious that generation is possible. > > It would be best to have a single source, which could be just > a CSV file with entries like: > > <Name>,<OID number> > > And then in scripts/ there should be a script that takes this > source and generates oid_registry.gen.{h,c}. The existing > oid_registry.h should really just include oid_registry.gen.h > then to make this transparent change. > > And then in the series where OID's are encoded per-subsystem > patch that takes pre-encoded OID into use. > > Happy to review such patch set if it is pushed forward. Heh, OK, since I'm the one who thinks it's quite easy, I'll give it a go. James
On Thu May 23, 2024 at 6:30 PM EEST, James Bottomley wrote: > On Thu, 2024-05-23 at 16:54 +0300, Jarkko Sakkinen wrote: > > On Thu May 23, 2024 at 4:38 PM EEST, James Bottomley wrote: > > > On Thu, 2024-05-23 at 16:19 +0300, Jarkko Sakkinen wrote: > > > > There's no reason to encode OID_TPMSealedData at run-time, as it > > > > never changes. > > > > > > > > Replace it with the encoded version, which has exactly the same > > > > size: > > > > > > > > 67 81 05 0A 01 05 > > > > > > > > Include OBJECT IDENTIFIER (0x06) tag and length as the epilogue > > > > so > > > > that the OID can be simply copied to the blob. > > > > > > This is true, but if we're going to do this, we should expand the > > > OID > > > registry functions (in lib/oid_registry.c) to do something like > > > encode_OID. The registry already contains the hex above minus the > > > two > > > prefixes (which are easy to add). > > > > Yes, I do agree with this idea, and I named variable the I named > > it to make it obvious that generation is possible. > > > > It would be best to have a single source, which could be just > > a CSV file with entries like: > > > > <Name>,<OID number> > > > > And then in scripts/ there should be a script that takes this > > source and generates oid_registry.gen.{h,c}. The existing > > oid_registry.h should really just include oid_registry.gen.h > > then to make this transparent change. > > > > And then in the series where OID's are encoded per-subsystem > > patch that takes pre-encoded OID into use. > > > > Happy to review such patch set if it is pushed forward. > > Heh, OK, since I'm the one who thinks it's quite easy, I'll give it a > go. I guess if it cleaned up multiple sites in kernel then it could be considered useful. I'd guess that there is at least a few locations that also encode OID. BR, Jarkko
On Thu, 2024-05-23 at 18:37 +0300, Jarkko Sakkinen wrote: > On Thu May 23, 2024 at 6:30 PM EEST, James Bottomley wrote: > > On Thu, 2024-05-23 at 16:54 +0300, Jarkko Sakkinen wrote: > > > On Thu May 23, 2024 at 4:38 PM EEST, James Bottomley wrote: > > > > On Thu, 2024-05-23 at 16:19 +0300, Jarkko Sakkinen wrote: > > > > > There's no reason to encode OID_TPMSealedData at run-time, as > > > > > it never changes. > > > > > > > > > > Replace it with the encoded version, which has exactly the > > > > > same size: > > > > > > > > > > 67 81 05 0A 01 05 > > > > > > > > > > Include OBJECT IDENTIFIER (0x06) tag and length as the > > > > > epilogue so that the OID can be simply copied to the blob. > > > > > > > > This is true, but if we're going to do this, we should expand > > > > the OID registry functions (in lib/oid_registry.c) to do > > > > something like encode_OID. The registry already contains the > > > > hex above minus the two prefixes (which are easy to add). > > > > > > Yes, I do agree with this idea, and I named variable the I named > > > it to make it obvious that generation is possible. > > > > > > It would be best to have a single source, which could be just > > > a CSV file with entries like: > > > > > > <Name>,<OID number> > > > > > > And then in scripts/ there should be a script that takes this > > > source and generates oid_registry.gen.{h,c}. The existing > > > oid_registry.h should really just include oid_registry.gen.h > > > then to make this transparent change. > > > > > > And then in the series where OID's are encoded per-subsystem > > > patch that takes pre-encoded OID into use. > > > > > > Happy to review such patch set if it is pushed forward. > > > > Heh, OK, since I'm the one who thinks it's quite easy, I'll give it > > a go. > > I guess if it cleaned up multiple sites in kernel then it could > be considered useful. I'd guess that there is at least a few > locations that also encode OID. This should be the only one currently. The ASN.1 encoding was added to the kernel to support the trusted keys pipe use case. However, if you want the kernel to construct and pipe out asymmetric keys, that would be the second use case. James
On Thu May 23, 2024 at 6:43 PM EEST, James Bottomley wrote: > On Thu, 2024-05-23 at 18:37 +0300, Jarkko Sakkinen wrote: > > On Thu May 23, 2024 at 6:30 PM EEST, James Bottomley wrote: > > > On Thu, 2024-05-23 at 16:54 +0300, Jarkko Sakkinen wrote: > > > > On Thu May 23, 2024 at 4:38 PM EEST, James Bottomley wrote: > > > > > On Thu, 2024-05-23 at 16:19 +0300, Jarkko Sakkinen wrote: > > > > > > There's no reason to encode OID_TPMSealedData at run-time, as > > > > > > it never changes. > > > > > > > > > > > > Replace it with the encoded version, which has exactly the > > > > > > same size: > > > > > > > > > > > > 67 81 05 0A 01 05 > > > > > > > > > > > > Include OBJECT IDENTIFIER (0x06) tag and length as the > > > > > > epilogue so that the OID can be simply copied to the blob. > > > > > > > > > > This is true, but if we're going to do this, we should expand > > > > > the OID registry functions (in lib/oid_registry.c) to do > > > > > something like encode_OID. The registry already contains the > > > > > hex above minus the two prefixes (which are easy to add). > > > > > > > > Yes, I do agree with this idea, and I named variable the I named > > > > it to make it obvious that generation is possible. > > > > > > > > It would be best to have a single source, which could be just > > > > a CSV file with entries like: > > > > > > > > <Name>,<OID number> > > > > > > > > And then in scripts/ there should be a script that takes this > > > > source and generates oid_registry.gen.{h,c}. The existing > > > > oid_registry.h should really just include oid_registry.gen.h > > > > then to make this transparent change. > > > > > > > > And then in the series where OID's are encoded per-subsystem > > > > patch that takes pre-encoded OID into use. > > > > > > > > Happy to review such patch set if it is pushed forward. > > > > > > Heh, OK, since I'm the one who thinks it's quite easy, I'll give it > > > a go. > > > > I guess if it cleaned up multiple sites in kernel then it could > > be considered useful. I'd guess that there is at least a few > > locations that also encode OID. > > This should be the only one currently. The ASN.1 encoding was added to > the kernel to support the trusted keys pipe use case. However, if you > want the kernel to construct and pipe out asymmetric keys, that would > be the second use case. Yes, we definitely need tpm2_key_ecdsa, and that is actually probably more important than RSA but I think both are needed. It was easier to use RSA to carve stuff to fit as there some off-the-shelf code that could be modified for the purpose. I was already considering do we need the encoder at all but I think for dynamic assets like octect strings and variable size integers it has its place. Obviously is not very mature at this point. I think I keep the "dump" strategy for RSA keys at least for first to keep the series as tight as possible but at least v3 included already a patch to make asn1_encode_integer() eat variable size stuff: https://lore.kernel.org/linux-integrity/20240521152659.26438-3-jarkko@kernel.org/ So my proposal here is that I land RSA keys without using encoder but that said it can take them into use in ECDSA keys when the encoder has been carved up properly. There's already bunch of things changed in v4, so thus I did not want to keep this in that series: https://lore.kernel.org/linux-integrity/20240522005252.17841-1-jarkko@kernel.org/ I.e. the dump can be considered as first iteration. There's bunch of uses for these keys, e.g. WIFI passwords, Ethereum keypairs (requires ECDSA) and many others. It is really awesome application feature for TPM2. BR, Jarkko
On Thu May 23, 2024 at 6:55 PM EEST, Jarkko Sakkinen wrote: > I was already considering do we need the encoder at all but I think > for dynamic assets like octect strings and variable size integers > it has its place. Obviously is not very mature at this point. Also, I've been opening up discussion of opt-in and *experimental* ASN1_RUST feature. I think it is inevident that it needs to be done at some point because for ASN.1 like format this would have benefits, and also given that it used to process security sensitive data. So metrics for this would something along the lines: - Depending on ASN1_RUST setting, the C API's would be implemented either C or Rust. - OID database could be shared from C-side to Rust simply with bindgen. - C API should be streamline and matured a bit to cover mostly dynamic assets (integers, octect strings and such). Since the number of call sites is small improving should be easy. - After tpm2_key_rsa is landed as it is now as per how buffer processing goes it can be brought to use encoder. - I'd consider have just a single ASN1 flag instead of a separate ASN1_ENCODER flag. It simplifies thing and is not significant cost for vmlinux size so not worth it IMHO. As for sending patches for e.g. improving OID database, I'd like to land the current tpm2_key_rsa first because then in possible OID series that can be also applied to it (and encoder). It does stuff that affects all this work. And as said we need also tpm2_key_ecdsa. Right, there's also https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/ I checked from David that this TPM2 asymmetric key work is relevant for this spec although I readily know some applications for it, and he acknowledged that. I should probably link that to the next version. Asymmetric keys essentially make TPM2 a peer in x.509 ecosystem, which has bunch of especially enterprise and data center type of use cases. I guess this summarizes the big picture. I've been messing around mailing lists and developed these thoughts but this along the lines how I see big picture, including integration to the Rust ecosystem (in non-intrusive way). But yeah, tpm2_key_rsa needs to be the first step. I don't have an employer for kernel development at the moment (probably at some point I do, my contract researcher sabbatical ends at end of Sep) no money to come to the plumbers to discuss about all this at the boot-time security mc so I need to spam my input for that I guess ;-) BR, Jarkko
On Thu, 2024-05-23 at 11:30 -0400, James Bottomley wrote: > On Thu, 2024-05-23 at 16:54 +0300, Jarkko Sakkinen wrote: > > On Thu May 23, 2024 at 4:38 PM EEST, James Bottomley wrote: > > > On Thu, 2024-05-23 at 16:19 +0300, Jarkko Sakkinen wrote: > > > > There's no reason to encode OID_TPMSealedData at run-time, as > > > > it > > > > never changes. > > > > > > > > Replace it with the encoded version, which has exactly the same > > > > size: > > > > > > > > 67 81 05 0A 01 05 > > > > > > > > Include OBJECT IDENTIFIER (0x06) tag and length as the epilogue > > > > so > > > > that the OID can be simply copied to the blob. > > > > > > This is true, but if we're going to do this, we should expand the > > > OID > > > registry functions (in lib/oid_registry.c) to do something like > > > encode_OID. The registry already contains the hex above minus > > > the > > > two > > > prefixes (which are easy to add). > > > > Yes, I do agree with this idea, and I named variable the I named > > it to make it obvious that generation is possible. > > > > It would be best to have a single source, which could be just > > a CSV file with entries like: > > > > <Name>,<OID number> > > > > And then in scripts/ there should be a script that takes this > > source and generates oid_registry.gen.{h,c}. The existing > > oid_registry.h should really just include oid_registry.gen.h > > then to make this transparent change. > > > > And then in the series where OID's are encoded per-subsystem > > patch that takes pre-encoded OID into use. > > > > Happy to review such patch set if it is pushed forward. > > Heh, OK, since I'm the one who thinks it's quite easy, I'll give it a > go. Turns out it's actually really simple. This would go as three patches: adding the feature to lib/oid_registry.c using it in trusted keys and removing the now unused OID encode from lib/asn1_encode.c but I'm attaching here (minus the removal) to give an idea. James --- diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h index 51421fdbb0ba..87a6bcb2f5c0 100644 --- a/include/linux/oid_registry.h +++ b/include/linux/oid_registry.h @@ -151,5 +151,6 @@ extern enum OID look_up_OID(const void *data, size_t datasize); extern int parse_OID(const void *data, size_t datasize, enum OID *oid); extern int sprint_oid(const void *, size_t, char *, size_t); extern int sprint_OID(enum OID, char *, size_t); +extern ssize_t encode_OID(enum OID, u8 *, size_t); #endif /* _LINUX_OID_REGISTRY_H */ diff --git a/lib/oid_registry.c b/lib/oid_registry.c index fe6705cfd780..45f97e1e0f91 100644 --- a/lib/oid_registry.c +++ b/lib/oid_registry.c @@ -12,6 +12,7 @@ #include <linux/errno.h> #include <linux/bug.h> #include <linux/asn1.h> +#include <linux/asn1_ber_bytecode.h> #include "oid_registry_data.c" MODULE_DESCRIPTION("OID Registry"); @@ -196,3 +197,31 @@ int sprint_OID(enum OID oid, char *buffer, size_t bufsize) return ret; } EXPORT_SYMBOL_GPL(sprint_OID); + +/** + * encode_OID - embed an ASN.1 encoded OID in the provide buffer + * @oid: The OID to encode + * @buffer: The buffer to encode to + * @bufsize: the maximum size of the buffer + * + * Returns: negative error or encoded size in the buffer. + */ +ssize_t encode_OID(enum OID oid, u8 *buffer, size_t bufsize) +{ + int oid_size; + + BUG_ON(oid >= OID__NR); + + oid_size = oid_index[oid + 1] - oid_index[oid]; + + if (bufsize < oid_size + 2) + return -EINVAL; + + buffer[0] = _tag(UNIV, PRIM, OID); + buffer[1] = oid_size; + + memcpy(&buffer[2], &oid_data[oid_index[oid]], oid_size); + + return oid_size; +} +EXPORT_SYMBOL_GPL(encode_OID); diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c index 9c7ac2e423d3..b6f34ff0ca5c 100644 --- a/security/keys/trusted-keys/trusted_tpm2.c +++ b/security/keys/trusted-keys/trusted_tpm2.c @@ -19,8 +19,6 @@ #include "tpm2key.asn1.h" #include "tpm2-policy.h" -static u32 tpm2key_oid[] = { 2, 23, 133, 10, 1, 5 }; - static int tpm2_key_encode(struct trusted_key_payload *payload, struct trusted_key_options *options, u8 *src, u32 len) @@ -31,6 +29,7 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, u8 *end_work = scratch + SCRATCH_SIZE; u8 *priv, *pub; u16 priv_len, pub_len; + int ret; priv_len = get_unaligned_be16(src) + 2; priv = src; @@ -43,8 +42,10 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, if (!scratch) return -ENOMEM; - work = asn1_encode_oid(work, end_work, tpm2key_oid, - asn1_oid_len(tpm2key_oid)); + ret = encode_OID(OID_TPMSealedData, work, end_work - work); + if (ret < 0) + return ret; + work += ret; if (options->blobauth_len == 0) { unsigned char bool[3], *w = bool;
On Thu May 23, 2024 at 8:08 PM EEST, James Bottomley wrote: > On Thu, 2024-05-23 at 11:30 -0400, James Bottomley wrote: > > On Thu, 2024-05-23 at 16:54 +0300, Jarkko Sakkinen wrote: > > > On Thu May 23, 2024 at 4:38 PM EEST, James Bottomley wrote: > > > > On Thu, 2024-05-23 at 16:19 +0300, Jarkko Sakkinen wrote: > > > > > There's no reason to encode OID_TPMSealedData at run-time, as > > > > > it > > > > > never changes. > > > > > > > > > > Replace it with the encoded version, which has exactly the same > > > > > size: > > > > > > > > > > 67 81 05 0A 01 05 > > > > > > > > > > Include OBJECT IDENTIFIER (0x06) tag and length as the epilogue > > > > > so > > > > > that the OID can be simply copied to the blob. > > > > > > > > This is true, but if we're going to do this, we should expand the > > > > OID > > > > registry functions (in lib/oid_registry.c) to do something like > > > > encode_OID. The registry already contains the hex above minus > > > > the > > > > two > > > > prefixes (which are easy to add). > > > > > > Yes, I do agree with this idea, and I named variable the I named > > > it to make it obvious that generation is possible. > > > > > > It would be best to have a single source, which could be just > > > a CSV file with entries like: > > > > > > <Name>,<OID number> > > > > > > And then in scripts/ there should be a script that takes this > > > source and generates oid_registry.gen.{h,c}. The existing > > > oid_registry.h should really just include oid_registry.gen.h > > > then to make this transparent change. > > > > > > And then in the series where OID's are encoded per-subsystem > > > patch that takes pre-encoded OID into use. > > > > > > Happy to review such patch set if it is pushed forward. > > > > Heh, OK, since I'm the one who thinks it's quite easy, I'll give it a > > go. > > Turns out it's actually really simple. This would go as three patches: > adding the feature to lib/oid_registry.c using it in trusted keys and > removing the now unused OID encode from lib/asn1_encode.c but I'm > attaching here (minus the removal) to give an idea. This looks pretty good to me at least in this level. I could repeal and replace the patch I did today with this if it plays out well. BR, Jarkko
diff --git a/include/linux/asn1_encoder.h b/include/linux/asn1_encoder.h index 08cd0c2ad34f..afeefdfe2525 100644 --- a/include/linux/asn1_encoder.h +++ b/include/linux/asn1_encoder.h @@ -8,14 +8,10 @@ #include <linux/asn1_ber_bytecode.h> #include <linux/bug.h> -#define asn1_oid_len(oid) (sizeof(oid)/sizeof(u32)) unsigned char * asn1_encode_integer(unsigned char *data, const unsigned char *end_data, s64 integer); unsigned char * -asn1_encode_oid(unsigned char *data, const unsigned char *end_data, - u32 oid[], int oid_len); -unsigned char * asn1_encode_tag(unsigned char *data, const unsigned char *end_data, u32 tag, const unsigned char *string, int len); unsigned char * diff --git a/lib/asn1_encoder.c b/lib/asn1_encoder.c index 0fd3c454a468..c0db3cbebe89 100644 --- a/lib/asn1_encoder.c +++ b/lib/asn1_encoder.c @@ -85,97 +85,6 @@ asn1_encode_integer(unsigned char *data, const unsigned char *end_data, } EXPORT_SYMBOL_GPL(asn1_encode_integer); -/* calculate the base 128 digit values setting the top bit of the first octet */ -static int asn1_encode_oid_digit(unsigned char **_data, int *data_len, u32 oid) -{ - unsigned char *data = *_data; - int start = 7 + 7 + 7 + 7; - int ret = 0; - - if (*data_len < 1) - return -EINVAL; - - /* quick case */ - if (oid == 0) { - *data++ = 0x80; - (*data_len)--; - goto out; - } - - while (oid >> start == 0) - start -= 7; - - while (start > 0 && *data_len > 0) { - u8 byte; - - byte = oid >> start; - oid = oid - (byte << start); - start -= 7; - byte |= 0x80; - *data++ = byte; - (*data_len)--; - } - - if (*data_len > 0) { - *data++ = oid; - (*data_len)--; - } else { - ret = -EINVAL; - } - - out: - *_data = data; - return ret; -} - -/** - * asn1_encode_oid() - encode an oid to ASN.1 - * @data: position to begin encoding at - * @end_data: end of data pointer, points one beyond last usable byte in @data - * @oid: array of oids - * @oid_len: length of oid array - * - * this encodes an OID up to ASN.1 when presented as an array of OID values - */ -unsigned char * -asn1_encode_oid(unsigned char *data, const unsigned char *end_data, - u32 oid[], int oid_len) -{ - int data_len = end_data - data; - unsigned char *d = data + 2; - int i, ret; - - if (WARN(oid_len < 2, "OID must have at least two elements")) - return ERR_PTR(-EINVAL); - - if (WARN(oid_len > 32, "OID is too large")) - return ERR_PTR(-EINVAL); - - if (IS_ERR(data)) - return data; - - - /* need at least 3 bytes for tag, length and OID encoding */ - if (data_len < 3) - return ERR_PTR(-EINVAL); - - data[0] = _tag(UNIV, PRIM, OID); - *d++ = oid[0] * 40 + oid[1]; - - data_len -= 3; - - for (i = 2; i < oid_len; i++) { - ret = asn1_encode_oid_digit(&d, &data_len, oid[i]); - if (ret < 0) - return ERR_PTR(ret); - } - - data[1] = d - data - 2; - - return d; -} -EXPORT_SYMBOL_GPL(asn1_encode_oid); - /** * asn1_encode_length() - encode a length to follow an ASN.1 tag * @data: pointer to encode at diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c index 8b7dd73d94c1..f732e01a9dc6 100644 --- a/security/keys/trusted-keys/trusted_tpm2.c +++ b/security/keys/trusted-keys/trusted_tpm2.c @@ -26,7 +26,8 @@ static struct tpm2_hash tpm2_hash_map[] = { {HASH_ALGO_SM3_256, TPM_ALG_SM3_256}, }; -static u32 tpm2key_oid[] = { 2, 23, 133, 10, 1, 5 }; +/* Encoded OID_TPMSealedData. */ +static u8 OID_TPMSealedData_ASN1[] = {0x06, 0x06, 0x67, 0x81, 0x05, 0x0a, 0x01, 0x05}; static int tpm2_key_encode(struct trusted_key_payload *payload, struct trusted_key_options *options, @@ -51,8 +52,8 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, if (!scratch) return -ENOMEM; - work = asn1_encode_oid(work, end_work, tpm2key_oid, - asn1_oid_len(tpm2key_oid)); + work = memcpy(work, OID_TPMSealedData_ASN1, sizeof(OID_TPMSealedData_ASN1)); + work += sizeof(OID_TPMSealedData_ASN1); if (options->blobauth_len == 0) { unsigned char bool[3], *w = bool; @@ -90,6 +91,9 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, goto err; } + print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE, 16, 1, + payload->blob, work1 - payload->blob, 0); + kfree(scratch); return work1 - payload->blob;
There's no reason to encode OID_TPMSealedData at run-time, as it never changes. Replace it with the encoded version, which has exactly the same size: 67 81 05 0A 01 05 Include OBJECT IDENTIFIER (0x06) tag and length as the epilogue so that the OID can be simply copied to the blob. Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> --- include/linux/asn1_encoder.h | 4 - lib/asn1_encoder.c | 91 ----------------------- security/keys/trusted-keys/trusted_tpm2.c | 10 ++- 3 files changed, 7 insertions(+), 98 deletions(-)