linux-kernel - kernel/time/ntp.c: possible unit inconsistency

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 8 Jul 2016 11:46:49 +0300
From:	"Matwey V. Kornilov" <matwey.kornilov@...il.com>
To:	john.stultz@...aro.org, tglx@...utronix.de,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: kernel/time/ntp.c: possible unit inconsistency

Hello,

I think I found minor inconsistency in measurement units between ntpd
and linux kernel. Though, I am not sure completely.
I've failed to reach ntp mail list because lists.ntp.org is down for
me for several days.

My principal concern is about `maxerror' quantity.
kernel/time/ntp.c has time_maxerror variable which is can be get/put
from/to userspace using ntp_adjtime call.
The single point where the variable is altered by the linux kernel is
second_overflow() function in kernel/time/ntp.c:456.
Here the following happens:

        /* Bump the maxerror field */
        time_maxerror += MAXFREQ / NSEC_PER_USEC;
        if (time_maxerror > NTP_PHASE_LIMIT) {
                time_maxerror = NTP_PHASE_LIMIT;
                time_status |= STA_UNSYNC;
        }

The line assumes that time_maxerror is always measured in the units of usec.

At the same time, if we get ntp-4.2.8p8 sources and look at

ntpdc/ntpdc_ops.c:2955 function kerninfo() or
ntpd/ntp_control.c:2359 function ctl_putsys()

then we found that ntpd expects that ntp_adjtime returns maxerror
either in usec (if STA_NANO is not used) or in nsec (if STA_NANO is
used).
So, there can be the case when kernel measures maxerror in usec and
ntpd does in nsec.

-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2207@...ber.ru