Sorry maybe I missed one thing. So you're saying that there's no
daemon in the background that keeps adjusting the clock? It only
adjusts once? If that's the case, then yes it does increase
monotonically, though it you wouldn't be able to leave it on for
long...
But yeah, I think the other points are valid, except maybe the way the
clocks speeds up or slows down. It may not be as simple as speeding up
or slowing down the CPU. Maybe just the number of cpu cycles that
count as one second are adjusted. I don't know, I'm not a clock expert
:)
On Mon, Jun 2, 2014 at 2:34 AM, AK <akarmn@???> wrote:
> On Mon, Jun 2, 2014 at 2:18 AM, intrigeri <intrigeri@???> wrote:
>> Hi,
>>
>> AK wrote (01 Jun 2014 22:22:45 GMT) :
>>> I just did some quick research on my it's important to have a clock
>>> that doesn't go backwards in time (the monotonic requirement). Other
>>> than the fact that the C version of htpdate requires this with its
>>> "adjust" feature (gave example about databases) and NTP has this in
>>> its design as well, I found a paper by David Mills (inventor of NTP)
>>> [1] that talks about the monotonic requirement. However, I couldn't
>>> see a good explanation as to why it's important. So I looked some more
>>> and found one concrete example [2] of a software system that does rely
>>> on the monotonic requirement. I know there should be more evidence,
>>> and I will look, but I think it's always a good security/correctness
>>> practice to have a monotonically increasing clock.
>>
>>> [1] http://www.eecis.udel.edu/~mills/database/reports/time/timeb.pdf
>>> [2] https://www.unidata.ucar.edu/software/ldm/ldm-current/basics/platform.html
>>
>> I agree in general.
>>
>> Time sync'ing is run as part of the system initialization in Tails,
>> not as a continuous process. So, once the system is fully connected to
>> Tor and the time has been sync'd (which is what matters), time does
>> increase monotonically.
>>
>> Also, we're setting the time to UTC, so most systems will have their
>> clock changed abruptly anyway, and if something breaks due to this,
>> well, it breaks and likely we'll notice. So I don't see why we should
>> introduce more complexity, just for the sake of adjusting the clock
>> more smoothly in case it's not that far from the current correct
>> UTC one. Did I miss anything?
>>
>> Cheers,
>> --
>> intrigeri
>> | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
>> | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
>
> I don't think it will always increase monotonically even after the
> initial sync. If the frequency of the cpu gets too fast, then the
> clock will be ahead, so it will be set backwards (or if the HTTPS
> servers are giving slightly early time). The adjtime() [1] call
> ensures that the time increases monotically by either temporarily
> increasing the CPU frequency to move it faster or decreasing it to
> move it slower and let the real time catch up (from what I
> understand).
>
> I think typically the hardware clock of a computer is set to be close
> to UTC time. Then when the OS boots, it uses the hardware clock to set
> the software clock (which may be adjusted), and then whent it shuts
> down, the hardware clock is set to the software clock. So if you this
> set up, you can do an initial jump to set a Tails' user's clock if
> it's needed, and then they can restart and be sure that everything
> started and is still running with a smooth, monotonic clock. Just
> giving suggestions. My main point was just to ask if there's something
> wrong with the C version of htpdate, but unless someone tells me a
> good reason why not to use it, then I will just go ahead and use it.
> And maybe in the future you will find it useful.
>
> [1] linux.die.net/man/3/adjtime
