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

[coderman]

On Wed, Dec 18, 2013 at 9:03 AM, Nick Mathewson <nickm at alum.mit.edu> wrote:
> On Sat, Dec 14, 2013 at 9:14 AM, coderman <coderman at gmail.com> wrote:
>> this is logged as trac ticket:
>>   https://trac.torproject.org/projects/tor/ticket/10402
>
> I'm fairly sure that patch doesn't actually do anything; see comments
> on #10402 (URL above) for my investigation.
>
> Lessons I learned: Do not assume that you have really replaced an
> undesirable function until you've investigated with a debugger.  Do
> not assume you were using the undesirable function in the first place
> until you've investigated with a debugger.  Above all, do not assume
> that you understand how OpenSSL works until you have investigated with
> a debugger, the source code, and a pot of coffee.

thanks Nick!  i have been poking at a "badengine" version of the
rdrand module since you asked for a trace two days ago.
(also to be able to confirm/deny the environment variable CPU flag
tricks works as other option)

i also appreciate the explanation of where first call for entropy is
encountered in circuit builds, which is another scenario i didn't
anticipate.



> There is a probably fixed patch ready for testing at that URL that
> should apply cleanly to 0.2.4. I've made a quick and dirty 0.2.5
> version for people to use as well, if they like.
>
> These could use review and testing, of course.  Comments at the above
> URL if possible please.

i don't know when OpenSSL expects to deliver an update; this is really
the best fix.

this code could also use some cleanup for newer versions, which i'll
keep as a separate patch. (e.g. ENGINE_register_all_complete() is
called by ENGINE_load_builtin_engines() in later revisions, and no
longer needed in Tor's engine setup)

thanks again, and lesson learned :)


best regards,