locks and kernel randomness...

[John-Mark Gurney]

Alfred Perlstein wrote this message on Mon, Mar 02, 2015 at 10:07 -0500:
> On 3/2/15 8:31 AM, Emeric POUPON wrote:
> > About arc4random, we have noticed significant contention in that function on multi CPU systems when ciphering a lot of packets in the IPsec stack.
> > This is indeed due to the mutex that is being used in the arc4rand function.
> >
> > Actually randomness is required by the IV used in the forged output packets.
> > However, making a separate random generator per CPU might be more complicated than expected.
> > The RFC 6027 (http://www.ietf.org/rfc/rfc6027.txt) reminds that the IV must not be repeated :
> > ---
> >   3.7.1. Outbound SAs Using Counter Modes
> >
> >      For SAs involving counter mode ciphers such as Counter Mode (CTR)
> >     ([RFC3686]) or Galois/Counter Mode (GCM) ([RFC4106]) there is yet
> >     another complication. The initial vector for such modes MUST NOT be
> >     repeated, and senders use methods such as counters or linear feedback
> >     shift registers (LFSRs) to ensure this [...]
> > ---
> >
> > What do you think?
> 
> If you can not have multiple random sources then what do you think of 
> having a thread that pre-fetches batches of random values and queues it 
> to each cpu?  If you have the queue be pretty large then you shouldn't 
> bottleneck on it.
> 
> Sort of like UMA for random data.
> 
> Sorry if this is a daft idea, not sure about this code path in general, 
> but this struck me as a potential workaround.

I'd say that's needlessly complex...  You'd still need a lock, or play
w/ the scheduler (sched_bind) to serialize access to the PCPU random
pool...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."