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: <CAK+XE=mh6Ktka1MJkFzuGk8urJqAtBaaJX4ZfrFEHc+pzN-FVw@mail.gmail.com>
Date:   Mon, 29 Oct 2018 12:54:01 +0000
From:   John Hurley <john.hurley@...ronome.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        oss-drivers@...ronome.com, Jiri Pirko <jiri@...nulli.us>,
        ozsh@...lanox.com, Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Simon Horman <simon.horman@...ronome.com>, avivh@...lanox.com
Subject: Re: [RFC net-next v2 1/8] net: sched: register callbacks for indirect
 tc block binds

On Sun, Oct 28, 2018 at 11:10 AM Or Gerlitz <gerlitz.or@...il.com> wrote:
>
> 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..
>

Hi Or,
The owner stuff just makes it easier for a driver to track the blocks
it has registered for and, in turn, release these when exiting.
We could just leave this up to the driver to ensure it properly cleans
up after itself.
I don't feel that strongly either way.

> > 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?
>

Yes, currently in TC, when you register for rule callbacks to a block
that already has rules, these rules are replayed.
With the indirect block approach we still use the same mechanism for
requesting rule callbacks,

> Or.