Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3191154pxu; Tue, 8 Dec 2020 06:01:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJxoi7KNt0aSrrpNcMfciHOdzePp8K9falYHqQgLgbn1YmCVkoACEZ1NvnhyAVk50dQmmo5x X-Received: by 2002:a17:907:2d0f:: with SMTP id gs15mr3434942ejc.455.1607436104154; Tue, 08 Dec 2020 06:01:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607436104; cv=none; d=google.com; s=arc-20160816; b=gc9eUX1/rwEFgDO927LN7TFOUIWtcXla/oI2Ks6gGCsQuxkC+QGi2WK9SxxLHntJ/x kmatQQuElWK/75G7yGh+BfywldIH0mXHoiGNjQz+tc6jzuL8dtsjyoPpKkkKHk5RKngh +09lR9lPPxpmG7vgzm+SeN5gGs/58TvwG4aIwj8ZgvMrYSVuDGeQ57hXPpTPqS2dMon4 3D9L15BIZ+B7yiJO5yY15zENqMfBSJXnHUNx1WNzcr7Rpx53RKMVdSZUH4Pl6IuY2l5E F2dEXuohSvrtKGtN/YCBvKJGkIlPcYL2Tmkp1I8GnWF/G8Y2pcoGqYYNU2q16/Yui2j3 knkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date; bh=H1AzWGOPu/LGvC19iT1bRqk2u46ThqcWKYwVJeeM3w4=; b=OgEnPf8U6I5j5vddb3BTokReB6J7+20fvUYCryozXlxtEUDesedaV5aE/PI2j/uOaF 9tDaN5aaEgY7dNJvNNFQob4WBq+A4dFOcHNQf9UcMYApu8CuiKXsgdkYj8DwW8jlL5rf c5FRjIEktErYpwsuLhUnmCgRP9XDo4KrbBfnL6O+4+ckzVH9oEqAahlZR+QuctHsIf5r jcILtw5nPI44N8L5MEl6yM5npSgfg2auVEyy00n3SQYjOKXlMrlaioXNMpUcWNqDcx/a /CNQhfOKV1/GykqBCMEc9wH4v9PFWOCyFhElIKJFCdV8CbRiq96G92p0FMmTDmbMCTqd bbMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i8si1053429edr.271.2020.12.08.06.01.05; Tue, 08 Dec 2020 06:01:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729510AbgLHOA6 (ORCPT + 99 others); Tue, 8 Dec 2020 09:00:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728546AbgLHOA6 (ORCPT ); Tue, 8 Dec 2020 09:00:58 -0500 Received: from orbyte.nwl.cc (orbyte.nwl.cc [IPv6:2001:41d0:e:133a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46829C061749; Tue, 8 Dec 2020 06:00:18 -0800 (PST) Received: from n0-1 by orbyte.nwl.cc with local (Exim 4.94) (envelope-from ) id 1kmdXJ-0006n8-82; Tue, 08 Dec 2020 15:00:13 +0100 Date: Tue, 8 Dec 2020 15:00:13 +0100 From: Phil Sutter To: Nicolas Dichtel Cc: Steffen Klassert , linux-crypto@vger.kernel.org, netfilter-devel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v2] xfrm: interface: Don't hide plain packets from netfilter Message-ID: <20201208140013.GX4647@orbyte.nwl.cc> Mail-Followup-To: Phil Sutter , Nicolas Dichtel , Steffen Klassert , linux-crypto@vger.kernel.org, netfilter-devel@vger.kernel.org, netdev@vger.kernel.org References: <20201207134309.16762-1-phil@nwl.cc> <9d9cb6dc-32a3-ff1a-5111-7688ce7a2897@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9d9cb6dc-32a3-ff1a-5111-7688ce7a2897@6wind.com> Sender: Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hi Nicolas, On Tue, Dec 08, 2020 at 10:02:16AM +0100, Nicolas Dichtel wrote: > Le 07/12/2020 à 14:43, Phil Sutter a écrit : [...] > > diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c > > index aa4cdcf69d471..24af61c95b4d4 100644 > > --- a/net/xfrm/xfrm_interface.c > > +++ b/net/xfrm/xfrm_interface.c > > @@ -317,7 +317,8 @@ xfrmi_xmit2(struct sk_buff *skb, struct net_device *dev, struct flowi *fl) > > skb_dst_set(skb, dst); > > skb->dev = tdev; > > > > - err = dst_output(xi->net, skb->sk, skb); > > + err = NF_HOOK(skb_dst(skb)->ops->family, NF_INET_LOCAL_OUT, xi->net, > skb->protocol must be correctly set, maybe better to use it instead of > skb_dst(skb)->ops->family? skb->protocol holds ETH_P_* values in network byte order, NF_HOOK() expects an NFPROTO_* value, so this would at least not be a simple replacement. Actually I copied the code from xfrm_output_resume() in xfrm_output.c, where skb_dst(skb)->ops is dereferenced without checking as well. Do you think this is risky? > > + skb->sk, skb, NULL, skb_dst(skb)->dev, dst_output); > And here, tdev instead of skb_dst(skb)->dev ? Well yes, tdev was set to dst->dev earlier. Likewise I could use dst directly instead of skb_dst(skb) to simplify the call a bit further. OTOH I like how in the version above it is clear that skb's dst should be used, irrespective of the code above (and any later changes that may receive). No strong opinion though, so if your version is regarded the preferred one, I'm fine with that. Thanks, Phil