[prev in list] [next in list] [prev in thread] [next in thread]
List: gentoo-dev
Subject: Re: [gentoo-dev] Signed push & clock drift rejection
From: Alec Warner <antarus () gentoo ! org>
Date: 2016-07-19 20:34:03
Message-ID: CAAr7Pr8FE6GgSOoznnONJA_Y7p4wnj69eTe-SfZuYW-vHPumqQ () mail ! gmail ! com
[Download RAW message or body]
On Tue, Jul 19, 2016 at 11:23 AM, Andrew Savchenko <bircoph@gentoo.org>
wrote:
> On Mon, 18 Jul 2016 22:21:22 -0400 waltdnes@waltdnes.org wrote:
> > On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote
> > >
> > > As I wrote earlier in this thread, ntp server is not a guarantee
> > > that such problems will not happen. If hardware clocked was
> > > significantly offset during boot, it may take several _hours_ for
> > > ntp to fix this via clock skew. Apparantly commit may be made
> > > during these several hours.
> >
> > I'm amazed that "robust linux servers" are deathly afraid of simply
> > setting the time, and being done with it. And while we're at it, if a
> > developer is doing development on a server machine, he may have other
> > problems to worry about. At home I occasionally manually run a script
> > that includes the 2 lines...
>
Its actually really typical for programmers to do bad things with time.
Some examples include:
1) Assuming time is monotonically increasing.
2) Assuming time changes at a constant rate.
Doing 1 leads to bugs where your local clock is faster than 'real time' and
your time sync daemon sets your time to a time in the past. This is a very
bad thing for a lot of workloads. Generally callers should use
CLOCK_MONOTONIC (or CLOCK_MONOTONIC_RAW) to properly use a clock, but many
do not.
Doing 2 leads to synchronization issues because you expected APIs like:
DoThing()
WaitFiveSeconds() # Actually expect 5 seconds to pass here?, haha!
DoOtherThing()
Of course this is also a bad pattern, but you'd be surprised where you see
this crop up.
Not to mention other workloads where time is part the security stack
(generating randomness, GUIDs, nonces, etc, avoiding replay, etc.)
-A
> I never said anything about "robust linux servers". If you think
> than only servers need a gradual clock slew instead of stepping,
> you are mistaken.
>
> > /usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org
> > /usr/bin/sudo /sbin/hwclock --systohc
>
> And if time delta is significant, the system may become broken
> this way. Congratulations.
>
> The gradual NTP time slew was not invented because people were lazy
> to run two simple commands. Actually it is just the opposite:
> setting system time via a single huge step is much easier to
> implement than a proper adjustment via a series of small time slews.
> For servers it is indeed important in many ways, including
> time stamp based cryptography as kerberos or database integrity.
>
> But desktops also do need a proper time adjustment:
> - Filesystems will not operate correctly with time stamps in
> future, in the best keys they will be marked/reported as needed a
> repair procedure.
> - Cron jobs may go broken too as chithanh mentioned already.
> - Video encoding is not happy with time shifts at all. While small
> predictable slews can be tolerated, large jumps will just broke the
> process.
> - System may become *vulnerable* because of time stamp based attack.
> Though it is not easy to use such behaviour, it is still possible.
> - and many more...
>
> Best regards,
> Andrew Savchenko
>
[Attachment #3 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul \
19, 2016 at 11:23 AM, Andrew Savchenko <span dir="ltr"><<a \
href="mailto:bircoph@gentoo.org" target="_blank">bircoph@gentoo.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><span class="">On Mon, 18 Jul 2016 22:21:22 -0400 <a \
href="mailto:waltdnes@waltdnes.org">waltdnes@waltdnes.org</a> wrote:<br> </span><span \
class="">> On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote<br> \
> ><br> > > As I wrote earlier in this thread, ntp server is not a \
guarantee<br> > > that such problems will not happen. If hardware clocked \
was<br> > > significantly offset during boot, it may take several _hours_ \
for<br> > > ntp to fix this via clock skew. Apparantly commit may be made<br>
> > during these several hours.<br>
><br>
> I'm amazed that "robust linux servers" are deathly afraid of \
simply<br> > setting the time, and being done with it. And while we're at it, \
if a<br> > developer is doing development on a server machine, he may have \
other<br> > problems to worry about. At home I occasionally manually run a \
script<br> > that includes the 2 \
lines...<br></span></blockquote><div><br></div><div>Its actually really typical for \
programmers to do bad things with time. Some examples \
include:</div><div><br></div><div>1) Assuming time is monotonically \
increasing.</div><div>2) Assuming time changes at a constant \
rate.</div><div><br></div><div>Doing 1 leads to bugs where your local clock is faster \
than 'real time' and your time sync daemon sets your time to a time in the \
past. This is a very bad thing for a lot of workloads. Generally callers should use \
CLOCK_MONOTONIC (or CLOCK_MONOTONIC_RAW) to properly use a clock, but many do \
not.</div><div><br></div><div>Doing 2 leads to synchronization issues because you \
expected APIs like:</div><div><br></div><div>DoThing()</div><div>WaitFiveSeconds() # \
Actually expect 5 seconds to pass here?, \
haha!</div><div>DoOtherThing()</div><div><br></div><div>Of course this is also a bad \
pattern, but you'd be surprised where you see this crop \
up.</div><div><br></div><div>Not to mention other workloads where time is part the \
security stack (generating randomness, GUIDs, nonces, etc, avoiding replay, \
etc.)</div><div><br></div><div>-A</div><div><br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""> \
<br> </span>I never said anything about "robust linux servers". If you \
think<br> than only servers need a gradual clock slew instead of stepping,<br>
you are mistaken.<br>
<span class=""><br>
> /usr/bin/sudo /usr/bin/openrdate -n -s <a href="http://ca.pool.ntp.org" \
rel="noreferrer" target="_blank">ca.pool.ntp.org</a><br> > /usr/bin/sudo \
/sbin/hwclock --systohc<br> <br>
</span>And if time delta is significant, the system may become broken<br>
this way. Congratulations.<br>
<br>
The gradual NTP time slew was not invented because people were lazy<br>
to run two simple commands. Actually it is just the opposite:<br>
setting system time via a single huge step is much easier to<br>
implement than a proper adjustment via a series of small time slews.<br>
For servers it is indeed important in many ways, including<br>
time stamp based cryptography as kerberos or database integrity.<br>
<br>
But desktops also do need a proper time adjustment:<br>
- Filesystems will not operate correctly with time stamps in<br>
future, in the best keys they will be marked/reported as needed a<br>
repair procedure.<br>
- Cron jobs may go broken too as chithanh mentioned already.<br>
- Video encoding is not happy with time shifts at all. While small<br>
predictable slews can be tolerated, large jumps will just broke the<br>
process.<br>
- System may become *vulnerable* because of time stamp based attack.<br>
Though it is not easy to use such behaviour, it is still possible.<br>
- and many more...<br>
<br>
Best regards,<br>
Andrew Savchenko<br>
</blockquote></div><br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic