Re: use of RDRAND in $random_library
On Wed, 11 Jun 2014, Joey Hess wrote:
> I don't have a stong opinion on the security of RDRAND, which is a
> contentious topic in a domain I am not expert in. However, I would much
> rather rely on linux developers to make the right decision on that,
> rather than libraries deciding on an ad-hoc basis. Especially because
I second that. Previous experience with the "xstore-rng" instruction for
the VIA PadLock on-die HRNG[1] taught me just how dangerous it is dangerous
to call model-specific instructions directly.
Although it is Intel we're talking about here, so you could at least expect
a microcode update to disable RDRAND/RDSEED where broken (it is a known fact
that they can enable or disable it through a microcode update, refer to
errata BV54 for the 3rd gen Intel Core processor, where the microcode update
does the opposite and enables RDRAND).
It would take like 6 months for such a microcode update to show up anywhere,
and the low adoption rates would ensure a lot of boxes would never get the
fix. So it would be up to the kernel to avoid disaster.
Now, the kernel can soft-blacklist RDRAND (and RDSEED) usage[2]. In that
case, the kernel won't use it and it disappears from /proc/cpuinfo, and we
could do that also to avoid processor errata, not just due to user request.
However, AFAIK kernel blacklisting would not cause the instructions to trap
or fail on bare-metal, so userspace could still just use them anyway.
Joey, what does that Haskell lib uses to detect availability of RDRAND?
[1] Due to processor errata, instead of writing the requested number of
bytes, the xstore-rng instruction will write 16 bytes, trashing nearby data.
Known to happen at least to the Via Nano processor.
[2] Add "nordrand" to the kernel command line to soft-blacklist RDRAND. You
cannot blacklist RDSEED on most kernels at this time, the fix was not sent
to -stable (yet).
--
"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: