[tor-bugs] #13696 [Tor]: Use syscall-based entropy reading where possible.

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Nov 26 16:57:27 UTC 2015


#13696: Use syscall-based entropy reading where possible.
-------------------------+--------------------------------
 Reporter:  nickm        |          Owner:  yawning
     Type:  enhancement  |         Status:  needs_revision
 Priority:  Medium       |      Milestone:  Tor: 0.2.???
Component:  Tor          |        Version:
 Severity:  Normal       |     Resolution:
 Keywords:  tor-relay    |  Actual Points:
Parent ID:               |         Points:
  Sponsor:               |
-------------------------+--------------------------------

Comment (by yawning):

 Replying to [comment:6 nickm]:
 >  * Have any other bsds grabbed getentropy() ?  Possibly we should check
 for it with autoconf rather than with #if directives.

 Done.

 >  * A part of me says that it would be smart to 0-fill the buffer before
 we call these functions, and then verify that they actually filled the
 buffer with something other than 0s. (Assuming that the buffer is of
 sufficient size)

 Done.  Opted to check if the buffer is still all zero for requests that
 are >= 128 bits, with 3 retries.  If teor or somebody write a better light
 weight statistical test we could use that since this shouldn't be critical
 path.

 >  * Maybe a comment should document what the 0 flags mean here.

 Done.

 >  * I don't think that a warn should be necessary if getrandom() returns
 ENOSYS.

 It only warns once, and I think it's a useful warning to have.  If people
 the binary with old kernel headers, the code won't get compiled in, and
 will never warn.  If people build the binary against kernel headers that
 don't match the actual running kernel, that's a problem.  I don't have
 extremely strong feelings about this though.

 >  * If we're doing `tor_assert(ret == (int)out_len);`, should we check
 for out_len rather than -1 in the loop?

 Hm.  Matter of taste?  The only time the assert will trigger is if the
 kernel people break userland, so I think it's an invariant.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13696#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list