netdev - Re: [PATCH] ptp: Add PTP_CLOCK_EXTTSUSR internal ptp

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210630225734.ymgdtzpwvyvj7gfa@bsd-mbp.dhcp.thefacebook.com>
Date:   Wed, 30 Jun 2021 15:57:34 -0700
From:   Jonathan Lemon <jonathan.lemon@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     netdev@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH] ptp: Add PTP_CLOCK_EXTTSUSR internal ptp_event

On Wed, Jun 30, 2021 at 07:42:57AM -0700, Richard Cochran wrote:
> On Tue, Jun 29, 2021 at 08:50:31PM -0700, Jonathan Lemon wrote:
> > The PHC should be sync'd to the PPS coming from the GPS signal.
> > However, the GPS may be in holdover, so the actual counter comes
> > from an atomic oscillator.  As the oscillator may be ever so 
> > slightly out of sync with the GPS (or drifts with temperature),
> > so we need to measure the phase difference between the two and
> > steer the oscillator slightly.
> > 
> > The phase comparision between the two signals is done in HW 
> > with a phasemeter, for precise comparisons.  The actual phase
> > steering/adjustment is done through adjphase().
> 
> So you don't need the time stamp itself, just the phase offset, right?
> 
> > What's missing is the ability to report the phase difference
> > to user space so the adjustment can be performed.
> 
> So let's create an interface for that reporting.

The current 'struct ptp_extts_event' returns 32 bytes to userspace
for every event.  Of these, 16 bytes (50%) are unused, as the structure
only returns a timestamp + index, without any event information.

It seems logical that these unused bytes (which are event specific)
could be used to convey more information about the event itself.


> It is about getting the right interface.  The external time stamp
> interface is generic and all-purpose, and so I question whether your
> extension makes sense.

I question whether the definition of "all-purpose" really applies
here.  All it tells me is that "an event happened on this channel 
at this time".

If the user doesn't care about additional data, it can just be 
ignored, right?


In the meantime, let's see what the HW guys say about doing the 
comparision in SW.  Other vendors have PPS input to their MAC,
so the disciplining is done in HW, bypassing adjphase() completely.
-- 
Jonathan