Do not refresh object store before fetching object.

[larssilven]

Before this commit the object store for a file token was always refreshed by reading
the file of the token every time an object of the token was fetched.
Now the HSM may be configured not to refresh when fetching an object. But the
refresh will still be done after an application gets a handle for an object.

The reason for this change is that the CPU time consumed by the reading may not
be negligible for some HW.

[rijswijk]

Thanks for your PR; the reason it is implemented the way it currently is is to cope with multiple independent processes concurrently manipulating the same token through the SoftHSM library. If you disable the check, then a process will fail to pick up any changes to the token made by an external process. I understand that for performance reasons this is inconvenient, but perhaps it would be better, if you want to be able to disable it, to make this a configurable feature?

I'm wondering, though, if that should then be run-time configurable or compile-time (since you might not want two processes using SoftHSM with conflicting configurations). I'd like to ask @halderen for an opinion on this too.

[halderen]

It is really needed that multiple concurrent processes access the same token at the same time for many use cases. I'd first like to know the performance impact of such a thing. SoftHSMv2 isn't really that fast anyway (for security reasons) so if the effect isn't good for me. Not having the lock (so this PR) means bringing back the old SoftHSMv1 functionality and the way SoftHSMv2 sometimes operate due to a bug. This took us with OpenDNSSEC 2 1/2 years to find, so I'd rather not burn application programmers with this. In any case, this should not be a compile time option, as this would mean package maintainers may select this, and then everyone may be stuck with this. It should be a run-time, per slot/token option (but that might not be possible) option that is not default on.

[larssilven]

I'm glad that you are willing to accept my proposal with the modification that the 'refresh disabling' should be optional and disabled by default.

Could we add a key called objectstore.readrefresh to the softhsm2.conf . If this key has the value 'false' then no refreshing is done before fetching an object from the store, if something else or not define then the refresh is done (as before).

I have just tested this with the file mode. Maybe nothing should be done about the DB mode (I removed a mutex lock)?

I believe it should be possible in 'file mode' for several processes to use the same objects in a store with 'objectstore.readrefresh=false'. There will just be a problem if one of the processes use C_DestroyObject or C_SetAttribute;
then the other processes will continue to used the object as it was before.

[larssilven]

New version ready for review.

[larssilven]

Benchmarks

I have compared result from a Debian VM running the p11speed test with different configurations. p11speed has used 24 threads each doing 1000 signings with 2048 RSA_PKCS.
It has been done on 2 different kind of storage, ordinary VM qcow2 and 9p that access a storage on the hypervisor. Here is the result:

storage type	objectstore.readrefresh	objectstore.backend	signes/s
9p	true	file	386
9p	true	db	1275
9p	false	file	2393
9p	false	db	1263
qcow2	true	file	2534
qcow2	true	db	2170
qcow2	false	file	2379
qcow2	false	db	2163

I will remove my DB fix since it is not doing any difference.

[jschlyter]

Please rebase on develop and mark as ready when ready.

[larssilven]

Now all tests but windows are OK. But I don't think these problem has anything to do with this.

[larssilven]

how stupid of me. I did just assume the the windows build was not ready yet.
Thanks @bjosv