From owner-freebsd-arch@FreeBSD.ORG Mon Mar 2 15:03:22 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A60893C for ; Mon, 2 Mar 2015 15:03:22 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 667FD311 for ; Mon, 2 Mar 2015 15:03:22 +0000 (UTC) Received: from AlfredMacbookAir.local (hudsonhotel209.h.subnet.rcn.com [207.237.151.136]) by elvis.mu.org (Postfix) with ESMTPSA id BBE71341F90D; Mon, 2 Mar 2015 07:03:19 -0800 (PST) Message-ID: <54F47C98.2080505@freebsd.org> Date: Mon, 02 Mar 2015 10:07:04 -0500 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Emeric POUPON , John-Mark Gurney Subject: Re: locks and kernel randomness... References: <20150224012026.GY46794@funkthat.com> <1824482166.23183751.1425303073196.JavaMail.zimbra@stormshield.eu> In-Reply-To: <1824482166.23183751.1425303073196.JavaMail.zimbra@stormshield.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 15:03:22 -0000 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