netdev - Re: [PATCH net-next rfc 0/6] convert tc

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: <CAF=yD-Lt7yOObrphvqo7PsEDaLCz=P5ku20g8GViNT-d+Bi0og@mail.gmail.com>
Date:   Tue, 3 Jan 2017 12:05:07 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Florian Westphal <fw@...len.de>, dborkman@...earbox.net,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Roman Mashak <mrv@...atatu.com>,
        Hannes Frederic Sowa <hannes@...essinduktion.org>,
        Shmulik Ladkani <shmulik.ladkani@...il.com>
Subject: Re: [PATCH net-next rfc 0/6] convert tc_verd to integer bitfields

> No objections to new year resolution of slimming the skb.
> But: i am still concerned about the recursion that getting rid of
> some of these bits could embolden. i.e my suggestion was infact to
> restore some of those bits taken away by Florian after the ingress
> redirect patches from Shmulik.
>
> The possibilities are: egress->egress, egress->ingress,
> ingress->egress, ingress->ingress. The suggestion was
> xmit_recursion with some skb magic would suffice.
> Hannes promised around last netdevconf that he has a scheme to solve
> it without using any extra skb state.

Are you referring to

"
Personally, I would only try to fix and warn against the easy to detect
cases. It is easy enough to just create a loop with your local attached
L2 which brings your box into a endless loop processing the same packet
again and again. Because it is out of control of the kernel you cannot
do anything at all.

I would just care that we sometimes reschedule and don't do everything
in one stack so we don't corrupt the machine and an admin has still a
chance to solve the problem.
"
https://www.spinics.net/lists/netdev/msg397498.html

That can be solved by extending act_mirred in the same way as
Daniel did for bpf_redirect in a70b506efe89 ("bpf: enforce recursion
limit on redirects").