[tor-bugs] #7419 [Tor]: Choose a faster memwipe implementation

[Tor Bug Tracker & Wiki]

#7419: Choose a faster memwipe implementation
-----------------------------+------------------------------------
     Reporter:  nickm        |      Owner:
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-relay, nickm-patch
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+------------------------------------

Comment (by teor):

 Re: the patch itself - test-memwipe.c

 I think the buffers could all be declared volatile:
 * if char buf[2048] (secret) is declared volatile, this means that the
 compiler cannot predict the value of sum, and therefore isn't allowed to
 precompute it (I can imagine a series of optimisation steps: optimise
 memcpy to static initialisation, optimise sum based on static
 initialisation, notice code similarity and use same value for all three
 sums, avoid compiling most of the program...)
 * if char buf[1024] (check) is declared volatile, it is no longer
 "uninitialised" memory - it is externally modifiable memory, that the
 compiler can never predict the value of.
 * using volatile also avoids all caching of values from these buffers,
 making sure the data is really written to and read from memory, not just
 cached in a large L3 cache somewhere.
 volatile is a way of telling the compiler: "I know what I'm doing here."

 If we were really paranoid, we could test with and without volatile on
 char buf[2048] (secret).

 Also, should we test heap allocations as well as stack allocations?
 They could have very different behaviours, and therefore security
 characteristics.

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