[tor-bugs] #27741 [Core Tor/Tor]: too many arguments in rust protover_compute_vote()

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Sep 19 23:46:46 UTC 2018


#27741: too many arguments in rust protover_compute_vote()
-------------------------------------------------+-------------------------
 Reporter:  cyberpunks                           |          Owner:  nickm
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.5.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.3.6
 Severity:  Normal                               |     Resolution:
 Keywords:  035-must, protover, memory-safety,   |  Actual Points:
  033-backport, 034-backport                     |
Parent ID:  #27739                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:10 cyberpunks]:
 > Replying to [comment:9 teor]:
 > > * C to Rust unit tests (maybe depends on #25386?), if the values in
 the uninitialised register weren't always zero, or if the architecture
 poisons uninitialised registers
 >
 > We already have C unit tests for this function and they run against the
 Rust implementation in CI, don't they?

 We do, so:
 * the architectures we're running on don't poison uninitialised registers,
 and
 * either the value in the uninitialised register is always the same, or
 the unit test results don't change based on that value.

 > > * fuzzing C against Rust (#27229), if the values in the uninitialised
 register weren't always zero, or if the architecture poisons uninitialised
 registers
 >
 > Wouldn't the C fuzzing code need to know about the 3rd argument in order
 to fuzz it, and not knowing it's in the Rust version of the function
 signature is the problem?

 No, not necessarily: if the value of the 3rd argument changes arbitrarily,
 a fuzzer would identify differences between the Rust and C implementation.

 > But wait, [https://github.com/google/sanitizers/wiki/MemorySanitizer
 MSan] could probably catch this use of an uninitialized value.

 I think I tried MSan once. We would probably take a patch to add MSan as
 an option to configure.

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


More information about the tor-bugs mailing list