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

Message-ID: <wcxdbqhoe4cppukyy5rvkq5am4ht6wk5u6d6g2k2swqhidjw7i@6nar5vuusm35>
Date: Mon, 23 Dec 2024 19:13:46 +0100
From: Peter Hilber <quic_philber@...cinc.com>
To: Richard Cochran <richardcochran@...il.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 Fri, Dec 20, 2024 at 07:19:52AM -0800, Richard Cochran wrote:
> 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.
> 

The precise synchronization of the VM guest with its immediate
environment can also be important; a VM guest may depend the decision
about leap second smearing on its environment. Also, the administrative
configuration choice may change over the lifetime of a system.

> 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.
> 

The intent is to also support (embedded) VM clients which are themselves
not necessarily internetworked, which do not get a lot of maintenance,
and which are not guaranteed to get an update within the typically less
than 6 months between leap second announcement and occurrence. I will
document this in the patch message.

> > 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.
> 

The IANA Time Zone Database includes a leap seconds list.

> > 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.

I agree that a device driver should not determine clock quality metrics.
The intent is that the driver forwards metrics, if such are advertised
by the device. These metrics should describe the accuracy etc. of the
device itself. The patch message should document this more clearly. The
metrics can be determined e.g. by virtualization host user space
software. The device driver would just expose the device metrics to user
space.

Thanks for the feedback,

Peter