greenpillow11[m]: rbrunner: IIRC RR 8149 addressed the multisig issues

I remember.

Ooo is the only one who can answer on the vulnerabilities that still exist

I miss him/her

Everyday

moneromooo Does this commit monero-project/monero #5370/commits/4d29e80aae376e116cecc59c82d7871c9f66ba96#diff-d229136ad349270fc2700a14156517556c003df8494b0233c526046430e57d57 work because copy elision is not done with crypto::secret_key b/c of the non-trivial destructor?

I am not sure. It works because it is using the same local instead of recreating one per loop.

So ctor/dtor don't constantly get called for a new object.

Does that answer your question ?

ohhhhhhhhhhhhhhhhhhhhhh

Yes that answers it. I though for some reason the C++ compiler was calling ctor/dtor before AND after returning the crypto::secret_key from the function

Like 1. ctor/dtor 2. copy value in stack 3. ctor/dtor

Thanks

git grep -E 'secret_key +[a-zA-Z0-9_:]+\('

There's a lot of functions that return secret_keys. Maybe could be a good avenue for similar optimizations

You'll see mlock/munlock in the profile if you find one.

"in the profile"?

I mean the output of, eg, perf top.

Ah gotcha

Now it is too late and wouldn't really be worth the effort, but a custom allocator could have been interesting for this. Call it MlockScrubAllocator. One giant chunk of memory is allocated once with mlock() called once on allocation and munlock() called once on deallocation. Deallocs thru our allocator would scrub the used memory automatically. And crypto::secret_key (or any other type which we want to have these properties) would be

a RAII pointer allocated thru our custom allocator.

jtgrassie:

"greenpillow11[m]: rbrunner: IIRC RR 8149 addressed the multisig issues"

Thanks. Yes, but we *still* label it experimental in the latest release, if I remember correctly? Especially in the CLI wallet