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  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 <>
To:     Richard Cochran <>
Cc:     "Keller, Jacob E" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>
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 <> 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.


Powered by blists - more mailing lists