----- Mail original ----- > De: "Florian Fainelli" <flor...@openwrt.org> > À: "OpenWrt Development List" <openwrt-devel@lists.openwrt.org> > Envoyé: Jeudi 12 Janvier 2012 13:53:47 > Objet: Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package > > Hello, > > On 01/12/12 12:29, Olipro wrote: > > Haveged is an entropy gathering daemon which refills the kernel's entropy > > pool by timing the nanoseconds a CPU takes to complete a loop. The existing > > haveged only supports a few architectures - I have added support for any > > given architecture by utilising the CLOCK_MONOTONIC_RAW introduced in > > kernel 2.6.28 - no doubt this does incur a performance penalty since the > > architecture specific code uses assembler. unfortunately reading r9 from > > cp0 on mips requires the cpu to be in kernel or supervisor mode. > > > > Unlike rng-tools, using haveged ensure the entropy pool is not simply > > refilled from /dev/urandom - thus ensuring that evicted entropy is not > > recycled into the secure pool. > > > > however, I'm not entirely sure what dependencies I should be making this > > rely on to ensure people on say... brcm2.4 don't get it, thus if someone > > could take a look at it, I'd be most appreciative - the package itself > > works just fine, I'm using it on my WNDR3800. > > Though I am not against adding this daemon, rather, I think that we > should make some network drivers interrupts fill the kernel entropy pool > like it used to be, this should solve the entropy problem on most > platforms. > -- > Florian
I was one that try to advocate in 2008 for the non removal of IRQF_SAMPLE_RANDOM. http://marc.info/?l=linux-kernel&m=121096875505040&w=2 This look to be a dead cause. It's true there is some good technical reason why IRQF_SAMPLE_RANDOM may not be a good entropy source. First issue is that with modern drivers, interrupt number decrease when traffic increase (I forgot the technical details but that could be found in the quoted thread). HLFS had another solution than a user-space daemon (everything could help) but not for crypto purpose using frandom kernel module. That create /dev/{e,f}random devices. In case of HLFS, /dev/erandom is plugged to glibc in place of /dev/urandom. http://www.linuxfromscratch.org/hlfs/view/development/chapter08/kernel.html http://www.linuxfromscratch.org/hlfs/view/development/chapter06/glibc.html http://www.billauer.co.il/frandom.html Testing user-space and module solution is still on my todo list. Gilles _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
