netdev - Re: tc offload debug-ability

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

Message-ID: <YQlF/bQFKH58wTH2@shredder>
Date:   Tue, 3 Aug 2021 16:34:53 +0300
From:   Ido Schimmel <idosch@...dia.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>
CC:     Vlad Buslov <vladbu@...dia.com>,
        Simon Horman <simon.horman@...igine.com>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "Cong Wang" <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...lanox.com>, <netdev@...r.kernel.org>,
        <oss-drivers@...igine.com>,
        Baowen Zheng <baowen.zheng@...igine.com>,
        Louis Peens <louis.peens@...igine.com>,
        "Jiri Pirko" <jiri@...nulli.us>, Roopa Prabhu <roopa@...dia.com>
Subject: Re: tc offload debug-ability

On Tue, Aug 03, 2021 at 08:50:27AM -0400, Jamal Hadi Salim wrote:
> On 2021-08-03 8:14 a.m., Vlad Buslov wrote:
> > 
> > On Tue 03 Aug 2021 at 15:02, Jamal Hadi Salim <jhs@...atatu.com> wrote:
> 
> [..]
> 
> > > 
> > > So unless i am mistaken Vlad:
> > > a) there is no way to reflect the  details when someone dumps the rules.
> > > b) No notifications sent to the control plane (user space) when the
> > > neighbor updates are offloaded.
> > 
> > Correct.
> > 
> 
> Feels like we can adopt the same mechanics. Although, unless i am
> misreading, it seems Ido's patches cover a slightly different use
> case: not totally synchronous in successfully pushing the rule to
> hardware i.e could be sitting somewhere in firmware on its way to
> the ASIC (and at least your connectx driver seems to only be
> relinquishing control after confirming the update succeeded).
> Am i mistaken Ido?

It is simply that all routes are notified from an atomic context, which
means installation to hardware needs to be deferred. But even if we
solve this case, there are other cases that cannot be solved.

For example, in IPv6 routes can be installed in response to RA packets
from softIRQ context. As another example, you can have several routes
with the same key already installed in the kernel, but only the one with
the lowest metric will be installed in hardware. Once it is deleted (for
example, in response to a netdev event), the kernel will try to install
the route with the higher metric. As a user, you want to get a
notification if this operation failed.

The same problem exists with tc actions, not sure about classifiers. For
example, we can mirror to a gretap to emulate ERSPAN. The hardware
expects all the headers to be specified, which means the path towards
the remote IP must be resolved in the kernel. Due to FIB/neigh/FDB
events it can obviously change, which means that the validity of the
action in hardware (not the classifier) changes over time with zero
visibility to user space.

So I believe that we need to be able to notify user space about the
state of the action. Whether it is in hardware / not in hardware /
failed to be installed to hardware.

> 
> 
> cheers,
> jamal