Re: [gpsd-dev] RFC2783 vs TIOCMIWAIT, PPS on NetBSD

[Greg Troxel]

Andy Walls <address@hidden> writes:

> On Fri, 2013-11-01 at 09:05 -0400, Greg Troxel wrote:

> From RFC2783 Section 3.4.2:
> "A suitably privileged application may use time_pps_setparams() to set
>    the parameters (mode bits and timestamp offsets) for a PPS source."
>
> So time_pps_setparams() can require privileges.

True, but in 3.4.1, third paragraph in DESCRIPTION it says
"time_pps_setparams SHOULD be prohibited .. [if the fd is open only for
reading]", which I read as a clue that "can write device" was the
meaning of "suitable".  (Certainly it's within-spec to require more than
that.)

> The rationale is likely that someone can muck with system time
> offsets, which is a security concern.

[will mention offset mucking below]

> From RFC2783 Section 3.4.4:

> "An application with appropriate privileges may use time_pps_kcbind()
>    to bind a kernel consumer to the PPS source specified by the handle."
>
> So time_pps_kcbind() can require privileges.  Again, the rationale is
> likely that someone can muck with system time, which is a security
> concern. 

Sure - but in the time_pps_kcbind case the language in the discussion is
quite clear that the privileges that should be needed are the same ones
to modify the system timebase.

>> From RFC2783, I can't tell if setparams should affect only the current
>> instance of the device, or others that also have it open.
>> From quickly reading the NetBSD code, setparams looks to be
>> unprivileged.
>
> IMO, RFC2783's doesn't prohibit setparams from being an unprivileged
> operation, since it uses the weasel words "suitably privileged".

I didn't really see that as weasely, since the clear hint is "can write
to the device".

What I can't figure out is what should happen when there is a single
serial device and two processes open the same device (or the /dev/ppsN
that corresponds to that device).  It would be entirely possible to have
separate pps state associated with each open, so that setparams only
affects the time returned to that opening process.  But this isn't
explained either way, and I think it's because when RFC2783 was written
the notion was that obviously only a single program like ntpd would do
this for any given device.

From my skim of the Linux and NetBSD code, I think there's one pps state
associated with the device, and that state is shared with all users.
(But I read the code too fast.)

This is important because if one process opens /dev/dty00 and sets an
offset and does kcbind and another process opens /dev/dty00 and sets an
offset, the kernel timekeeping can be affected.  I'm guessing this is
the case you referred to above.  That's perhaps a case for having
exclusive open when opening devices intended to control system time.

The other side of the coin is that a user process with no special
privileges but which can read/write a serial port (or the corresponding
/dev/ppsN) should be able to set modes and offets and call
time_pps_fetch.  That doesn't affect anything else (except maybe other
users of the port), and really shouldn't need root or the ability to set
the system time.

> Yup.  It appears that working on serial device nodes appears to be a
> choice the *BSDs made.  I suspect that Linux did not make that same
> choice.

Agreed - this strikes me as odd because it requires an extra level of
indirection for no apparent reason.

> I base this on the existing gpsd code which divines the
> correct /dev/pps? node, and on that Linux has a tty line discipline that
> is explicitly used for setting up a /dev/pps? device that snoops the DCD
> line of a tty. 

So basically some (beyond RFC2783) ioctl on the tty, which binds it to a
/dev/ppsN and tells you which one?

Do the permissions from the tty get copied to the /dev/ppsN device?  (It
seems obvious that one should be able to access /dev/ppsN iff one can
access the underlying device.)

>> Unless I'm missing something, in the docs I think we need to treat the
>> notion of /dev/ppsN as Linux-specific.
>
> I think you are correct, but maybe the statement needs to be broader.
>
> Whatever the device node type and name, they have to be treated as OS
> specific, since, as you mentioned, RFC2783 decided it was not in the
> RFC's scope (Section 3.4.1).

Sure, that's fair.  But having it work on fds corresponding to serial
ports is what a reader of RFC2783 applying the Principle of Least
Astonishment would expect (imho).  In gpsd this will need OS-specific
ifdefs to come up with the fd to use the standard calls, which is easy
enough.  I suspect that all BSDs and Solaris will use the serial port
fd, as they seem to have gotten the same code around the time of
publication from the sample code from the RFC authors.

> The particular rationale for why Linux uses /dev/pps? is here:
>
> http://lxr.free-electrons.com/source/Documentation/pps/pps.txt#L40
>
> Basically, not all PPS sources are from serial or parallel ports, so
> what does one do for the device node for these other sources?

I saw that, but it struck me as the tail wagging the dog.

I would have created /dev/gpioN and implemented read/write ioctls for
the pin state, and made the pps ioctls work on that device, as that
seems easier and cleaner than inventing a method of discerning the
indirection to /dev/ppsN.  Or at least I would not have moved pps for
things that do have device nodes to /dev/ppsN.

[pause to check] FWIW, NetBSD has /dev/gpioN for the Nth GPIO controller
(which means one needs a 'select which pin' in addition to the standard
interface, or pin-specific devices).  There isn't currently any pps
support.

> RFC2783 Section 1 does state:
>
> "Although existing practice has focussed on the use of serial lines
>  and DCD transitions, PPS signals might also be delivered by other
>  kinds of devices.  The API specified in this document does not
>  require the use of a serial line, although it may be somewhat biased
>  in that direction."
>
> I happen to use GPIO pins and Timer-Counter event-capture pins for PPS
> devices at the moment.  Having a device not associated with a TTY is
> kind of necessary for me.  (Though I don't need gpsd to worry about them
> in my current work.)

Sure, but "device not associated with a TTY" does not imply "device not
associated with a character device node".  I realize none of this is
going to change, and it's easy to code for.

Thanks for the discussion - now I understand the bigger picture.

The remaining question is that I wonder why gpsd uses TIOCMIWAIT at all,
given that time_pps_fetch() can be set to block until a sample appears.
Is it a method for getting the timestamp in user space on Linux systems
that have been compiled with support for checking DCD on a serial port
but compiled without support for the RFC2783 interface?  If so,
presumably that should be used only if RFC2783 support is missing.

(FWIW, on NetBSD, RFC2783 support appears to be always on and not a
kernel option, although kcbind is an option.  Strictly speaking, that
seems like a bug, although it's a tiny amount of code.)

pgpsH2dkVQ3y9.pgp
Description: PGP signature