From owner-freebsd-arch@FreeBSD.ORG Mon Mar 2 17:04:57 2015 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 183827D2 for ; Mon, 2 Mar 2015 17:04:57 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E7AC82F5 for ; Mon, 2 Mar 2015 17:04:56 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t22H4n5g049843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2015 09:04:49 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t22H4m5f049842; Mon, 2 Mar 2015 09:04:48 -0800 (PST) (envelope-from jmg) Date: Mon, 2 Mar 2015 09:04:48 -0800 From: John-Mark Gurney To: Emeric POUPON Subject: Re: locks and kernel randomness... Message-ID: <20150302170448.GN32329@funkthat.com> References: <20150224012026.GY46794@funkthat.com> <1824482166.23183751.1425303073196.JavaMail.zimbra@stormshield.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1824482166.23183751.1425303073196.JavaMail.zimbra@stormshield.eu> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Mon, 02 Mar 2015 09:04:49 -0800 (PST) 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 17:04:57 -0000 Emeric POUPON wrote this message on Mon, Mar 02, 2015 at 14:31 +0100: > 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. Not just that there is a mutex protecting arc4random, but in my tests, rc4 is slower than chacha, and I believe that this is due to the requirement that every byte generated requires multiple reads and multiple writes.. > 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. How so? > 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? I don't see how PCPU rng's could cause a problem... We aren't going to seed the PCPU rng's w/ the same seeding material unless the parent rng (yarrow or fortuna) manages to return the same seed twice in a row, and if that happens, well, you just won the lottery a few million times in the same day.. :) > ----- Mail original ----- > De: "John-Mark Gurney" > À: arch@FreeBSD.org > Envoyé: Mardi 24 Février 2015 02:20:26 > Objet: locks and kernel randomness... > > I'm working on simplifying kernel randomness interfaces. I would like > to get read of all weak random generators, and this means replacing > read_random and random(9) w/ effectively arc4rand(9) (to be replaced > by ChaCha or Keccak in the future). > > The issue is that random(9) is called from any number of contexts, such > as the scheduler. This makes locking a bit more interesting. Currently, > both arc4rand(9) and yarrow/fortuna use a default mtx lock to protect > their state. This obviously isn't compatible w/ the scheduler, and > possibly other calling contexts. > > I have a patch[1] that unifies the random interface. It converts a few > of the locks from mtx default to mtx spin to deal w/ this. > > If/when this is accepted, my next plan is to convert away from arc4rand, > to either ChaCha or Keccak. I already have another patch that converts > arc4rand and friends over to ChaCha. This patch does use PCPU data > and sched_pin to help eliminate locks, but this does need more study. > We could either do a restartable loop (but there might be too much state > to safely do) or a critical section (though running chacha a bunch of > times could have impact). > > [1] https://reviews.freebsd.org/D1956 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."