netdev - Re: [PATCH net-next v1] net: dsa: mv88e6xxx: Trap PTP traffic

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]

Message-ID: <877dc8xrls.fsf@kmk-computers.de>
Date:   Mon, 13 Dec 2021 19:54:55 +0100
From:   Kurt Kanzenbach <kurt@...-computers.de>
To:     Tobias Waldekranz <tobias@...dekranz.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH net-next v1] net: dsa: mv88e6xxx: Trap PTP traffic

On Sun Dec 12 2021, Tobias Waldekranz wrote:
>> Agreed. Some mechanism is required. Any idea how to implement it? In
>> case of PTP the management/policy entries should take precedence.
>
> One approach would be to create a cache containing all static ATU
> entries. That way we can easily track the owner of each entry. There are
> also major performance advantages of being able to update memberships of
> group entries without having to read the entry back from the ATU
> first. This is especially important once we start handling router ports
> correctly, in which case you have to update all active entries on every
> add/remove.
>
> Before going down that route though, I would suggest getting some
> initial feedback from Andrew.
>
> A complicating factor, no matter the implementation, is the relationship
> between the bridge MDB and all other consumers of ATU entries. As an
> example: If the driver first receives an MDB add for one of the L3 PTP
> groups, and then a user starts up ptp4l, the driver can't then go back
> to the bridge and say "remember that group entry that I said I loaded,
> well I have removed it now". So whatever implementation we choose, I
> think it needs to keep a shadow entry for the MDB that can be
> re-inserted if the corresponding management or policy entry is removed.
>
> You may simply want to allow all consumers to register any given group
> with the cache. The cache would then internally elect the "best" entry
> and install that to the ATU. Sort of what zebra/quagga/FRR does for
> dynamic routing. The priority would probably be something like:
>
> 1. Management entry
> 2. Policy entry
> 3. MDB entry
>
> This should still result in the proper forwarding of a registered groups
> that are shadowed by management or policy entries. The bridge would know
> (via skb->offload_fwd_mark) that the packet had not been forwarded in
> hardware and would fallback to software forwarding. If the policy entry
> was later removed (e.g. PTP was shut down) the MDB entry could be
> reinstalled and offloading resumed.

Thanks. This approach makes sense and should solve the problem at hand.

Thanks,
Kurt