linux-kernel - Re: [RFC PATCH 1/2] ptp: add PTP_SYS_OFFSET

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z2WLGHRdlsRpT6BL@hoboy.vegasvil.org>
Date: Fri, 20 Dec 2024 07:19:52 -0800
From: Richard Cochran <richardcochran@...il.com>
To: Peter Hilber <quic_philber@...cinc.com>
Cc: linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
	virtio-dev@...ts.linux.dev, netdev@...r.kernel.org,
	Trilok Soni <quic_tsoni@...cinc.com>,
	Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eugenio Pérez <eperezma@...hat.com>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Jason Wang <jasowang@...hat.com>,
	Paolo Abeni <pabeni@...hat.com>, Shuah Khan <shuah@...nel.org>,
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
	linux-kselftest@...r.kernel.org, linux-api@...r.kernel.org,
	David Woodhouse <dwmw2@...radead.org>,
	"Ridoux, Julien" <ridouxj@...zon.com>,
	John Stultz <jstultz@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Stephen Boyd <sboyd@...nel.org>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>
Subject: Re: [RFC PATCH 1/2] ptp: add PTP_SYS_OFFSET_STAT for xtstamping with
 status

On Thu, Dec 19, 2024 at 09:42:03PM +0100, Peter Hilber wrote:
> Ioctl PTP_SYS_OFFSET_PRECISE2 provides cross-timestamping of device time
> and system time. This can be used for virtualization where (virtualization)
> host and guest refer to the same clocksource. It may be preferred to
> indicate UTC time, rather than TAI. It is then useful to indicate when and
> how the host processes UTC leap seconds (stepping or smearing on leap
> seconds),

If the VM host provides TAI, then the guest may freely derive UTC and
leap seconds on its own.  Whether to smear leap seconds or not is
properly an administrative configuration choice in the VM guest.

Leap seconds are scheduled to be deleted in 2036.  If, between now and
then, another one occurs, it will be global event, not determined by a
VM host.  The way you find out about leap seconds is through
networking using the NTP (or even just downloading the published list
once in a while).  VM clients typically have networking, and so
they can learn about a leap second all by themselves.

> in particular if the guest is not guaranteed to have an
> up-to-date Time Zone Database or similar.

Time zones are not connected to leap seconds.

> Also, a host may have a notion of how accurate its clock is w.r.t. the
> hosts' reference clocks.

I'm opposed to having device drivers try to claim any kind of clock
quality.  All of the clock control, servos, statistics, etc, are done
in user space, and so only user space software can generate meaningful
clock quality metrics.  Putting some kind of hand wavy values into
kernel drivers is just plain wrong IMO.

Thanks,
Richard