netdev - Re: [PATCH net-next 3/3] docs: networking: timestamping: add a set of frequently asked questions

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]

Date:   Mon, 20 Jul 2020 17:15:20 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Jacob Keller <jacob.e.keller@...el.com>, kuba@...nel.org,
        davem@...emloft.net, netdev@...r.kernel.org, sorganov@...il.com,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next 3/3] docs: networking: timestamping: add a set
 of frequently asked questions

On Tue, Jul 21, 2020 at 12:05:18AM +0300, Vladimir Oltean wrote:
> 
> Yes, the problematic cases have to do with stacked PHCs (DSA, PHY). The
> pattern is that:
> - DSA sets SKBTX_IN_PROGRESS

Nit: DSA should _not_ set this bit (but a PHY/MII device should).

> - calls dev_queue_xmit towards the MAC driver
> - MAC driver sees SKBTX_IN_PROGRESS, thinks it's the one who set it
> - MAC driver delivers TX timestamp
> - DSA ends poll or receives TX interrupt, collects its timestamp, and
>   delivers a second TX timestamp

> So it's very far from obvious that setting this flag is 'the prevailing
> convention'. For a MAC driver, that might well be, but for DSA/PHY,
> there seem to be risks associated with doing that, and driver writers
> should know what they're signing up for.

The flag only exists to prevent the stack from delivering SW time
stamps when HW time stamps are active.  If an interface doesn't
provide SW time stamps (like DSA interfaces), then there is no need to
set the flag.

For MAC and PHY/MII time stamping, they must co-operate, meaning that
the MAC driver must be prepared to deal with the fact that the PHY/MII
might set this flag.  Many MAC drivers don't do this correctly, but
there are very few PHY/MII actually in use, and so very few authors of
MAC drivers have paid attention to this.

Thanks,
Richard