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: <Z2ymZuiFqY8mxihJ@hoboy.vegasvil.org>
Date: Wed, 25 Dec 2024 16:42:14 -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 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.

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

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

Thanks,
Richard