Date: Mon, 02 Mar 2015 10:07:04 -0500 From: Alfred Perlstein <alfred@freebsd.org> To: Emeric POUPON <emeric.poupon@stormshield.eu>, John-Mark Gurney <jmg@funkthat.com> Cc: arch@FreeBSD.org Subject: Re: locks and kernel randomness... Message-ID: <54F47C98.2080505@freebsd.org> In-Reply-To: <1824482166.23183751.1425303073196.JavaMail.zimbra@stormshield.eu> References: <20150224012026.GY46794@funkthat.com> <1824482166.23183751.1425303073196.JavaMail.zimbra@stormshield.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/2/15 8:31 AM, Emeric POUPON wrote: > Hello, > > 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. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54F47C98.2080505>