Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Mar 2015 09:10:26 -0800
From:      John-Mark Gurney <jmg@funkthat.com>
To:        Alfred Perlstein <alfred@freebsd.org>
Cc:        Emeric POUPON <emeric.poupon@stormshield.eu>, arch@freebsd.org
Subject:   Re: locks and kernel randomness...
Message-ID:  <20150302171025.GO32329@funkthat.com>
In-Reply-To: <54F47C98.2080505@freebsd.org>
References:  <20150224012026.GY46794@funkthat.com> <1824482166.23183751.1425303073196.JavaMail.zimbra@stormshield.eu> <54F47C98.2080505@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150302171025.GO32329>