Date: Mon, 2 Mar 2015 09:04:48 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Emeric POUPON <emeric.poupon@stormshield.eu> Cc: arch@FreeBSD.org Subject: Re: locks and kernel randomness... Message-ID: <20150302170448.GN32329@funkthat.com> 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
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" <jmg@funkthat.com> > À: 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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150302170448.GN32329>