[tor-bugs] #27319 [Core Tor/Tor]: remove buf_get_oldest_chunk_timestamp()

[Tor Bug Tracker & Wiki]

#27319: remove buf_get_oldest_chunk_timestamp()
-------------------------------------+----------------------------------
 Reporter:  cypherpunks3             |          Owner:  (none)
     Type:  defect                   |         Status:  new
 Priority:  Medium                   |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor             |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:  datatypes, buffers, oom  |  Actual Points:
Parent ID:  #23878                   |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+----------------------------------

Comment (by cypherpunks3):

 Replying to [comment:2 nickm]:
 > we need to track the age of the data in the buffer, to implement the
 defense for this: https://www.nrl.navy.mil/itd/chacs/sites/edit-
 www.nrl.navy.mil.itd.chacs/files/pdfs/13-1231-3743.pdf
 >

 Thanks for the additional context.

 Could we

 - replace the per-chunk timestamp with a timestamp stored in `struct
 connection_t`, which is updated with the last point in time that `outbuf`
 had been empty? Move age-calculation logic there.
 - Or if not that, keep a uint32_t field per chunk, but have it be an
 opaque tag kept at zero normally, but callers that care about timestamps
 like connection.c can call `buf_tag_new_chunks(buf_t, uint32_t)` after
 writing to the buffer, assigning that uint32_t to any chunk that currently
 has a tag of zero (ie, any newly created chunks). Then OOM can call
 `buf_get_head_tag()` to retrieve the number and calculate its age.

 Technically, `buf_get_oldest_chunk_timestamp()` is a misnomer anyway,
 since it calculates the age from the timestamp and returns its age in
 seconds, not the timestamp.

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