| Message ID | 20200922004005.10268-1-themiron@yandex-team.ru |
|---|---|
| State | Superseded |
| Headers |
Return-Path: <openvpn-devel-bounces@lists.sourceforge.net> Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director10.mail.ord1d.rsapps.net ([172.31.255.6]) by backend30.mail.ord1d.rsapps.net with LMTP id GFLSJ0tIaV8QXQAAIUCqbw (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) for <patchwork@openvpn.net>; Mon, 21 Sep 2020 20:41:47 -0400 Received: from proxy18.mail.iad3b.rsapps.net ([172.31.255.6]) by director10.mail.ord1d.rsapps.net with LMTP id 4NSbJ0tIaV9CWQAApN4f7A (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) for <patchwork@openvpn.net>; Mon, 21 Sep 2020 20:41:47 -0400 Received: from smtp23.gate.iad3b ([172.31.255.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy18.mail.iad3b.rsapps.net with LMTPS id ON8wIUtIaV9jZgAA3NpJmQ (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) for <patchwork@openvpn.net>; Mon, 21 Sep 2020 20:41:47 -0400 X-Spam-Threshold: 95 X-Spam-Score: 0 X-Spam-Flag: NO X-Virus-Scanned: OK X-Orig-To: openvpnslackdevel@openvpn.net X-Originating-Ip: [216.105.38.7] Authentication-Results: smtp23.gate.iad3b.rsapps.net; iprev=pass policy.iprev="216.105.38.7"; spf=pass smtp.mailfrom="openvpn-devel-bounces@lists.sourceforge.net" smtp.helo="lists.sourceforge.net"; dkim=fail (signature verification failed) header.d=sourceforge.net; dkim=fail (signature verification failed) header.d=sf.net; dkim=fail (signature verification failed) header.d=yandex-team.ru; dmarc=fail (p=none; dis=none) header.from=yandex-team.ru X-Suspicious-Flag: YES X-Classification-ID: 648fcb36-fc6c-11ea-bd89-525400aa5716-1-1 Received: from [216.105.38.7] ([216.105.38.7:44646] helo=lists.sourceforge.net) by smtp23.gate.iad3b.rsapps.net (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id 99/C7-02158-A48496F5; Mon, 21 Sep 2020 20:41:46 -0400 Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) id 1kKWMC-0003WA-BU; Tue, 22 Sep 2020 00:40:32 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <themiron@yandex-team.ru>) id 1kKWM8-0003Vd-3N for openvpn-devel@lists.sourceforge.net; Tue, 22 Sep 2020 00:40:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Message-Id:Date:Subject:To:From:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lxccLRQT9/naCtZuHD1tNHh40YVBV1Nuvs8c9Tksszo=; b=EM2QyoZE8KnanC1QMjAXDYolb8 x+dhzpdAqKCb56umFlN9nYiNFwDthHoxDryvH7MpPAjQRlbCBPlKYxuq8sT7HIeywLiKG55XqrWRo mrw7S+jWfGLgFerLdOwPGxwkaJU9rDjK81p+Iz7H4d4fHk4vy3j47JV1nuBWhW+y66/c=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Message-Id:Date:Subject:To:From:Sender:Reply-To:Cc:MIME-Version: Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lxccLRQT9/naCtZuHD1tNHh40YVBV1Nuvs8c9Tksszo=; b=cbXfiT5u4zvmGJA7qUEkrfWh5n bnCc7GKu2h+SEtUdAuYYq7sfCIhPNyTJTzvlwXn+NasT33j4XeWpYvOvjvFhxURcsZ3srIkz3v/z3 nGGmIx0BKDSiTk5s34fyphR9j4vUm8e99Ej9M7JJMFVmr3/iG7ERXr78gvsAwsBU/GTI=; Received: from forwardcorp1o.mail.yandex.net ([95.108.205.193]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1kKWLx-002bK7-6g for openvpn-devel@lists.sourceforge.net; Tue, 22 Sep 2020 00:40:27 +0000 Received: from iva8-d077482f1536.qloud-c.yandex.net (iva8-d077482f1536.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:2f26:0:640:d077:482f]) by forwardcorp1o.mail.yandex.net (Yandex) with ESMTP id E0ADA2E1551 for <openvpn-devel@lists.sourceforge.net>; Tue, 22 Sep 2020 03:40:09 +0300 (MSK) Received: from iva8-88b7aa9dc799.qloud-c.yandex.net (iva8-88b7aa9dc799.qloud-c.yandex.net [2a02:6b8:c0c:77a0:0:640:88b7:aa9d]) by iva8-d077482f1536.qloud-c.yandex.net (mxbackcorp/Yandex) with ESMTP id jwMlyFg3NK-e9vigcp1; Tue, 22 Sep 2020 03:40:09 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1600735209; bh=lxccLRQT9/naCtZuHD1tNHh40YVBV1Nuvs8c9Tksszo=; h=Message-Id:Date:Subject:To:From; b=R351neh9R/Z6T8wj8F44VNbZZB0FJVzo2arhNypaPuXvoF+4eFg3wRwu7gTGUJrkF YsSxCgIzUlv9310jAas8JsdaMgkJnS/fXhA2vrbqA44DcRvSqeSFL/1aSWA/HciakQ 2x9ODw+sXhme0lckhG+A0xY8bKRuInoMPYlwPTQA= Received: from 37.9.85.33-iva.dhcp.yndx.net (37.9.85.33-iva.dhcp.yndx.net [37.9.85.33]) by iva8-88b7aa9dc799.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id eBgQQ5S47x-e9nS2wcE; Tue, 22 Sep 2020 03:40:09 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) From: Vladislav Grishenko <themiron@yandex-team.ru> To: openvpn-devel@lists.sourceforge.net Date: Tue, 22 Sep 2020 05:40:05 +0500 Message-Id: <20200922004005.10268-1-themiron@yandex-team.ru> X-Mailer: git-send-email 2.17.1 X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: yandex-team.ru] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-Headers-End: 1kKWLx-002bK7-6g Subject: [Openvpn-devel] [PATCH] Fix update_time() and openvpn_gettimeofday() X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: <openvpn-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/options/openvpn-devel>, <mailto:openvpn-devel-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=openvpn-devel> List-Post: <mailto:openvpn-devel@lists.sourceforge.net> List-Help: <mailto:openvpn-devel-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/openvpn-devel>, <mailto:openvpn-devel-request@lists.sourceforge.net?subject=subscribe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-getmail-retrieved-from-mailbox: Inbox |
| Series |
[Openvpn-devel] Fix update_time() and openvpn_gettimeofday()
|
|
Commit Message
Vladislav Grishenko
Sept. 21, 2020, 2:40 p.m. UTC
With TIME_BACKTRACK_PROTECTION defined, openvpn_gettimeofday() uses and
updates global variable "now_usec" along with "now" only if current time
is ahead of the previsouly stored, taking nanoseconds into account.
But, update_time() function updates only "now" leaving "now_usec" as
is with any previously value stored.
This breaks both update_time() and openvpn_gettimeofday() results and
leads to time jumps in the future within one second, can affect shaper
and user timers.
100.900 openvpn_gettimeofday():
now set to 100s, now_usec set to 100ns, stored time is 100.900
101.300 update_time():
now set to 101s, but now_usec is not updated and still 900ns, stored
time jumps to the future 101.900
101.600 openvpn_gettimeofday():
current time 101.600 is in the past relatively stored time 101.900,
now & now_usec variables are not updated, returned time 101.900 is
still and again incorrect
102.100 openvpn_gettimeofday():
current time 102.100 is no longer in the past relatively stored time
101.900, so now & now_usec get updated with wrong time delta from
previous openvpn_gettimeofday() call or now/now_usec math
Since update_time() and openvpn_gettimeofday() calls are mixed in runtime,
to fix their coexistance update_time() must update "now_usec" as well,
calling just update_now() is not enough.
Signed-off-by: Vladislav Grishenko <themiron@yandex-team.ru>
---
src/openvpn/otime.h | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
Comments
> --- a/src/openvpn/otime.h > +++ b/src/openvpn/otime.h > @@ -78,13 +78,9 @@ openvpn_gettimeofday(struct timeval *tv, void *tz) > static inline void > update_time(void) > { > -#ifdef _WIN32 > - /* on _WIN32, gettimeofday is faster than time(NULL) */ > + /* can't use time(NULL), now_usec needs to be updated */ > struct timeval tv; > openvpn_gettimeofday(&tv, NULL); > -#else > - update_now(time(NULL)); > -#endif > } > > #else /* !TIME_BACKTRACK_PROTECTION */ > I am hesitant about this change, it mentions that gettimeofday is faster on Windows than time(NULL) and we prefer it there for this reason. But that also implies it is the other way round on other platforms. The update_time function is called in multiple critical places. Do we have any idea about this? I remember vaguely that the default gettimeofday in FreeBSD is more accurate than the Linux variant (involves a kernel call) but you can request a version similar to the Linux one by some flag (reading from a shared readonly memory page that is read only). Arne
Hi Arne, > But that also > implies it is the other way round on other platforms. The update_time function is > called in multiple critical places. Do we have any idea about this? On Linux with glibc's implementation both time() and gettimeofday() results in the same clock_gettime() call over VDSO (https://man7.org/linux/man-pages/man7/vdso.7.html). On FreeBSD (and so), same if VDSO is used both time() and gettimeofday() will use clock_gettime too with even additional "tv->tv_usec = 0" for time(). So, on most of architectures there will be no difference after replacing time() to gettimeofday() except. asm commands for moving 32/64bit tv_usec, it'll be not visible. On some acrhs/systems where VDSO is not supported - same syscall will happen. > I remember > vaguely that the default gettimeofday in FreeBSD is more accurate than the > Linux variant (involves a kernel call) but you can request a version similar to the > Linux one by some flag (reading from a shared readonly memory page that is > read only). As for clock drifting, it maybe feasible to use clock_gettime() with CLOCK_MONOTONIC and get rid of homegrown time adj code at all -> returned time will always be monotonic by design. At least on supported platforms (!_WIN32). -- Best Regards, Vladislav Grishenko > -----Original Message----- > From: Arne Schwabe <arne@rfc2549.org> > Sent: Tuesday, September 22, 2020 1:41 PM > To: Vladislav Grishenko <themiron@yandex-team.ru>; openvpn- > devel@lists.sourceforge.net > Subject: Re: [Openvpn-devel] [PATCH] Fix update_time() and > openvpn_gettimeofday() > > > > --- a/src/openvpn/otime.h > > +++ b/src/openvpn/otime.h > > @@ -78,13 +78,9 @@ openvpn_gettimeofday(struct timeval *tv, void *tz) > > static inline void > > update_time(void) > > { > > -#ifdef _WIN32 > > - /* on _WIN32, gettimeofday is faster than time(NULL) */ > > + /* can't use time(NULL), now_usec needs to be updated */ > > struct timeval tv; > > openvpn_gettimeofday(&tv, NULL); > > -#else > > - update_now(time(NULL)); > > -#endif > > } > > > > #else /* !TIME_BACKTRACK_PROTECTION */ > > > > I am hesitant about this change, it mentions that gettimeofday is faster on > Windows than time(NULL) and we prefer it there for this reason. But that also > implies it is the other way round on other platforms. The update_time function is > called in multiple critical places. Do we have any idea about this? I remember > vaguely that the default gettimeofday in FreeBSD is more accurate than the > Linux variant (involves a kernel call) but you can request a version similar to the > Linux one by some flag (reading from a shared readonly memory page that is > read only). > > Arne
diff --git a/src/openvpn/otime.h b/src/openvpn/otime.h index a6f7ec25..fab4575c 100644 --- a/src/openvpn/otime.h +++ b/src/openvpn/otime.h @@ -78,13 +78,9 @@ openvpn_gettimeofday(struct timeval *tv, void *tz) static inline void update_time(void) { -#ifdef _WIN32 - /* on _WIN32, gettimeofday is faster than time(NULL) */ + /* can't use time(NULL), now_usec needs to be updated */ struct timeval tv; openvpn_gettimeofday(&tv, NULL); -#else - update_now(time(NULL)); -#endif } #else /* !TIME_BACKTRACK_PROTECTION */