netdev - Re: [RFC 0/3] ptp: Add esterror support

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: <a1bb18d0-174f-486a-bdfd-295d7c5ce4b2@lunn.ch>
Date: Fri, 16 Aug 2024 01:11:44 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Maciek Machnikowski <maciek@...hnikowski.net>
Cc: Richard Cochran <richardcochran@...il.com>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>, netdev@...r.kernel.org,
	jacob.e.keller@...el.com, darinzon@...zon.com, kuba@...nel.org
Subject: Re: [RFC 0/3] ptp: Add esterror support

On Fri, Aug 16, 2024 at 12:06:51AM +0200, Maciek Machnikowski wrote:
> 
> 
> On 15/08/2024 23:08, Richard Cochran wrote:
> > On Thu, Aug 15, 2024 at 05:00:24PM +0200, Maciek Machnikowski wrote:
> > 
> >> Think about a Time Card
> >> (https://opencomputeproject.github.io/Time-Appliance-Project/docs/time-card/introduction).
> > 
> > No, I won't think about that!
> > 
> > You need to present the technical details in the form of patches.
> > 
> > Hand-wavey hints don't cut it.
> > 
> > Thanks,
> > Richard
> 
> This implementation addresses 3 use cases:
> 
> 1. Autonomous devices that synchronize themselves to some external
> sources (GNSS, NTP, dedicated time sync networks) and have the ability
> to return the estimated error from the HW or FW loop to users

So this contradicts what you said earlier, when you said the device
does not know its own error, it has to be told it.

So what is user space supposed to do with this error? And given that
you said it is undefined what this error includes and excludes, how is
user space supposed to deal with the error in the error? Given how
poorly this is defined, what is user space supposed to do when the
device changes the definition of the error?

The message Richard has always given is that those who care about
errors freeze their kernel and do measurement campaign to determine
what the real error is and then configure user space to deal with
it. Does this error value negate the need for this?

> 2. Multi function devices that may have a single isolated function
> synchronizing the device clock (by means of PTP, or PPS or any other)
> and letting other functions access the uncertainty information

So this is the simple message passing API, which could be implemented
purely in the core? This sounds like it should be a patch of its own,
explaining the use case. 

> 3. Create a common interface to read the uncertainty from a device
> (currently you can use PMC for PTP, but there is no way of receiving
> that information from ts2phc)

That sounds like a problem with ts2phc? Please could you expand on why
the kernel should be involved in feature deficits of user space tools?

> Also this is an RFC to help align work on this functionality across
> different devices ] and validate if that's the right direction. If it is
> - there will be a patch series with real drivers returning uncertainty
> information using that interface. If it's not - I'd like to understand
> what should I improve in the interface.

I think you took the wrong approach. You should first state in detail
the use cases. Then show how you solve each use cases, both the user
and kernel space parts, and include the needed changes to a real
device driver.

	Andrew