Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
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
Reply to: