| Newsgroups |
gmane.comp.mozilla.crypto |
| Message-ID |
<[email protected]> |
On 2/18/26 1:04 PM, Andrew Cagney wrote:
> Hi,
>
> Is there a way, similar to how Electric Fence never releases memory,
> to get NSS to never reuse pointers?
> (for the moment I'm going around hobbling free calls such as for symkeys).
>
> We (libreswan) are chasing a potential lock contention problem (for
> instance, NSC_DeriveKey() -> PR_Lock() appears in an off-cpu profile).
> But the water is being muddied by NSS re-using objects and locks so
> we'd like to eliminate that.
>
> Andrew
>
So there are a couple of types of reuse:
1) using the same pointer for the same object, so, for example, when NSS
returns a slot, it returns a reference to that slot, so searches for the
same slot will always return the same pointer. You free your reference
to that slot. This kind of reuse is pretty fundamental in NSS, and you
really can't do anything about it.
2) reusing keys and session objects. After you free a key or session
object, that object is placed on a free list because a number of things
that you create with the object (like the session or the locks), could
be fairly expensive and key creation/destruction can happen quite
frequently. This can of reuse can be capped, though we may need to add
some machinery to allow applications to cap them.
How many freed key structures that are kept around is determined by the
maxKeyCount variable in the slot. Unfortunately we currently have no way
to set it from the application. It's set based on the token's
maxKeySessionCount in it's tokenInfo structure. Typically it's '0',
which sets maxKeyCount to 800. Sounds like you would like a call that
will set that value to 0 for your tests. That will change the timing of
things (since PK11_SymKeyFree() and creating new keys will both take
longer), but it would reduce the noise of reuse... particularly lock reuse.
bob
--
You received this message because you are subscribed to the Google Groups "[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/916a9540-461f-4887-9e0e-fdcc38a45e08%40redhat.com.