[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs