netdev - Re: [RFC net-next v2 1/8] net: sched: register callbacks for indirect tc block binds

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: <CAJ3xEMjdcDcoEQ=C7S7tBp=8+1AMyoSF1JAnVq7wApiHxk0STA@mail.gmail.com>
Date:   Sun, 28 Oct 2018 13:10:39 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     John Hurley <john.hurley@...ronome.com>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        oss-drivers@...ronome.com, Jiri Pirko <jiri@...nulli.us>,
        Oz Shlomo <ozsh@...lanox.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Aviv Heller <avivh@...lanox.com>
Subject: Re: [RFC net-next v2 1/8] net: sched: register callbacks for indirect
 tc block binds

On Thu, Oct 25, 2018 at 3:28 PM John Hurley <john.hurley@...ronome.com> wrote:
> Currently drivers can register to receive TC block bind/unbind callbacks
> by implementing the setup_tc ndo in any of their given netdevs. However,
> drivers may also be interested in binds to higher level devices (e.g.
> tunnel drivers) to potentially offload filters applied to them.

> Introduce indirect block devs which allows drivers to register callbacks
> for block binds on other devices. The calling driver is expected to
> reference an 'owner' struct that it will pass to all block registrations.
> This is used to track the callbacks from a given driver and free them if
> the driver is removed while the upper level device is still active.

Hi John,

Maybe it would be better to follow the trusted environment model of the kernel
and not protect the core from driver bugs? If the driver does things right they
will unregister before bailing out and if not, they will have to fix..

> Freeing a callback will also trigger an unbind event (if necessary) to
> direct the driver to remove any offloaded rules and unreg any block filter
> callbacks.

> Allow registering an indirect block dev callback for a device that is
> already bound to a block. In this case (if it is an ingress block),
> register and also trigger the callback meaning that any already installed
> rules can be replayed to the calling driver.

not just can be replayed.. they will be replayed, but through an
existing (tc re-offload?)
facility, correct?

Or.