netdev - Re: Extending socket timestamping API for NTP

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: <20170209111529.GB1449@localhost>
Date:   Thu, 9 Feb 2017 12:15:29 +0100
From:   Miroslav Lichvar <mlichvar@...hat.com>
To:     Denny Page <dennypage@...com>
Cc:     netdev@...r.kernel.org, Richard Cochran <richardcochran@...il.com>,
        Jiri Benc <jbenc@...hat.com>,
        "Keller, Jacob E" <jacob.e.keller@...el.com>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: Extending socket timestamping API for NTP

On Wed, Feb 08, 2017 at 04:45:05PM -0800, Denny Page wrote:
> > On Feb 07, 2017, at 06:01, Miroslav Lichvar <mlichvar@...hat.com> wrote:
> > 
> > 5) new SO_TIMESTAMPING options to get transposed RX timestamps

> > 6) new SO_TIMESTAMPING option to get PHC index with HW timestamps
> > 
> >   With bridges, bonding and other things it's difficult to determine
> >   which PHC timestamped the packet. It would be very useful if the
> >   PHC index was provided with each HW timestamp.
> > 
> >   I'm not sure what would be the best place to put it. I guess the
> >   second timespec in scm_timestamping could be reused for this, but
> >   that sounds like a gross hack. Do we need to define a new struct?

> Miroslav, if #5 were implemented, would #6 still needed?

Yes. With #5 we wouldn't have to know the link speed of the interface
and guess the length of received packets (or use raw sockets), but we
would still not know which clock has actually timestamped the packet.

-- 
Miroslav Lichvar