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: <CAF=yD-JLiABx6TcVg_8mS5ZhomRaZ+cZ8edx00hJNG8PDrsSjg@mail.gmail.com>
Date:   Tue, 7 Feb 2017 14:32:04 -0800
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>
Cc:     Miroslav Lichvar <mlichvar@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Richard Cochran <richardcochran@...il.com>,
        Jiri Benc <jbenc@...hat.com>, Denny Page <dennypage@...com>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: Extending socket timestamping API for NTP

>> 2) new SO_TIMESTAMPING option to receive from the error queue only
>>    user data as was passed to sendmsg() instead of Ethernet frames
>>
>>    Parsing Ethernet and IP headers (especially IPv6 options) is not
>>    fun and SOF_TIMESTAMPING_OPT_ID is not always practical, e.g. in
>>    applications which process messages from the error queue
>>    asynchronously and don't bind/connect their sockets.
>
> This would be useful for application writing.

What kind of user data are you suggesting? Just a user-defined ID
passed as a cmsg? Allowing such metadata to override
skb_shinfo(skb)->tskey sounds fine.

>> 3) target address in msg_name of messages from the error queue
>>
>>    With 2) and unconnected sockets, there needs to be a way to get the
>>    address to which the packet was sent. Is it ok to always fill
>>    msg_name, or does it need to be a new option?
>
>
> I'm not sure.

This would be an argument to just loop the original packet.

>> 4) allow sockets to use both SW and HW TX timestamping at the same time
>>
>>    When using a socket which is not bound to a specific interface, it
>>    would be nice to get transmit SW timestamps when HW timestamps are
>>    missing. I suspect it's difficult to predict if a HW timestamp will
>>    be available. Maybe it would be acceptable to get from the error
>>    queue two messages per transmission if the interface supports both
>>    SW and HW timestamping?
>
>
> This seems useful,

Agreed, as long as it is optional so that it does not change the
behavior for existing applications.

> but not sure how best to implement it.

It might be sufficient to just remove the second line in sw_tx_timestamp

static inline void sw_tx_timestamp(struct sk_buff *skb)
{
        if (skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP &&
            !(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS))
                skb_tstamp_tx(skb, NULL);
}