netdev - Re: [PATCH net] net: dsa: sja1105: Ensure PTP time for rxtstamp reconstruction is not in the past

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] [day] [month] [year] [list]

Message-Id: <20190930.172201.1744857425959169580.davem@davemloft.net>
Date:   Mon, 30 Sep 2019 17:22:01 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     olteanv@...il.com
Cc:     richardcochran@...il.com, andrew@...n.ch, f.fainelli@...il.com,
        vivien.didelot@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net] net: dsa: sja1105: Ensure PTP time for rxtstamp
 reconstruction is not in the past

From: Vladimir Oltean <olteanv@...il.com>
Date: Sun, 29 Sep 2019 01:08:17 +0300

> Sometimes the PTP synchronization on the switch 'jumps':
 ...
> Background: the switch only offers partial RX timestamps (24 bits) and
> it is up to the driver to read the PTP clock to fill those timestamps up
> to 64 bits. But the PTP clock readout needs to happen quickly enough (in
> 0.135 seconds, in fact), otherwise the PTP clock will wrap around 24
> bits, condition which cannot be detected.
> 
> Looking at the 'max 134217731' value on output line 3, one can see that
> in hex it is 0x8000003. Because the PTP clock resolution is 8 ns,
> that means 0x1000000 in ticks, which is exactly 2^24. So indeed this is
> a PTP clock wraparound, but the reason might be surprising.
> 
> What is going on is that sja1105_tstamp_reconstruct(priv, now, ts)
> expects a "now" time that is later than the "ts" was snapshotted at.
> This, of course, is obvious: we read the PTP time _after_ the partial RX
> timestamp was received. However, the workqueue is processing frames from
> a skb queue and reuses the same PTP time, read once at the beginning.
> Normally the skb queue only contains one frame and all goes well. But
> when the skb queue contains two frames, the second frame that gets
> dequeued might have been partially timestamped by the RX MAC _after_ we
> had read our PTP time initially.
> 
> The code was originally like that due to concerns that SPI access for
> PTP time readout is a slow process, and we are time-constrained anyway
> (aka: premature optimization). But some timing analysis reveals that the
> time spent until the RX timestamp is completely reconstructed is 1 order
> of magnitude lower than the 0.135 s deadline even under worst-case
> conditions. So we can afford to read the PTP time for each frame in the
> RX timestamping queue, which of course ensures that the full PTP time is
> in the partial timestamp's future.
> 
> Fixes: f3097be21bf1 ("net: dsa: sja1105: Add a state machine for RX timestamping")
> Signed-off-by: Vladimir Oltean <olteanv@...il.com>

Applied and queued up for -stable, thanks.