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: <f4eae75af72331ea298beb5d91d18055ecd97a33.camel@infradead.org>
Date: Mon, 04 Aug 2025 10:07:48 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Julien Ridoux <julien@...clab.org>, mlichvar@...hat.com
Cc: akiyano@...zon.com, aliguori@...zon.com, alisaidi@...zon.com, 
 amitbern@...zon.com, andrew@...n.ch, benh@...zon.com, darinzon@...zon.com, 
 davem@...emloft.net, dwmw@...zon.com, edumazet@...gle.com,
 evgenys@...zon.com,  evostrov@...zon.com, joshlev@...zon.com,
 kuba@...nel.org, matua@...zon.com,  msw@...zon.com, nafea@...zon.com,
 ndagan@...zon.com, netanel@...zon.com,  netdev@...r.kernel.org,
 ofirt@...zon.com, pabeni@...hat.com,  richardcochran@...il.com,
 ridouxj@...zon.com, saeedb@...zon.com,  tglx@...utronix.de, zorik@...zon.com
Subject: Re:  [RFC PATCH net-next] ptp: Introduce
 PTP_SYS_OFFSET_EXTENDED_TRUSTED ioctl

On Sun, 2025-08-03 at 16:51 -0700, Julien Ridoux wrote:
> > On 7/28/25, 7:28 AM, "Miroslav Lichvar"
> > <mlichvar@...hat.com <mailto:mlichvar@...hat.com>> wrote:
> > 
> > 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?
> 
> That's a fair call. The ioctl can be renamed to
> PTP_SYS_OFFSET_EXTENDED_ATTRS

While we're talking about extending the userspace API... I think I'd
also like a way to use the actual hardware counter (TSC, arch timer) as
the reference clockid instead of CLOCK_MONOTONIC etc. 

In a hosting environment, I barely even care about calibrating the host
kernel's timekeeping against the external time reference. What I *do*
care about calibrating is the hardware counter, so that it can be
correctly advertised to guests through a vmclock device.

Using vmclock and simply advertising the relationship between the
hardware counter and precision time, makes *so* much more sense than
having hundreds of virtual guests on the same machine all performing
the *same* calibration of precisely the same underlying counter, each
of them potentially experiencing latency of measurements due to steal
time while they do so.

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