Date: Mon, 2 Mar 2015 14:31:13 +0100 (CET) From: Emeric POUPON <emeric.poupon@stormshield.eu> To: John-Mark Gurney <jmg@funkthat.com> Cc: arch@FreeBSD.org Subject: Re: locks and kernel randomness... Message-ID: <1824482166.23183751.1425303073196.JavaMail.zimbra@stormshield.eu> In-Reply-To: <20150224012026.GY46794@funkthat.com> References: <20150224012026.GY46794@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, About arc4random, we have noticed significant contention in that function o= n multi CPU systems when ciphering a lot of packets in the IPsec stack.=20 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 complicat= ed 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? Emeric Poupon ----- Mail original ----- De: "John-Mark Gurney" <jmg@funkthat.com> =C3=80: arch@FreeBSD.org Envoy=C3=A9: Mardi 24 F=C3=A9vrier 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 --=20 John-Mark Gurney=09=09=09=09Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1824482166.23183751.1425303073196.JavaMail.zimbra>