netdev - Re: [RFC PATCH net-next] ptp: Introduce PTP_SYS_OFFSET_EXTENDED

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: <aIeInmXyglMdIuxE@localhost>
Date: Mon, 28 Jul 2025 16:26:38 +0200
From: Miroslav Lichvar <mlichvar@...hat.com>
To: David Arinzon <darinzon@...zon.com>
Cc: David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
	Richard Cochran <richardcochran@...il.com>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	"Woodhouse, David" <dwmw@...zon.com>, Andrew Lunn <andrew@...n.ch>,
	David Woodhouse <dwmw2@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>, netdev@...r.kernel.org,
	"Machulsky, Zorik" <zorik@...zon.com>,
	"Matushevsky, Alexander" <matua@...zon.com>,
	Saeed Bshara <saeedb@...zon.com>, "Wilson, Matt" <msw@...zon.com>,
	"Liguori, Anthony" <aliguori@...zon.com>,
	"Bshara, Nafea" <nafea@...zon.com>,
	"Schmeilin, Evgeny" <evgenys@...zon.com>,
	"Belgazal, Netanel" <netanel@...zon.com>,
	"Saidi, Ali" <alisaidi@...zon.com>,
	"Herrenschmidt, Benjamin" <benh@...zon.com>,
	"Kiyanovski, Arthur" <akiyano@...zon.com>,
	"Dagan, Noam" <ndagan@...zon.com>,
	"Bernstein, Amit" <amitbern@...zon.com>,
	"Ostrovsky, Evgeny" <evostrov@...zon.com>,
	"Tabachnik, Ofir" <ofirt@...zon.com>,
	Julien Ridoux <ridouxj@...zon.com>,
	Josh Levinson <joshlev@...zon.com>
Subject: Re: [RFC PATCH net-next] ptp: Introduce
 PTP_SYS_OFFSET_EXTENDED_TRUSTED ioctl

On Thu, Jul 24, 2025 at 02:56:56PM +0300, David Arinzon wrote:
> The proposed PTP_SYS_OFFSET_EXTENDED_TRUSTED ioctl offers the
> same timestamps as the PTP_SYS_OFFSET_EXTENDED ioctl, but extends
> it with a measurement of the PHC device clock accuracy and the
> synchronization status. This supports two objectives.

I have a slight issue with the naming of this new ioctl. TRUSTED
implies to me the other supported ioctls are not to be trusted
for some reason, but that's not the case, right? It's just more
information provided, i.e. it's extended once again. Would
PTP_SYS_OFFSET_EXTENDED3 or PTP_SYS_OFFSET_EXTENDED_ATTRS not work
better?

It would be nice to have a new variant of the PTP_SYS_OFFSET_PRECISE
ioctl for the ptp_kvm driver to pass the system clock maxerror and
status.

> The proposed PTP_SYS_OFFSET_EXTENDED_TRUSTED ioctl fulfills both
> objectives by extending each PHC timestamp with two quality
> indicators:
> 
> - error_bound: a device-calculated value (in nanoseconds)
>   reflecting the maximum possible deviation of the timestamp from
>   the true time, based on internal clock state.

Is this value expected to be changing so rapidly that it needs to be
provided with each sample of the ioctl? I'd expect a maximum value
from all samples to be sufficient (together with the worst status).

> - clock_status: a qualitative state of the clock, with defined
>   values including:
>   1. Unknown: the clock's synchronization status cannot be
>      reliably determined.
>   2. Initializing: the clock is acquiring synchronization.
>   3. Synchronized: The clock is actively being synchronized and
>      maintained accurately by the device.
>   4. FreeRunning: the clock is drifting and not being
>      synchronized and updated by the device.
>   5. Unreliable: the clock is known to be unreliable, the
>      error_bound value cannot be trusted.

I'd expect a holdover status to be included here.

-- 
Miroslav Lichvar