On 18 October 2016 at 15:24, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote: >> >> > Hmm. Is it really worth having a per-CPU variable for each possible >> > key? You could have a large number of those (typically three when >> > you're a client on an AP, and 1 + 1 for each client when you're the >> > AP). > > 2 + 1 for each client, actually, since you have 2 GTKs present in the > "steady state"; not a big difference though. > >> > Would it be so bad to have to set the TFM every time (if that's >> > even possible), and just have a single per-CPU cache? > >> That would be preferred, yes. The only snag here is that >> crypto_alloc_aead() is not guaranteed to return the same algo every >> time, which means the request size is not guaranteed to be the same >> either. This is a rare corner case, of course, but it needs to be >> dealt with regardless > > Ah, good point. Well I guess you could allocate a bigger one it if it's > too small, but then we'd have to recalculate the size all the time > (which we already did anyway, but saving something else would be good). > Then we'd be close to just having a per-CPU memory block cache though. > Well, ideally we'd allocate the ccm(aes) crypto_alg a single time and 'spawn' the transforms for each key. This is how the crypto API implements templates internally, but I don't think this functionality is publicly accessible. Herbert?
