TPM2 (Trusted Platform Module) userspace development
 help / color / mirror / Atom feed
From: Petr Gotthard <petr.gotthard at centrum.cz>
To: tpm2@lists.01.org
Subject: [tpm2] Re: CMP error: cannot duplicate context:2306 tpm:warn(2.0): out of memory for object contexts
Date: Thu, 14 Oct 2021 18:48:47 +0200	[thread overview]
Message-ID: <20211014184847.7BEC86AB@centrum.cz> (raw)
In-Reply-To: SN6PR11MB3437FA7C3AFE75B0148E66E5B8B69@sn6pr11mb3437.namprd11.prod.outlook.com

[-- Attachment #1: Type: text/plain, Size: 4575 bytes --]

Hi Bill,
 
>> Example 1: OpenSSL often duplicates hash sequences: To hash sequences A,B,C1 and then A,B,C2 they first hash A,B, then duplicate/fork the hash sequence and then complete the hash first for C1 and then for C2. This is a great performance optimization, but when too many dup (forks) are made, the TPM runs out of objects.
  
> Why are we doing hashing with the TPM? If we're in an OpenSSL provider cant we just use software provided hashing routines? I see hashing is configurable, but I would imagine off be default is what you want. Do we use validation tickets or anything like that or just the resulting digest? If all we use are the digests, I would make TPM not hash and make that option a nop.
 
Signing by a restricted signing key requires validation tickets, so the hash must be done by the TPM. The OpenSSL has a combined operation "EVP_DigestSign", which enables the tpm2 provider to hash, obtain the validation ticket and then immediately sign the hash using this ticket. This is beautiful, but it needs the TPM hashing.
 
 
>> Example 2: The CMP key update needs 4 objects to operate (old client key, new client key, server key and hash sequence), but the kernel RM (tpm_space.context_tbl) allows only 3 objects. (If I am right.)
  
 > It does seem that way, but TPM commands only ever need 3 objects alive at once, so that's likely why that was chosen.
 
Yeah, I thought this is so.
 
> Does CMP key really need all 4 of those things in the TPM at once, because currently today that's not actually happening as abrmd is just swapping them in and out.
 
Currently, the tpm2 provider does not do any internal resource management. If someone loads a public / private key, the provider creates a TPM object for this. This key may be used for some later TPM operation or even not used at all, for example when a pubkey is being validated against a privkey. Unfortunately, the provider cannot know in advance if and how the key being loaded will be used.
(The user is free not to use the TPM provider for loading a pubkey, but if it does a TPM object is created.)
 
Typical OpenSSL based implementations are not optimized to reduce the number of concurrently loaded keys. The code often pre-loads all keys and then uses the keys in various operations. Even though a single operation never needs more than 3 objects, the code may prepare more than 3 objects because it is going to invoke more than one operation later.
 
> Also, doesn't CMP use public objects (x509 certs) for some of it?
 
Yes, it does. X.509 certs also include pubkeys and CMP sometimes wants to extract a pubkey from a certificate to match it against a privkey it has. This also consumes two objects (one for the pubkey and one for the privkey) although no TPM operation can be invoked. (But it might be and we don't know, as said above.)
 
> Are public key operations implemented in software? In tpm2-pkcs11 we implement them in software and hash in software and I have yet to have someone hit a limit but perhaps they are all using abrmd but I thought some were using in-kernel RM.
 
Yes. Some public key operations are implemented. Applications can use only one RSA/ECC key management-- if a TPM based RSA (or ECC) key management is loaded in OpenSSL, it will be used for both sign and validate operations-- a typical OpenSSL application cannot say "do privkey in the TPM and pubkey in the default provider"; it can choose only one for both (or create two contexts, but nobody does that). This is OK because TPM can do public key operations too, but it needs more resources if the app pre-loads everything as said above.
 
 
I can see 3 possible solutions how to solve the resource problem:
1) Optimize the code for resource consumption. But then the OpenSSL applications must be TPM aware, which is what I wanted to avoid.
2) Implement some more intelligent resource (less greedy) usage in the tpm2 provider itself. But this feels like re-implementing the RM elsewhere.
3) Rely on the RM (abrmd?) to swap the objects as needed and create the illusion of a much larger object space.
 
Can the abrmd swap resources from a single user? I thought the purpose is to swap resources from multiple connections (users), but in this case there is just one greedy user.
 
The https://github.com/tpm2-software/tpm2-abrmd README.md says: The current implementations are mostly equivalent with a few differences. But if abrmd can swap resources much better than the in-kernel RM, then I wouldn't call them "mostly equivalent".
 
 
Petr

             reply	other threads:[~2021-10-14 16:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14 16:48 Petr Gotthard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-10-15 14:00 [tpm2] Re: CMP error: cannot duplicate context:2306 tpm:warn(2.0): out of memory for object contexts Roberts, William C
2021-10-12 20:09 Roberts, William C
2021-10-08 16:44 Petr Gotthard
2021-10-08 15:45 Roberts, William C
2021-10-06  9:49 Petr Gotthard
2021-10-05 23:08 Chris Newman
2021-10-04  8:18 Chris Newman
2021-10-04  7:31 Petr Gotthard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211014184847.7BEC86AB@centrum.cz \
    --to=tpm2@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox