netdev - Re: [PATCH v2 net-next] ptp: Add clock driver for the OpenCompute TimeCard.

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] [day] [month] [year] [list]

Message-ID: <20201204133314.GA26030@hoboy.vegasvil.org>
Date:   Fri, 4 Dec 2020 05:33:14 -0800
From:   Richard Cochran <richardcochran@...il.com>
To:     Jonathan Lemon <jonathan.lemon@...il.com>
Cc:     netdev@...r.kernel.org, kuba@...nel.org, kernel-team@...com
Subject: Re: [PATCH v2 net-next] ptp: Add clock driver for the OpenCompute
 TimeCard.

On Thu, Dec 03, 2020 at 06:00:37PM -0800, Jonathan Lemon wrote:
> On Thu, Dec 03, 2020 at 04:56:24PM -0800, Richard Cochran wrote:

> > The name here is a bit confusing since "timex" has a special meaning
> > in the NTP/PTP API.
> 
> The .gettimex64 call is used here so the time returned from the
> clock can be correlated to the system time.

[facepalm] man, its in the interface naming.  Oh well.

> > This driver looks fine, but I'm curious how you will use it.  Can it
> > provide time stamping for network frames or other IO?
> 
> The card does have a PPS pulse output, so it can be wired to a network
> card which takes an external PPS signal.

Cool.  So the new ts2phc program can synchronize the NICs for you.
All that is missing here is ptp_clock_info.enable().  With that in
place, it will work out of the box.

> Right now, the current model (which certainly can be improved on) is using
> phc2sys to discipline the system and NIC clocks.

Yeah, ts2phc will fill in the gap.

> I'll send a v3.  I also need to open a discussion on how this should
> return the leap second changes to the user - there doesn't seem to be
> anything in the current API for this.

There is the clock_adjtime() system call, analogue of adjtimex.

Right now there is no PHC driver access to the timex.status field
(which carries the leap flags), but that can be changed...

kernel/time/posix-timers.c	do_clock_adjtime()  calls
kernel/time/posix-clock.c	pc_clock_adjtime()  calls
drivers/ptp/ptp_clock.c		ptp_clock_adjtime()

At this point the PHC layer could invoke a new, optional driver
callback that returns the leap second status flags, and then the PHC
layer could set timex.status appropriately.

Having said all that, the ts2phc program takes the approach of getting
the leap second information from the leap seconds file.  Of course,
this requires administratively updating the file at least once every
six months.

I considered and rejected the idea of trying to get the current leap
second status from GPS for two reasons.  First, there is no
standardized and universally implemented way of querying this from a
GPS.  Second, and more importantly, the leap second information is
only broadcast every 12.5 minutes, and that it is *way* too long to
wait after cold boot for applications I am interested in.

So the choice boiled down to either having to keep a file up to date,
say every month or so, or waiting 15 minutes in the worst case.  I
chose the lesser of two evils.

Thanks,
Richard