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: <f4646b14-5ee9-e18e-8bb0-5087cd4f6cae@iogearbox.net>
Date:   Thu, 30 Sep 2021 09:10:21 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     Pablo Neira Ayuso <pablo@...filter.org>,
        netfilter-devel@...r.kernel.org, davem@...emloft.net,
        netdev@...r.kernel.org, kuba@...nel.org, kadlec@...filter.org,
        fw@...len.de, ast@...nel.org, edumazet@...gle.com, tgraf@...g.ch,
        nevola@...il.com, john.fastabend@...il.com, willemb@...gle.com
Subject: Re: [PATCH nf-next v5 0/6] Netfilter egress hook

On 9/30/21 8:52 AM, Lukas Wunner wrote:
> On Thu, Sep 30, 2021 at 08:08:53AM +0200, Daniel Borkmann wrote:
>> Hm, so in the case of SRv6 users were running into a similar issue
>> and commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6
>> data plane") [0] added a new hook along with a sysctl which defaults
>> the new hook to off.
>>
>> The rationale for it was given as "the hooks are enabled via
>> nf_hooks_lwtunnel sysctl to make sure existing netfilter rulesets
>>   do not break." [0,1]
>>
>> If the suggestion to flag the skb [2] one way or another from the
>> tc forwarding path (e.g. skb bit or per-cpu marker) is not
>> technically feasible, then why not do a sysctl toggle like in the
>> SRv6 case?
> 
> The skb flag *is* technically feasible.  I amended the patches with
> the flag and was going to post them this week, but Pablo beat me to
> the punch and posted his alternative version, which lacks the flag
> but modularizes netfilter ingress/egress processing instead.
> 
> Honestly I think a hodge-podge of config options and sysctl toggles
> is awful and I would prefer the skb flag you suggested.  I kind of
> like your idea of considering tc and netfilter as layers.
> 
> FWIW the finished patches *with* the flag are on this branch:
> https://github.com/l1k/linux/commits/nft_egress_v5
> 
> Below is the "git range-diff" between Pablo's patches and mine
> (just the hunks which pertain to the skb flag, plus excerpts
> from the commit message).
> 
> Would you find the patch set acceptable with this skb flag?

Yes, that looks good to me, thanks Lukas!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ