Re: [gpsd-dev] PPS and privilege-dropping

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> > I have tested with the GR601W, not running as root, over USB.  Serial
> > PPS works (I see PPS messages in JSON).  This means that it ought to
> > be possible in general to hotplug USB devices delivering PPS and have
> > them work, even well after gpsd has dropped root privileges.
> 
> Yes, but KPPS will not.  BTW, the PPS mmessages in JSON are NMEA, and
> never found a good use for them.

"are NMEA"?  Sorry, I don't understand what you're trying to say here.

The JSON PPS messages were designed with a specific purpose in mind -
to track the skew between NTP-adjusyed system clock and GPS+PPS time
so Dave Taht and I can benchmark NTP.
 
> > We can't make kernel PPS work for hotplugged devices in the general
> > case because hotplugging happens after privilege dropping.  I like
> > the fact that gpsd has only a very tiny attack surface for privilege
> > escalation and want to keep that.
> 
> I should prolly add a doc note then.

More than that.  See below.

> > I think kernel PPS failing is tolerable because *serial* PPS works in
> > the general case.  What is the functional advantage of kernel PPS over
> > serial?
> 
> By 'serial' you mean basic PPS.  All PPS is 'serial' as it uses an
> RS-232 control line to mark the edge of the second.  Kernel PPS uses a
> kernel function to accurately timestamp the status change on the PPS
> line.  Basic PPS has the kernel wake up the PPS thread and then the PPS
> thread reads the current system clock.  Obviously and as notedd in the
> code, having the kernel do the time stamp is lower latency and less
> jitter.  That is about 20 micro Sec less latency and +/- 5 mucro Sec
> jitter on one of my test systems.
>
> With KPPS it is very doable to get the system clock stable to +/- 1 micro 
> Sec.  Otherwise you are lucky to get +/- 5 micro Sec.  Important to a time
> nut.

Can I talk you into drafting a HOWTO on time-nuttery with GPSD to be
included in the documentation?  Just dump your brain; I'll polish the
formatting and language and then you can check my edits.

It should include the above two paragraphs. Also remarks on serial-PPS
accuracy vs. USB accuracy - the latter is controlled by the USB
polling interval and will be about one millisecond, with the jitter.
being whatever USB's polling-interval jitter is.

Which, by the way, is why I'm not sure there's any actual point to
trying to support kernel PPS for hotplugged devices. The reason:
they're going to be USB, which means they have an intrinsic accuracy
limit about five times larger than the difference between plain and
kernel PPS.

Still, if you think we absolutely need to do this, I could add an scons
option to disable privilege-dropping.

A brief tutorial on how to choose NTPd offset parameters would be good
to have in the HOWTO, too.  Basically I want this to be a primer for
the relatively ignorant - like, er, me.

Also I think the table of NTP offsets that's now on the hardware page
should move to the HOWTO.

> So if you can adjust Scons to disable all PPS if no TIOMCWAIT then the
> code will be more correct and simpler.

I'll work on it

From later mail:

>ALL ntpd prefers root for initialization.  There is serious loss of
>functionality when not initialized as root. 

The HOWTO should explain this.  There's a reference to it in a comment
in ntpshm.c, but it didn't tell me eniough to understand *why*.

>                                           You need to expand your
>thread wait to the entire ntpd initialization.  This will in fact make
>the code much cleanner as you no longer need the new layer you added.
>Just protect the entire thread.

I will attempt this.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature