Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp3378531ybd; Tue, 25 Jun 2019 01:19:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqxGZuZff9E0zhYSTapZicXH+cIMOK86aCngkLKhadsyTuoa/9kPyMMnzvHNYyhN6kdoc93V X-Received: by 2002:a17:90a:30cf:: with SMTP id h73mr30851672pjb.42.1561450775124; Tue, 25 Jun 2019 01:19:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561450775; cv=none; d=google.com; s=arc-20160816; b=WwlEnOduWjQgxtjQPrHIrte6qhKjawURpDHqg+4pd/6aMRHU93Ggho5jkt26EO+tgT CtDg5vXT2e+QLvQ1K7zup3SQbu13rGhL3QUuGXLK0P884XCeMPCRMzmOhqK/dl5a/kmX SnXlSIHKMpk3ezglcgkw4MQPPlYMbkeedCGAifzKLiJbODt6Vm2NLf8jbC8BIrqa0Beu CfHgSmhN12px7l2/kVZAjjj2050cLS8B7D5I20VRczqoPmNvRhYAsgeASBrTDCRBGDfc hUJokTj+f4fr0mJpkkhb9xnXZoQ4jZhYn5RSRj0Jgi+QetW3hoA7os3G6Gwrrs+gU1uo Lk0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=H44OptQH8tQFX0955EJkaU4S2nbswM8tA7a7vCpXuME=; b=kkcuHfXZI1kI1W/eXrkUevcsDK+6Zh2ja6ItFGu2iPmj0V/YqRxRAShPHIG7USa0O8 J3FIZUi08LVhRWzDGEmqNRhSFpo0/LQVxfmcNNeCmcC03pbQXYgoAt1XePX7IIrZofWG NYzOm7qy+68KVxoQ1NrIc4aO2dZL6bAUUWUHUWI/remhCS1enql2sfEP5hIZPv/tXUw4 fzm+TtIIMzdP7fx9QES816V6oeliKMIJ1Q+1cfWTapXDe8Xp84u3SrK2HE77kzwmK7pm IFuGZn+VkzvLp3o7VVMFWmD1wGR0DkGqac9jeMAcDoqZUbPzQSD3ulogQ6lFmvp4Zr09 G/mQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q23si6153886pff.103.2019.06.25.01.19.18; Tue, 25 Jun 2019 01:19:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729481AbfFYISE (ORCPT + 99 others); Tue, 25 Jun 2019 04:18:04 -0400 Received: from mail.us.es ([193.147.175.20]:49906 "EHLO mail.us.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727887AbfFYISD (ORCPT ); Tue, 25 Jun 2019 04:18:03 -0400 Received: from antivirus1-rhel7.int (unknown [192.168.2.11]) by mail.us.es (Postfix) with ESMTP id B8867C1A6A for ; Tue, 25 Jun 2019 10:18:01 +0200 (CEST) Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id A07674CA14 for ; Tue, 25 Jun 2019 10:18:01 +0200 (CEST) Received: by antivirus1-rhel7.int (Postfix, from userid 99) id 939DA207DE; Tue, 25 Jun 2019 10:18:01 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on antivirus1-rhel7.int X-Spam-Level: X-Spam-Status: No, score=-108.2 required=7.5 tests=ALL_TRUSTED,BAYES_50, SMTPAUTH_US2,USER_IN_WHITELIST autolearn=disabled version=3.4.1 Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id 6CE66DA4D0; Tue, 25 Jun 2019 10:17:59 +0200 (CEST) Received: from 192.168.1.97 (192.168.1.97) by antivirus1-rhel7.int (F-Secure/fsigk_smtp/550/antivirus1-rhel7.int); Tue, 25 Jun 2019 10:17:59 +0200 (CEST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/antivirus1-rhel7.int) Received: from us.es (sys.soleta.eu [212.170.55.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 1984lsi) by entrada.int (Postfix) with ESMTPSA id 42A5F4265A32; Tue, 25 Jun 2019 10:17:59 +0200 (CEST) Date: Tue, 25 Jun 2019 10:17:58 +0200 X-SMTPAUTHUS: auth mail.us.es From: Pablo Neira Ayuso To: linmiaohe Cc: "kadlec@blackhole.kfki.hu" , "fw@strlen.de" , "davem@davemloft.net" , "kuznet@ms2.inr.ac.ru" , "yoshfuji@linux-ipv6.org" , "netfilter-devel@vger.kernel.org" , "coreteam@netfilter.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dsahern@gmail.com" , Mingfangsen Subject: Re: [PATCH v3] net: netfilter: Fix rpfilter dropping vrf packets by mistake Message-ID: <20190625081758.rgcyo2reabuxxd6e@salvia> References: <30442ee669c44d9db01fb374b73fd2dd@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30442ee669c44d9db01fb374b73fd2dd@huawei.com> User-Agent: NeoMutt/20170113 (1.7.2) X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 19, 2019 at 09:49:04AM +0000, linmiaohe wrote: > > On 2019/6/18 23:58, Pablo Neira Ayuso wrote: > > On Thu, Apr 25, 2019 at 09:43:53PM +0800, linmiaohe wrote: > >> From: Miaohe Lin > >> > >> When firewalld is enabled with ipv4/ipv6 rpfilter, vrf > >> ipv4/ipv6 packets will be dropped because in device is vrf but out > >> device is an enslaved device. So failed with the check of the > >> rpfilter. > >> > >> Signed-off-by: Miaohe Lin > >> --- > >> --- a/net/ipv4/netfilter/ipt_rpfilter.c > >> +++ b/net/ipv4/netfilter/ipt_rpfilter.c > >> @@ -81,6 +81,7 @@ static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par) > >> flow.flowi4_mark = info->flags & XT_RPFILTER_VALID_MARK ? skb->mark : 0; > >> flow.flowi4_tos = RT_TOS(iph->tos); > >> flow.flowi4_scope = RT_SCOPE_UNIVERSE; > >> + flow.flowi4_oif = l3mdev_master_ifindex_rcu(xt_in(par)); > >> > >> return rpfilter_lookup_reverse(xt_net(par), &flow, xt_in(par), > >> --- a/net/ipv6/netfilter/ip6t_rpfilter.c > >> +++ b/net/ipv6/netfilter/ip6t_rpfilter.c > >> @@ -58,7 +58,9 @@ static bool rpfilter_lookup_reverse6(struct net *net, const struct sk_buff *skb, > >> if (rpfilter_addr_linklocal(&iph->saddr)) { > >> lookup_flags |= RT6_LOOKUP_F_IFACE; > >> fl6.flowi6_oif = dev->ifindex; > >> - } else if ((flags & XT_RPFILTER_LOOSE) == 0) > >> + } else if (((flags & XT_RPFILTER_LOOSE) == 0) || > >> + (netif_is_l3_master(dev)) || > >> + (netif_is_l3_slave(dev))) > >> fl6.flowi6_oif = dev->ifindex; > >> > >> rt = (void *)ip6_route_lookup(net, &fl6, skb, lookup_flags); @@ > >> -73,6 +75,12 @@ static bool rpfilter_lookup_reverse6(struct net *net, const struct sk_buff *skb, > >> goto out; > >> } > >> > >> + if (netif_is_l3_master(dev)) { > >> + dev = dev_get_by_index_rcu(dev_net(dev), IP6CB(skb)->iif); > >> + if (!dev) > >> + goto out; > >> + } > > > > So, for the l3 device cases this makes: > > > > #1 ip6_route_lookup() to fetch the route, using the device in xt_in() > > (the _LOOSE flag is ignored for the l3 device case). > > > > #2 If this is a l3dev master, then you make a global lookup for the > > device using IP6CB(skb)->iif. > > > > #3 You check if route matches with the device, using the new device > > from the lookup: > > > > if (rt->rt6i_idev->dev == dev ... > > > > If there is no other way to fix this, OK, that's fair enough. > > > > Still this fix looks a bit tricky to me. > > > > And this assymmetric between the IPv4 and IPv6 codebase looks rare. > > > > Probably someone can explain me this in more detail? I'd appreciate. > > > > Thanks! > > > Thanks for your reply. I will try to explain this in more detail. > Vrf device will pass through netfilter hook twice. One with skb->dev=l3mdev > Slave device and another one with skb->dev=l3mdev master deivce. > If a device is an l3mdev, l3mdev_master_ifindex_rcu will return l3mdev > master device ifindex otherwise 0 . So for non l3mdev cases, v4 version is > as same as the previous one. And for l3mdev cases, flow.flowi4_oif > will be l3mdev master device ifindex, so we can do a fib lookup in l3mdev > domain as expected. Since fib_info_nh_uses_dev help us handle the case with > dev=l3mdev slave or master and XT_RPFILTER_LOOSE do not lookup route > table, we finish v4. > For v6 version we need to set fl6.flowi6_oif as we are supposed to lookup > fib in l3mdev domain even in XT_RPFILTER_LOOSE mode. > And fib result rt->rt6i_idev->dev is l3mdev slave device, we need change > dev to enslaved l3mdev device when dev passed in is l3mdev master device. > The key is l3mdev will pass through netfilter hook twice with skb dev is l3mdev slave > and master . And we need to set flowi6_oif as fib lookup should in the l3mdev > domain. Thanks for explaining. Something must be wrong in all these helper function logic because this new code logic is hard to follow for the IPv6 chunk... Can you explore a more readable fix? So I'm not inclined to quickly take this patch. Thanks.