Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp617697rwp; Wed, 12 Jul 2023 20:26:27 -0700 (PDT) X-Google-Smtp-Source: APBJJlHDxj3+RBjrn8Wf19rSZ+hm9chi8oYLhx7aTQUJgQbBfSM2v7/rr6bPhO10PT+2hpLvGw68 X-Received: by 2002:a17:906:4698:b0:991:e695:cb7 with SMTP id a24-20020a170906469800b00991e6950cb7mr147597ejr.68.1689218786948; Wed, 12 Jul 2023 20:26:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689218786; cv=none; d=google.com; s=arc-20160816; b=VZBr/7epOkndfvUcxntpdnoXtmUU/mkrk25kQWt4wJlXExmaWiz1Pnbbom/TCAvmsY f+PPHjz9D33LpZYv6SOrjmgnABpZVKGD+iKPJKFvVCOyHabZ9DJV6oZI5uP84Fnfctjx 4qhWZhsA9fsgGeceEixn3Kgix0rkwzZFW2QNllZ77BuByDGu085tuRvXzwpFitbAed2+ S5n87UVmUkbVAsz5Z7s/Z3+FO5OVkyAGxDbc+GQguz5OTRl3MHWyhj2aNHLBWN+DwAAB Mb472wHmNai+rxxFA2iP5qcvC+pkviGbvOgJhfsZu/NpPFhI+zf6rNEmurvpdR/2QBoV pQww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=IecoBnL3XyIII1YUKthdlwZVWgMfN+WSwTXEvMXpAAc=; fh=M3IpMvhlhxuCUarBoPR6FU7G55FEaa3Q7MqwXBhJEwQ=; b=T3h8DTakpthPZWhzov5ZPm/KurNWUQ6SfWBhvotzsaT/Sat0Apss2LhOG1SgBJMfMr b/yEz2Q6+rd7/e2uRrfpW9OlYJ9pp787k63aQ98ThkF1wPFRIDNH+U5D1gRioswRxHQ4 LesxFb4SXjckEHD4K1vYTJSTHQa8+DmsVnJcNcJPT5keciCOMWD9emiRxobnakGu7eeu +hld+S4YrbdTN7BApXWN8gswBJTeHb9KPE12Mi479X7fs1WLIwhGn9V8y195EN0K7dZE /aruC6JGlqtm/aqHqtAsadYKB2Cic2D+4OkokPY0UJLpc500Ra2rK2NQSRn4bvaNNJfq 8SlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cloudflare.com header.s=google header.b="bLR9ff/i"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cloudflare.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a17-20020a170906191100b00991c46d0bb6si6041632eje.93.2023.07.12.20.26.02; Wed, 12 Jul 2023 20:26:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@cloudflare.com header.s=google header.b="bLR9ff/i"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=cloudflare.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233460AbjGMC6l (ORCPT + 99 others); Wed, 12 Jul 2023 22:58:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232553AbjGMC6j (ORCPT ); Wed, 12 Jul 2023 22:58:39 -0400 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F8B71BD5 for ; Wed, 12 Jul 2023 19:58:37 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-3fbf1b82d9cso1225635e9.2 for ; Wed, 12 Jul 2023 19:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; t=1689217116; x=1691809116; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=IecoBnL3XyIII1YUKthdlwZVWgMfN+WSwTXEvMXpAAc=; b=bLR9ff/iU7Qh+jYE5Hn0f3gU2ARjNAMtUeyivM+ysA2pnw47A422RZCp0PF5iVK3HY G8/1qL75M5iMrTsnguDtEph+B5emY4Jkw0NU9RQCPy1XixnI0qlo58yx352pmzdGbshz kWEzy2c/1gjGeYvjAvlFu8SVweO8HUAtitkjk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689217116; x=1691809116; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IecoBnL3XyIII1YUKthdlwZVWgMfN+WSwTXEvMXpAAc=; b=ZGLNJQypzlW1XAQh3z1A4FBCJDAkFvZHZ2yrxUA8cjsjAB3NsMZMBs166ouB57NArr 6cHjf6ne1WvZ9uGjtq6qquutpA1X1azke4eVTiB3BeDxCNWC45I9l6af7OINlkw7Kusz qvdZh+5jm49JGVavjj4pNTEXGUrHhQWjJmVkjUU4S73aHqYzYV4zSFq+M32dmQ1vSkS8 fgiPb5Jd9QaUFEhDM0N8hJFL9LutIDx5lItScM2T2IMn1/euTnHb4U8WQxE5bR8O6Swt Q0m6t2EksN602TV29MoQJuu4nEbP0I4CTyDcyw4sQL5rs69gJsBs1hhIDjOs6VrH+VE2 tuyQ== X-Gm-Message-State: ABy/qLbEMXzOCiKXFIHL6i6fRZE84rXcOIbd7hlcgLMtAiWysPBiJtOr McwTY1b8S+JY5H1vQiiZ2hi7RxoF+VSijrpD5fQcpA== X-Received: by 2002:adf:eeca:0:b0:314:183f:7ac0 with SMTP id a10-20020adfeeca000000b00314183f7ac0mr204705wrp.43.1689217115974; Wed, 12 Jul 2023 19:58:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yan Zhai Date: Wed, 12 Jul 2023 21:58:25 -0500 Message-ID: Subject: Re: [PATCH net] gso: fix GSO_DODGY bit handling for related protocols To: Jason Wang Cc: "open list:NETWORKING [TCP]" , kernel-team@cloudflare.com, Eric Dumazet , "David S. Miller" , David Ahern , Jakub Kicinski , Paolo Abeni , Marcelo Ricardo Leitner , Xin Long , Herbert Xu , Andrew Melnychenko , Willem de Bruijn , open list , "open list:SCTP PROTOCOL" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 12, 2023 at 9:11=E2=80=AFPM Jason Wang wr= ote: > > On Thu, Jul 13, 2023 at 9:55=E2=80=AFAM Yan Zhai wro= te: > > > > SKB_GSO_DODGY bit indicates a GSO packet comes from an untrusted source= . > > The canonical way is to recompute the gso_segs to avoid device driver > > issues. Afterwards, the DODGY bit can be removed to avoid re-check at t= he > > egress of later devices, e.g. packets can egress to a vlan device backe= d > > by a real NIC. > > > > Commit 1fd54773c267 ("udp: allow header check for dodgy GSO_UDP_L4 > > packets.") checks DODGY bit for UDP, but for packets that can be fed > > directly to the device after gso_segs reset, it actually falls through > > to fragmentation [1]. > > > > Commit 90017accff61 ("sctp: Add GSO support") and commit 3820c3f3e417 > > ("[TCP]: Reset gso_segs if packet is dodgy") both didn't remove the DOD= GY > > bit after recomputing gso_segs. > > If we try to fix two issues, we'd better use separate patches. > > > > > This change fixes the GSO_UDP_L4 handling case, and remove the DODGY bi= t > > at other places. > > > > Fixes: 90017accff61 ("sctp: Add GSO support") > > Fixes: 3820c3f3e417 ("[TCP]: Reset gso_segs if packet is dodgy") > > Fixes: 1fd54773c267 ("udp: allow header check for dodgy GSO_UDP_L4 pack= ets.") > > Signed-off-by: Yan Zhai > > > > --- > > [1]: > > https://lore.kernel.org/all/CAJPywTKDdjtwkLVUW6LRA2FU912qcDmQOQGt2WaDo2= 8KzYDg+A@mail.gmail.com/ > > > > --- > > net/ipv4/tcp_offload.c | 1 + > > net/ipv4/udp_offload.c | 19 +++++++++++++++---- > > net/ipv6/udp_offload.c | 19 +++++++++++++++---- > > net/sctp/offload.c | 2 ++ > > 4 files changed, 33 insertions(+), 8 deletions(-) > > > > diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c > > index 8311c38267b5..f9b93708c22e 100644 > > --- a/net/ipv4/tcp_offload.c > > +++ b/net/ipv4/tcp_offload.c > > @@ -87,6 +87,7 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb, > > /* Packet is from an untrusted source, reset gso_segs. = */ > > > > skb_shinfo(skb)->gso_segs =3D DIV_ROUND_UP(skb->len, ms= s); > > + skb_shinfo(skb)->gso_type &=3D ~SKB_GSO_DODGY; > > > > segs =3D NULL; > > goto out; > > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c > > index 75aa4de5b731..bd29cf19bb6b 100644 > > --- a/net/ipv4/udp_offload.c > > +++ b/net/ipv4/udp_offload.c > > @@ -388,11 +388,22 @@ static struct sk_buff *udp4_ufo_fragment(struct s= k_buff *skb, > > if (!pskb_may_pull(skb, sizeof(struct udphdr))) > > goto out; > > > > - if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4 && > > - !skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) > > - return __udp_gso_segment(skb, features, false); > > - > > mss =3D skb_shinfo(skb)->gso_size; > > + > > + if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4) { > > + if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) { > > + /* Packet is from an untrusted source, reset ac= tual gso_segs */ > > + skb_shinfo(skb)->gso_segs =3D DIV_ROUND_UP(skb-= >len - sizeof(*uh), > > + mss); > > + skb_shinfo(skb)->gso_type &=3D ~SKB_GSO_DODGY; > > + > > + segs =3D NULL; > > + goto out; > > + } else { > > + return __udp_gso_segment(skb, features, false); > > I think it's better and cleaner to move those changes in > __udp_gso_segment() as Willem suggests. > > > + } > > + } > > + > > if (unlikely(skb->len <=3D mss)) > > goto out; > > > > diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c > > index ad3b8726873e..6857d9f7bd06 100644 > > --- a/net/ipv6/udp_offload.c > > +++ b/net/ipv6/udp_offload.c > > @@ -43,11 +43,22 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_= buff *skb, > > if (!pskb_may_pull(skb, sizeof(struct udphdr))) > > goto out; > > > > - if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4 && > > - !skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) > > - return __udp_gso_segment(skb, features, true); > > - > > mss =3D skb_shinfo(skb)->gso_size; > > + > > + if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4) { > > + if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBU= ST)) { > > + /* Packet is from an untrusted source, = reset actual gso_segs */ > > + skb_shinfo(skb)->gso_segs =3D DIV_ROUND= _UP(skb->len - sizeof(*uh), > > + = mss); > > + skb_shinfo(skb)->gso_type &=3D ~SKB_GSO= _DODGY; > > Any reason you want to remove the DODGY here? Is this an optimization? > We will lose the chance to recognize/validate it elsewhere. > It is intended as a small optimization. And this is in fact the piece I am not fully confident about: after validating the gso_segs at a trusted location (i.e. assuming the kernel is the trusted computing base), do we need to validate it somewhere else? For example, in our scenario, we have a tun/tap device in a net namespace, so the packet going out will enter from the tap, get forwarded through an veth, and then a vlan backed by a real ethernet interface. If the bit is carried over, then at each egress of these devices, we need to enter the GSO code, which feels pretty redundant as long as the packet does not leave kernel space. WDYT? thanks > Thanks > > > + > > + segs =3D NULL; > > + goto out; > > + } else { > > + return __udp_gso_segment(skb, features,= true); > > + } > > + } > > + > > if (unlikely(skb->len <=3D mss)) > > goto out; > > > > diff --git a/net/sctp/offload.c b/net/sctp/offload.c > > index 502095173d88..3d2b44db0d42 100644 > > --- a/net/sctp/offload.c > > +++ b/net/sctp/offload.c > > @@ -65,6 +65,8 @@ static struct sk_buff *sctp_gso_segment(struct sk_buf= f *skb, > > skb_walk_frags(skb, frag_iter) > > pinfo->gso_segs++; > > > > + pinfo->gso_type &=3D ~SKB_GSO_DODGY; > > + > > segs =3D NULL; > > goto out; > > } > > -- > > 2.30.2 > > > --=20 Yan