On Sun, 15 Dec 2013, Robert Millan wrote: > > Backporting the fix to these kernels might be a good idea, probably best > > routed through an stable update upload (and not a security upload). > > This might be a bit complicated due to significant changes in internal > APIs. I'm also unsure if the yarrow algorithms used in those versions > are good enough for the task. > > Perhaps we should just disable Via chipset from sys/dev/random/probe.c. > Would this be a terrible loss for a Technology Preview release?
I don't think it would be a terrible loss. OTOH, I wouldn't lose any sleep over a VIA PadLock HRNG driving /dev/random in a tech preview release. I am not sure VIA ever updated the design with CPRNGs, but the original one-HRNG and the following two-HRNG designs are very audit-friendly. Just make sure you give xstore (the new instruction used to read the VIA PadLock HRNG) a full cacheline worth of buffer (which must also be cacheline-aligned), due to CPU errata... you'll get memory corruption of nearby data otherwise. You also have to audit (or otherwise lock down) the HRNG configuration, or assume it is operating in its worst mode while post-processing. The VIA PadLock RNG *is* a single MSR-write away from being misconfigured. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20131216004912.ga7...@khazad-dum.debian.net
