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: <098c86747dfa8e8a917d2b029ccc89dd8023b25d.camel@infradead.org>
Date: Thu, 24 Jul 2025 16:08:46 +0200
From: David Woodhouse <dwmw2@...radead.org>
To: David Arinzon <darinzon@...zon.com>, 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>, Miroslav Lichvar <mlichvar@...hat.com>, Thomas Gleixner
 <tglx@...utronix.de>,  netdev@...r.kernel.org
Cc: "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, 2025-07-24 at 14:56 +0300, David Arinzon wrote:
> 
> 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.
> 
> - 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.

Should this also include a 'type' field matching vmclock & virtio-rtc?
Especially if it's a smeared type, that is a (contra-)indication of the
quality of the clock.

Julien, I assume you're happy that this is *maxerror* and we completely
ignore esterror which should never exist anyway?

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)