netdev - Re: [PATCH net] net: dsa: sja1105: Fix double delivery of TX timestamps to socket error queue

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Dec 2019 17:30:09 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     "Keller, Jacob E" <jacob.e.keller@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net] net: dsa: sja1105: Fix double delivery of TX
 timestamps to socket error queue

On Fri, 27 Dec 2019 at 17:19, Richard Cochran <richardcochran@...il.com> wrote:
>
> On Thu, Dec 26, 2019 at 05:52:32PM -0800, Richard Cochran wrote:
> > On Thu, Dec 26, 2019 at 08:24:19PM +0200, Vladimir Oltean wrote:
> > > How will these drivers not transmit a second hw TX timestamp to the
> > > stack, if they don't check whether TX timestamping is enabled for
> > > their netdev?
> >
> > Ah, so they are checking SKBTX_HW_TSTAMP on the socket without
> > checking for HWTSTAMP first?
>
> Thinking a bit more about this, MAC drivers should not attempt any
> time stamping unless that functionality has been enabled at the device
> level using HWTSTAMP.  This is the user space API.
>
> So, if you want to fix those drivers, you can submit patches with the
> above justification.  That is a stronger argument than saying it
> breaks DSA drivers!
>
> Thanks,
> Richard

But in the case that I _do_ care about, it _is_ caused by DSA. The
gianfar driver is not expecting anybody else to set SKBTX_IN_PROGRESS,
which in itself is not illegal, whether or not you argue that it is
needed or not.
For the rest of the drivers, sure, they commit even more flagrant API
breaches, such as not checking previous calls of the HWTSTAMP ioctl.
But the flagrant issues are at least easier to catch (aka PTP is never
going to work), so I'm not as concerned about them, as long as user
space (e.g. ptp4l) has the necessary checks in place to detect such
error conditions.

Thanks.
-Vladimir