On Wed, Jun 28, 2017 at 05:08:35PM +0300, Tudor Ambarus wrote: > ecdh_ctx contained static allocated data for the shared secret, > for the public and private key. > > When talking about shared secret and public key, they were > doomed to concurrency issues because they could be shared by > multiple crypto requests. The requests were generating specific > data to the same zone of memory without any protection. > > The private key was subject to concurrency problems because > multiple setkey calls could fight to memcpy to the same zone > of memory. > > Shared secret and public key concurrency is fixed by allocating > memory on heap for each request. In the end, the shared secret > and public key are computed for each request, there is no reason > to use shared memory. > > Private key concurrency is fixed by allocating memory on heap > for each setkey call, by memcopying the parsed/generated private > key to the heap and by making the private key pointer from > ecdh_ctx to point to the newly allocated data. > > On all systems running Linux, loads from and stores to pointers > are atomic, that is, if a store to a pointer occurs at the same > time as a load from that same pointer, the load will return either > the initial value or the value stored, never some bitwise mashup > of the two. > > With this, the private key will always point to a valid key, > but to what setkey call it belongs, is the responsibility of the > caller, as it is now in all crypto framework. I don't get it. You're replacing a per-tfm shared secret with a per-tfm dynamically allocated shared secret. As far as I can see nothing has changed? If the caller is making simultaneous setkey calls on the same tfm, then it's their problem. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
