[tor-talk] Help testing patch on SandyBridge/IvyBridge? Force disable use of RDRAND in OpenSSL when HardwareAccel is enabled

[coderman]

#include <std_disclaimer.h>

i am not speaking for Tor devs nor Tor project - the cautious should
wait for a review and merge.


On Sat, Dec 14, 2013 at 6:14 AM, coderman <coderman at gmail.com> wrote:
> this is logged as trac ticket:
>   https://trac.torproject.org/projects/tor/ticket/10402
> ...
> help coderman test mitigation patch:
>   https://peertech.org/dist/tor-0.2.4.19-rdrand-disable.patch
>   https://peertech.org/dist/tor-0.2.5.1-rdrand-disable.patch
>   https://peertech.org/dist/tor-latest-rdrand-disable.patch


many thanks to rl1987! the patches have been updated and verified.

anyone running a relay on openssl 1.0.x with HardwareAccel 1 and
seeing this line in their notices.log:
"[notice] Using OpenSSL engine Intel RDRAND engine [rdrand] for RAND"
should** apply the apropos patch above and let me know if it doesn't
work.


a successful mitigation will look like this:
"""
[warn] OpenSSL is using RDRAND by default. Attempting to force disable.
 ...
[notice] Using default implementation for RAND
.
"""


**last but not least, please do run a userspace entropy collector like
haveged, dakarand, etc.  also be sure you're on a recent kernel that
is using RDRAND in a conservative / robust manner.[0]


best regards,



0. "void extract_buf(struct entropy_store *r, __u8 *out)"
  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1038

good use of RDRAND is:
1. mixed into a hash across the pool, not XOR'd against output,
2. mix the mix back into pool (prevent backtrack attacks)
3. atomically extract portion of pool and mix
4. fold final extracted output in half for conservative operation