1 |
On Tue, Jul 19, 2016 at 11:23 AM, Andrew Savchenko <bircoph@g.o> |
2 |
wrote: |
3 |
|
4 |
> On Mon, 18 Jul 2016 22:21:22 -0400 waltdnes@××××××××.org wrote: |
5 |
> > On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andrew Savchenko wrote |
6 |
> > > |
7 |
> > > As I wrote earlier in this thread, ntp server is not a guarantee |
8 |
> > > that such problems will not happen. If hardware clocked was |
9 |
> > > significantly offset during boot, it may take several _hours_ for |
10 |
> > > ntp to fix this via clock skew. Apparantly commit may be made |
11 |
> > > during these several hours. |
12 |
> > |
13 |
> > I'm amazed that "robust linux servers" are deathly afraid of simply |
14 |
> > setting the time, and being done with it. And while we're at it, if a |
15 |
> > developer is doing development on a server machine, he may have other |
16 |
> > problems to worry about. At home I occasionally manually run a script |
17 |
> > that includes the 2 lines... |
18 |
> |
19 |
|
20 |
Its actually really typical for programmers to do bad things with time. |
21 |
Some examples include: |
22 |
|
23 |
1) Assuming time is monotonically increasing. |
24 |
2) Assuming time changes at a constant rate. |
25 |
|
26 |
Doing 1 leads to bugs where your local clock is faster than 'real time' and |
27 |
your time sync daemon sets your time to a time in the past. This is a very |
28 |
bad thing for a lot of workloads. Generally callers should use |
29 |
CLOCK_MONOTONIC (or CLOCK_MONOTONIC_RAW) to properly use a clock, but many |
30 |
do not. |
31 |
|
32 |
Doing 2 leads to synchronization issues because you expected APIs like: |
33 |
|
34 |
DoThing() |
35 |
WaitFiveSeconds() # Actually expect 5 seconds to pass here?, haha! |
36 |
DoOtherThing() |
37 |
|
38 |
Of course this is also a bad pattern, but you'd be surprised where you see |
39 |
this crop up. |
40 |
|
41 |
Not to mention other workloads where time is part the security stack |
42 |
(generating randomness, GUIDs, nonces, etc, avoiding replay, etc.) |
43 |
|
44 |
-A |
45 |
|
46 |
|
47 |
> I never said anything about "robust linux servers". If you think |
48 |
> than only servers need a gradual clock slew instead of stepping, |
49 |
> you are mistaken. |
50 |
> |
51 |
> > /usr/bin/sudo /usr/bin/openrdate -n -s ca.pool.ntp.org |
52 |
> > /usr/bin/sudo /sbin/hwclock --systohc |
53 |
> |
54 |
> And if time delta is significant, the system may become broken |
55 |
> this way. Congratulations. |
56 |
> |
57 |
> The gradual NTP time slew was not invented because people were lazy |
58 |
> to run two simple commands. Actually it is just the opposite: |
59 |
> setting system time via a single huge step is much easier to |
60 |
> implement than a proper adjustment via a series of small time slews. |
61 |
> For servers it is indeed important in many ways, including |
62 |
> time stamp based cryptography as kerberos or database integrity. |
63 |
> |
64 |
> But desktops also do need a proper time adjustment: |
65 |
> - Filesystems will not operate correctly with time stamps in |
66 |
> future, in the best keys they will be marked/reported as needed a |
67 |
> repair procedure. |
68 |
> - Cron jobs may go broken too as chithanh mentioned already. |
69 |
> - Video encoding is not happy with time shifts at all. While small |
70 |
> predictable slews can be tolerated, large jumps will just broke the |
71 |
> process. |
72 |
> - System may become *vulnerable* because of time stamp based attack. |
73 |
> Though it is not easy to use such behaviour, it is still possible. |
74 |
> - and many more... |
75 |
> |
76 |
> Best regards, |
77 |
> Andrew Savchenko |
78 |
> |