From patchwork Tue Sep 22 07:08:41 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladislav Grishenko X-Patchwork-Id: 1470 Return-Path: Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director7.mail.ord1d.rsapps.net ([172.27.255.50]) by backend30.mail.ord1d.rsapps.net with LMTP id oFtdH/Qval9cGQAAIUCqbw (envelope-from ) for ; Tue, 22 Sep 2020 13:10:12 -0400 Received: from proxy21.mail.iad3a.rsapps.net ([172.27.255.50]) by director7.mail.ord1d.rsapps.net with LMTP id QE84H/Qval+NYQAAovjBpQ (envelope-from ) for ; Tue, 22 Sep 2020 13:10:12 -0400 Received: from smtp29.gate.iad3a ([172.27.255.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy21.mail.iad3a.rsapps.net with LMTPS id wJuzGPQval+uNAAASBQwCQ (envelope-from ) for ; Tue, 22 Sep 2020 13:10:12 -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: smtp29.gate.iad3a.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: 77b389ca-fcf6-11ea-ab5b-52540071c87c-1-1 Received: from [216.105.38.7] ([216.105.38.7:60940] helo=lists.sourceforge.net) by smtp29.gate.iad3a.rsapps.net (envelope-from ) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id 33/F3-19217-1FF2A6F5; Tue, 22 Sep 2020 13:10:09 -0400 Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kKln0-00068N-W6; Tue, 22 Sep 2020 17:09:14 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKln0-00068G-13 for openvpn-devel@lists.sourceforge.net; Tue, 22 Sep 2020 17:09:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=References:In-Reply-To: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:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4+lBiLqDtcdPv7eicZ7KQA01QIC7pzWarYTOefABijI=; b=i3ZuWPcLX9wdyKoOW5K76PIwz1 FeErUspmYdsOfgEuE3AHHW0iepE/c+Jj4yQRq8XPkRJTTQwZDFpZV9BUeqt7rU00Zwcjvcx7cGvrj Upm2s1xZgfT8sRdTrCTPF9MMVs6lpE7fdAZ//AUGufFXbDQsYjihvBL7zdaPAd8nndkk=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=References:In-Reply-To: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:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4+lBiLqDtcdPv7eicZ7KQA01QIC7pzWarYTOefABijI=; b=aBLm2cm7Tmn5IrNhYNDK1YvUSO FiCNT0tIu1x6HoRJkX9qPZWHBoumTFdJKyzmhjLccQNzXfvwnMWG1Cpp8YCbakxgkuFncjx9hjB2/ n2Vj8vlmvm+xgCYft3m66zMoFfhFY4pel1dXbx7X//ePtD3Vc7Xl4mI0byF0ioF/S2TM=; Received: from forwardcorp1j.mail.yandex.net ([5.45.199.163]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1kKlmo-003R39-33 for openvpn-devel@lists.sourceforge.net; Tue, 22 Sep 2020 17:09:13 +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 forwardcorp1j.mail.yandex.net (Yandex) with ESMTP id E8A7F2E14AA for ; Tue, 22 Sep 2020 20:08:46 +0300 (MSK) Received: from iva4-7c3d9abce76c.qloud-c.yandex.net (iva4-7c3d9abce76c.qloud-c.yandex.net [2a02:6b8:c0c:4e8e:0:640:7c3d:9abc]) by iva8-d077482f1536.qloud-c.yandex.net (mxbackcorp/Yandex) with ESMTP id xStQeWUYBt-8jviDNBk; Tue, 22 Sep 2020 20:08:45 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1600794525; bh=4+lBiLqDtcdPv7eicZ7KQA01QIC7pzWarYTOefABijI=; h=In-Reply-To:Message-Id:References:Date:Subject:To:From; b=mUChZK4o3RNqo2ICnWhFieBdvhmdXtH2Mg5FtQzRhJL6DquqwIsrRqKwbYd1+GCd2 llmAEKcCZVhOCP7z06SO3fHfeXzr9XCeukNJGrTdbK5gg3Sjv8tgC/4bGAAVkNsEb6 OEyt77Han0QSMvQrr0oStbdakUrn8+b7rX0AuIoQ= Received: from unknown (unknown [95.108.219.45]) by iva4-7c3d9abce76c.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id J9md7lMe5r-8jlWpHq5; Tue, 22 Sep 2020 20:08:45 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) From: Vladislav Grishenko To: openvpn-devel@lists.sourceforge.net Date: Tue, 22 Sep 2020 22:08:41 +0500 Message-Id: <20200922170841.13729-1-themiron@yandex-team.ru> X-Mailer: git-send-email 2.17.1 In-Reply-To: <75c379c2-35da-da12-d21f-44b1d6b1065b@rfc2549.org> References: <75c379c2-35da-da12-d21f-44b1d6b1065b@rfc2549.org> 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_PASS SPF: sender matches SPF record 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: 1kKlmo-003R39-33 Subject: [Openvpn-devel] [PATCH v3] Fix update_time() and openvpn_gettimeofday() coexistence X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-getmail-retrieved-from-mailbox: Inbox 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 openvpn_gettimeofday() results and leads to time jumps in the future within one second, can affect shaper and user timers. Example: 100.900 openvpn_gettimeofday(): now set to 100s, now_usec set to 900ns, 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, there're several options to fix the things: 1. Allow update_time() to reset "now_usec" value backward to 0, since it's used directly only in time ajusting and always invalidate it in openvpn_gettimeofday() unless time has drifted backwards. Quick solution that only fixes openvpn_gettimeofday() and keeps current level of time performance and backward-protection handling way. 2. Switch update_time() to gettimeofday() not only for windows, but for all platforms: "now_usec" will be updated accordingly. As a disadvantage, gettimeofday() may have performance penalty on older or platforms w/o VDSO where expensive kernel syscall will be made. And it will still need time adjusting code, doubt it's feasible. 3. Switch update_time() and openvpn_gettimeofday() to clock_gettime() on Linux/BSD platforms with CLOCK_REALTIME_FAST/CLOCK_REALTIME_COARSE clock sources. According tests it'll be faster with VDSO than gettimeofday() or CLOCK_REALTIME/CLOCK_REALTIME_PRECISE, but still may require adjusting code to protect from time jumps on devices with no RTC (ex. routers) where NTP is the only way to get correct time after boot. Since not every *libc have clock_gettime() and corresponding CLOCK_* defines and/or running kernel may have no VDSO/corresponding CLOCK_* support - related autotools checks and fallback code can still be necessary. 4. Switch update_time() and openvpn_gettimeofday() to clock_gettime() on Linux/BSD platforms with CLOCK_MONOTONIC_FAST/CLOCK_MONOTONIC_COARSE clock sources. This may allow to get rid of time adjusting code at all with the acceptable performance on modern systems, but may still require to fallback to gettimeofday() with adj friends on older platforms (most likely to be Linux CPE/routers). From the effort point of view, splitting the whole OpenVPN code into realtime/monotonic is most significant and desired task among the above, several parts still needs to use realtime due API or storage or output reasons. This patch implements the first stage only. v2: move from gettimeofday() (1st way) back to time(), don't check previous value of "now_usec" in update_usec() instead v3: recover "now_usec" checks against time jumps within one second, zero it in update_time() calls instead to pass the check. Signed-off-by: Vladislav Grishenko Acked-by: Gert Doering --- src/openvpn/otime.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/openvpn/otime.h b/src/openvpn/otime.h index a6f7ec25..78d20ba8 100644 --- a/src/openvpn/otime.h +++ b/src/openvpn/otime.h @@ -84,6 +84,7 @@ update_time(void) openvpn_gettimeofday(&tv, NULL); #else update_now(time(NULL)); + now_usec = 0; #endif }