On 22.11.19 11:42, Herbert Xu wrote: > On Fri, Nov 22, 2019 at 10:54:50AM +0100, Harald Freudenberger wrote: >> The setkey() sets the base key material (usually a secure key) to an >> tfm instance. From this key a 'protected key' (pkey) is derived which >> may get invalid at any time and may need to get re-derived from the >> base key material. >> An tfm instance may be shared, so the context where the pkey is >> stored into is also shared. So when a pkey gets invalid there is a need >> to update the pkey value within the context struct. This update needs >> to be done atomic as another thread may concurrently use this pkey >> value. That's all what this spinlock does. Make sure read and write >> operations on the pkey within the context are atomic. >> It is still possible that two threads copy the pkey, try to use it, find out >> that it is invalid and needs refresh, re-derive and both update the pkey >> memory serialized by the spinlock. But this is no issue. The spinlock >> makes sure the stored pkey is always a consistent pkey (which may >> be valid or invalid but not corrupted). > OK. Can you give me a bit more background info on how often > this is likely to happen? I mean it happened every time you > might as well not store the protected key in the tfm at all. > > Thanks, The pkey is in fact a encrypted key + a verification pattern for the encrypted key used. It gets invalid when this encryption key changes. The encryption key changes when the LPAR is re-activated so for example on suspend/resume or an Linux running as kvm guest gets relocated. So this happens very rarely.
