netdev - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <a352mltlizneonxazn4bffydn57fyudrc3zougii2rnatg3jga@3yagssaob5sb>
Date: Thu, 2 Jan 2025 17:11:01 +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 Wed, Dec 25, 2024 at 04:42:14PM -0800, Richard Cochran wrote:
> On Mon, Dec 23, 2024 at 07:13:46PM +0100, Peter Hilber wrote:
> 
> > 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.
> 
> I thought that the whole point of using a VM is to isolate the guests
> from each other and the host.  What you describe is a promiscuous
> coupling between guest and host, and the kernel shouldn't be in
> the business of supporting such behavior.
> 

Why? There is already ptp_kvm etc. in the kernel.

Would it be more acceptable to just announce leap seconds, but not
whether to smear?

> > Also, the administrative
> > configuration choice may change over the lifetime of a system.
> 
> Right, which is why we should keep those choices out of kernel space.
> Kernel provides mechanism, not policy.
>  

As discussed, the policy would be forwarded, not determined, by the
kernel.

If the policy would be forwarded via NTP (by the NTP server smearing or
not smearing leap seconds), this would have the following disadvantages:

- need to use an NTP server just for announcing leap seconds

- redundancy of serving time both via NTP and via PTP clocks (for better
  precision)

- no awareness about leap seconds in case of smearing.

> > 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.
> 
> Again, I don't think the kernel should be the solution to guests that
> lack networking.  Instead, the place to fix the problem is at the
> root, namely in the guests.
> 

I do not understand. Is the point that guests should decide through
another channel about leap second smearing?

> > 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.
> 
> Overall, I don't trust devices to tell the truth about their
> qualities.  But putting that aside, we would need to see some kind of
> commonality in hardware implementation to advertise their metrics.
> However, AFAICT there is no such industry practice on the market.
> 

I hope there will be some feedback from third parties (at least related
to virtualization).

> > 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.
> 
> Again, host user space shouldn't misuse the kernel to share random
> metrics with guest user space.  Isn't there another way to share such
> info from host to guest?
> 

For sure. But the aim of this proposal is to have an interoperable time
synchronization solution for VMs through a Virtio device. So the idea is
to include metrics, if a consensus on their usefulness can be reached.
AFAIU it is difficult to bypass the kernel for Virtio devices.

Thanks for the discussion,

Peter