From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-76841-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 4C3BA13832E for <garchives@archives.gentoo.org>; Tue, 19 Jul 2016 20:34:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4E47421C084; Tue, 19 Jul 2016 20:34:06 +0000 (UTC) Received: from mail-oi0-f65.google.com (mail-oi0-f65.google.com [209.85.218.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4FCD4E09B2 for <gentoo-dev@lists.gentoo.org>; Tue, 19 Jul 2016 20:34:05 +0000 (UTC) Received: by mail-oi0-f65.google.com with SMTP id d204so2857359oig.3 for <gentoo-dev@lists.gentoo.org>; Tue, 19 Jul 2016 13:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scriptkitty-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=BJNoA2Ony9ZD/7PPO7efRddbGMc3Or6liTrBMgT77m4=; b=Z3awyV33RMWPZotPf/LUwSB+WhfHrD6Q5+7RTNFuaFqbyWjWB1Ej3XhDDHMAsqCcrq vpPbBv6QfagU4g3Us+0HI90sm6Ud5GAYZ6li+yiIm9fvTYYR530g6JK/Z3/S8bivL4EF 2h+j8nWvTO3tFb4HftFVmCw0hs/ANFg82LRyk9klEz/AzdHjUje/0ulCz0kQD6arGRf5 k343b4po1nXk4rkbU44cziQwFOFv+nYOEfUbM/0HXAdMWo9r3SG5aV659xUm1RIGxOTj 7HEzTokmO4rlEJfUIm1DgX92/9cZmfMHm5S24x0M1aPgabxhK531KOMHr1cFDgCcmuNe HyNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=BJNoA2Ony9ZD/7PPO7efRddbGMc3Or6liTrBMgT77m4=; b=ADsaNq5FrrCEwFZw+A0JM9qaWba92Sbo0G3rTIswqKQbpQV3qIMMWJcjMDxnVMuaDE YUQ2v6F828DO9ZQRe47xlg6GbLXvantI1zV8B50WQUwr4SfHvP8Kkm618Bw6FHJpdhaM gBsHVRxxd3YRQniwFUZTkZMfATOwzwXXGIN94U2zRoqOFO8yeCLM6QWTZipPwVKX2ZXG r0uP6AXVJtHWTI0cSi70a4HqUFm9/ThfVl1/IXJw9skswKaTNlUikS5aXpzEIyyc0MRq uvYdCmw02WsVmdxJUT/FGJRPzP8wHgcvYsowLCPhIADJHxCmIrjQHNS6ZJdPFR5CQ6ZM IBKA== X-Gm-Message-State: ALyK8tJvaWIry0rlSnzwa5ql8Ns4TGrcd/acpTWtp8EW1lDu5PlrFGfzqdHreiuA1NwTP2wU8ZFc9fF85uOkrQ== X-Received: by 10.157.19.39 with SMTP id f36mr24198845ote.53.1468960444359; Tue, 19 Jul 2016 13:34:04 -0700 (PDT) Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Sender: antarus@scriptkitty.com Received: by 10.182.131.65 with HTTP; Tue, 19 Jul 2016 13:34:03 -0700 (PDT) X-Originating-IP: [2620:0:1000:3011:382a:7606:d62e:d9ab] In-Reply-To: <20160719212316.238d624977400260bc31b86d@gentoo.org> References: <robbat2-20160715T174905-986981250Z@orbis-terrarum.net> <20160716123309.940bdcbcb2c28d0aa26aa730@gentoo.org> <CAHgY3qe-ztXuLJ9h3nyzLY2uH1Mf7zCzgZQj3_uRvEcni5i4WQ@mail.gmail.com> <20160718200335.ukkvr5l42uzqv2hr@schiffbauer.net> <20160718232709.7756942377a33c34ce488d87@gentoo.org> <20160719022122.GA26527@waltdnes.org> <20160719212316.238d624977400260bc31b86d@gentoo.org> From: Alec Warner <antarus@gentoo.org> Date: Tue, 19 Jul 2016 13:34:03 -0700 X-Google-Sender-Auth: F_p-5GYLXnJGXJZ03pvfJPmWUoU Message-ID: <CAAr7Pr8FE6GgSOoznnONJA_Y7p4wnj69eTe-SfZuYW-vHPumqQ@mail.gmail.com> Subject: Re: [gentoo-dev] Signed push & clock drift rejection To: Gentoo Dev <gentoo-dev@lists.gentoo.org> Content-Type: multipart/alternative; boundary=001a113cfd8a79bb340538030111 X-Archives-Salt: ed503a5d-716c-4f9e-a687-b7d9550b637c X-Archives-Hash: 5af50c47e10f85207747fa7df8bd089a --001a113cfd8a79bb340538030111 Content-Type: text/plain; charset=UTF-8 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 > --001a113cfd8a79bb340538030111 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Tue, Jul 19, 2016 at 11:23 AM, Andrew Savchenko <span dir=3D"ltr">&l= t;<a href=3D"mailto:bircoph@gentoo.org" target=3D"_blank">bircoph@gentoo.or= g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">= On Mon, 18 Jul 2016 22:21:22 -0400 <a href=3D"mailto:waltdnes@waltdnes.org"= >waltdnes@waltdnes.org</a> wrote:<br> </span><span class=3D"">> On Mon, Jul 18, 2016 at 11:27:09PM +0300, Andr= ew 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> >=C2=A0 =C2=A0I'm amazed that "robust linux servers" are d= eathly afraid of simply<br> > setting the time, and being done with it. And while we're at it, i= f a<br> > developer is doing development on a server machine, he may have other<= br> > problems to worry about.=C2=A0 At home I occasionally manually run a s= cript<br> > that includes the 2 lines...<br></span></blockquote><div><br></div><di= v>Its actually really typical for programmers to do bad things with time. S= ome examples include:</div><div><br></div><div>1) Assuming time is monotoni= cally increasing.</div><div>2) Assuming time changes at a constant rate.</d= iv><div><br></div><div>Doing 1 leads to bugs where your local clock is fast= er than 'real time' and your time sync daemon sets your time to a t= ime 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 us= e a clock, but many do not.</div><div><br></div><div>Doing 2 leads to synch= ronization issues because you expected APIs like:</div><div><br></div><div>= DoThing()</div><div>WaitFiveSeconds() # Actually expect 5 seconds to pass h= ere?, haha!</div><div>DoOtherThing()</div><div><br></div><div>Of course thi= s 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, avoidin= g replay, etc.)</div><div><br></div><div>-A</div><div><br></div><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"><span class=3D""> <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=3D""><br> > /usr/bin/sudo /usr/bin/openrdate -n -s <a href=3D"http://ca.pool.ntp.o= rg" rel=3D"noreferrer" target=3D"_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> --001a113cfd8a79bb340538030111--