netdev - Re: Unexpected PACKET_TX

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: <CA+FuTSeR-M56yJbYNeE4j4+4kQ6Mi4P2DrxQAdoFSkvoWKHxJw@mail.gmail.com>
Date:   Fri, 17 Jul 2020 18:50:50 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Matt Sandy <mooseboys@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>
Subject: Re: Unexpected PACKET_TX_TIMESTAMP Messages

On Fri, Jul 17, 2020 at 1:52 PM Matt Sandy <mooseboys@...il.com> wrote:
>
> I've been playing around with raw sockets and timestamps, but seem to
> be getting strange timestamp data back on the errqueue. Specifically,
> if I am creating a socket(AF_PACKET, SOCK_RAW, htons(ETH_P_IP)) and
> requesting SO_TIMESTAMPING_NEW with options 0x4DF. I am not modifying
> the flags with control messages.
>
> On both send and receive, I get the expected
> SOL_SOCKET/SO_TIMESTAMPING_NEW cmsg (in errqueue on send, in the
> message itself on receive), and it contains what appears to be valid
> timestamps in the ts[0] field. On send, however, I receive an
> additional cmsg with level = SOL_PACKET/PACKET_TX_TIMESTAMP, whose
> content is just the fixed value `char[16] { 42, 0, 0, 0, 4, <zeros>
> }`.
>
> Any ideas why I'd be getting the SOL_PACKET message on transmit, and
> why its payload is clearly not a valid timestamp? In case it matters,
> this is on an Intel I210 nic using the igb driver.

This is not a char[16], but a struct sock_extended_err.

The first four bytes correspond to __u32 ee_errno, where 42 is ENOMSG.
The fifth byte is __u8 ee_origin, where 4 corresponds to
SO_EE_ORIGIN_TIMESTAMPING.

This is metadata stored along with the skb by __skb_complete_tx_timestamp.
This helps demultiplex timestamps received from the error queue from
other messages.

Additionally, in the case of timestamps it may include additional
associated information:

        serr->ee.ee_info = tstype;
        serr->opt_stats = opt_stats;
        serr->header.h4.iif = skb->dev ? skb->dev->ifindex : 0;
        if (sk->sk_tsflags & SOF_TIMESTAMPING_OPT_ID) {
                serr->ee.ee_data = skb_shinfo(skb)->tskey;
                if (sk->sk_protocol == IPPROTO_TCP &&
                    sk->sk_type == SOCK_STREAM)
                        serr->ee.ee_data -= sk->sk_tskey;
        }

The fact that the field after ee_origin is zero means that this is a
timestamp captured at device transmit (SCM_TSTAMP_SND), for instance.

The csmg_level and type themselves are chosen on recv errqueue in
packet_recvmsg:

        if (flags & MSG_ERRQUEUE) {
                err = sock_recv_errqueue(sk, msg, len,
                                         SOL_PACKET, PACKET_TX_TIMESTAMP);
                goto out;
        }