On 14/01/14 22:38, Robert Millan wrote: > On 14/01/2014 22:25, Steven Chamberlain wrote: >> Thankfully wheezy's 9.0 and 8.3 kernels had not enabled >> either of those RNGs yet. > > Are you sure? This is from 9.0:
Ahh, thanks for double-checking this. You're right, kfreebsd-i386 kernels already supported the RNG in VIA Eden 32-bit CPUs... since 5.3. 9.1 merely adds support for the RNG in Via Nano 64-bit CPUs. Actually, it seems I have kfreebsd-i386 9.0 running on a VIA Eden CPU right now with hardware RNG - should be handy for testing: > CPU: VIA Eden Processor 500MHz (498.76-MHz 686-class CPU) > Origin = "CentaurHauls" Id = 0x6d0 Family = 6 Model = d Stepping = 0 > > Features=0xa7c9bbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CLFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE> > Features2=0x4181<SSE3,EST,TM2,xTPR> > AMD Features=0x100000<NX> > VIA Padlock Features=0xffcc<RNG,AES,AES-CTR,SHA1,SHA256,RSA> There was no tunable to control use of this RNG until r240950 (which went into the 9.2 release). The changelog of when it was MFC'd doesn't specifically mention that, but the original commit r240135 does: http://svnweb.freebsd.org/base?view=revision&revision=240135 > Also add the tunables to disable hardware generator > even if detected. We could perhaps backport the tunable, then apply the patch for EN-14:01.random as-is; thus disabling the RNG by default but providing a loader tunable to turn it back on. And there was also this ironic snippet: > From the Intel whitepapers and articles about Bull Mountain, it seems > that we do not need to perform post-processing of RDRAND results, [...] > Intel claims that sanitization is performed in hardware. I've no reason to think VIA / Centaur Technology (Taiwanese owned) were participating in the NSA's project BULLRUN, but it's nice that kfreebsd 10 is taking a cautious approach to all hardware RNGs now. In any case, FreeBSD did an extra step of AES whitening on the output of VIA's RNG - which was a nice precaution, especially in case of a hardware defect - though it is still performed on-chip so can't be 100% trusted. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d5cf86.2060...@pyro.eu.org
