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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140613134310.gc30...@khazad-dum.debian.net