linux-kernel - Re: [PATCH net-next 3/5] net: dsa: mv88e6xxx: Let taggers specify a can

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:   Thu, 30 May 2019 17:47:55 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 3/5] net: dsa: mv88e6xxx: Let taggers specify a
 can_timestamp function

On Thu, 30 May 2019 at 17:24, Richard Cochran <richardcochran@...il.com> wrote:
>
> On Thu, May 30, 2019 at 10:42:41AM +0300, Vladimir Oltean wrote:
> > The meta frames generated by the SJA1105 do not contain any seqid.
>
> So this cannot ever work...
>
> > They contain:
> > * A globally programmable DMAC
> > * A globally programmable SMAC
>
> Don't know what these are, but doesn't sound like they uniquely
> identify the original frame.
>
> > * The 0x8 EtherType
> > * A partial (24-bit or 32-bit) RX timestamp
> > * Two bytes from the initial (pre follow-up) frame's DMAC, before the
> > switch mangled those with the source port and switch id. The driver is
> > supposed to patch these bytes from the follow-up back into the initial
> > frame before passing them up the stack.
> > * The source port that generated the meta frame
> > * The switch id that generated the meta frame
>
> None of these match to the original frame uniquely.  Looks like this
> is a dead end.
>

Yes, they don't identify the original frame.
The hardware's line of thinking seems to be "The meta frame is sent
immediately after the trapped frame that triggered the action." (quote
from https://www.nxp.com/docs/en/user-guide/UM10944.pdf).

> I recommend forgetting about these meta frames.  Instead, read out the
> time stamps over MDIO.
>

If there was any other way to retrieve RX timestamps I would have done
it already.

> Thanks,
> Richard