Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp575457rwp; Wed, 12 Jul 2023 19:17:48 -0700 (PDT) X-Google-Smtp-Source: APBJJlFlOIVhugjL7iDq49B7wzz9GH9eXcNJta/4CyK7/T1cIYzs8IuRrR10xtCm//jF9DDDIfyw X-Received: by 2002:a05:6a21:3385:b0:110:f65a:13d7 with SMTP id yy5-20020a056a21338500b00110f65a13d7mr104138pzb.9.1689214668280; Wed, 12 Jul 2023 19:17:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689214668; cv=none; d=google.com; s=arc-20160816; b=nQgVLciEx87S2hTnOHeOjT8/6gc7tVYZ9O9+3bpt0mVD/GNrsgDydcA4fhNDgLUqzL k6Er4FVHgtvbmR6T6yN2dbSpnaLBD9GiAnEp31sbaMhrk+XVcrTT0YTJ60HVn3lulIbf rgDrvHPWxyGO60bviHsNGqbD+Kpw5TgFkjRU1Yd5DSrucXXUVIjpjQxWKUG/vmNKtKfj nvmEcD5BpiNkzde0EtoAj/CBYn/7WczNErz471iAa83p2ZsHVHs2wlNXkg44qXQbw4TA utPNvsf8SVX2ooDxrpt1lvoNJsZ5BCte6Had1TcMqhHo6Y+jMDYaVfIXAcncNG9WpGsX Y0cA== 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=s/2697O0WOZzNU0fxI4+rorreaPiwgOivv5WesbBePc=; fh=itQ2t8mz19cmqyYwcL6VfCewViRguWlK1XvBTPU/fFo=; b=R88KpJdAgGXEsqf2HtXp43TNhfDaEzrVoTqpNF5J4J8jDMFkCjQ284KbS1OfEj2e3X TbLiCKx94u3D3tQjH6i19ZheQ7+pzj10gAYN7uiHm2+O3+CgEq2LOI+DiAw6BjSERToY 8PuSiZWSHsFVStFe/DjUIOGVNbTV23/RjD0FTrYlVQcSmf7GZPcwNLpVB0Jy1p1vZm2z 0Cou3kUwpl7VMC2MPg1Vb+MLhMPsN1L0zqbKjrYuF1pF0YP+uYH7aRYVC7p5ix2vGdNo QKbvf1ggh02qMA4pRMLbuobNQuUdTEyOd7XV7Cfu1nqq5ysEpBmaxHs5yMXCopvQdpU2 JSsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SKwcxAxv; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q16-20020a170902dad000b001b9ed01eb1dsi4364432plx.361.2023.07.12.19.17.36; Wed, 12 Jul 2023 19:17:48 -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=@redhat.com header.s=mimecast20190719 header.b=SKwcxAxv; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233303AbjGMCME (ORCPT + 99 others); Wed, 12 Jul 2023 22:12:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229502AbjGMCMD (ORCPT ); Wed, 12 Jul 2023 22:12:03 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C8FE1FF1 for ; Wed, 12 Jul 2023 19:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689214280; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s/2697O0WOZzNU0fxI4+rorreaPiwgOivv5WesbBePc=; b=SKwcxAxvDpLVvSfTI2RVnLlu5L8bQTVVz7ieSJvP0Rsdd2b3UvLH5X0DVufys582LMXuhp IQqlTCt481UCeQNm6Nl0ELmScPndkVKFsDMbnEyDbqteT2Ul/KDmYQUGADIDrj9FDvEdvJ Dbsav/H5N6wfxly6VF1hz0pkJVRoHH8= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-122-MjUmQG4dNYW16I4xvZIFig-1; Wed, 12 Jul 2023 22:11:19 -0400 X-MC-Unique: MjUmQG4dNYW16I4xvZIFig-1 Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-635e91cba88so1889966d6.0 for ; Wed, 12 Jul 2023 19:11:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689214279; x=1691806279; 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=s/2697O0WOZzNU0fxI4+rorreaPiwgOivv5WesbBePc=; b=a3PYPc44TDQiRAcMMFKnL0Gp+wFjYWbZ8kTCmFD9/HW8ujE3xSwLQfcOxoes5VhO5P +DbKog0ROiMEoOIYcZEXdkaU77d7i/iPw5rkYxCaHTuhagAmE/aQyNUoraIPGjdelev/ cbUiovzEHUtKXxF8ffGZ7bEsyqU1GQxKq6IFDZEvz+jIydyNx9PVvEMjl3lxYApyqj+0 r7MvVAM2VM9peH9b2DyRyxG57HJHftlglOaMyRtztzQKT95S2Uz9ksSvvSoKuj+EoRl+ xlc2olqBbVtDoQB3l153LqH1/HXf+wfFuts98gUBW/74X8ZFQccfhM+FFyypbEDtbYwD B8fw== X-Gm-Message-State: ABy/qLaiMFtFJY3Gabjfme/iP1UjL9I6/XDzxg9i7NIQ4UTTajlpBd6F TuUgGub2MVutHVcxqx/O7GWpay4czRVT2h/hCjlBYuaZJ0mVTSbNE63i9qcmdGp9yqs1myz6yzQ lg5WO8/3mN7nactDBlK40dtzStcdGwzVryUETL9Z3 X-Received: by 2002:a0c:b2c9:0:b0:635:db0c:df78 with SMTP id d9-20020a0cb2c9000000b00635db0cdf78mr339601qvf.3.1689214278890; Wed, 12 Jul 2023 19:11:18 -0700 (PDT) X-Received: by 2002:a0c:b2c9:0:b0:635:db0c:df78 with SMTP id d9-20020a0cb2c9000000b00635db0cdf78mr339582qvf.3.1689214278617; Wed, 12 Jul 2023 19:11:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jason Wang Date: Thu, 13 Jul 2023 10:11:06 +0800 Message-ID: Subject: Re: [PATCH net] gso: fix GSO_DODGY bit handling for related protocols To: Yan Zhai 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_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, 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 Thu, Jul 13, 2023 at 9:55=E2=80=AFAM Yan Zhai wrote= : > > 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 the > egress of later devices, e.g. packets can egress to a vlan device backed > 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 DODGY > 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 bit > 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 packet= s.") > Signed-off-by: Yan Zhai > > --- > [1]: > https://lore.kernel.org/all/CAJPywTKDdjtwkLVUW6LRA2FU912qcDmQOQGt2WaDo28K= zYDg+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, mss)= ; > + 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 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, 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 actu= al gso_segs */ > + skb_shinfo(skb)->gso_segs =3D DIV_ROUND_UP(skb->l= en - 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_bu= ff *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_ROBUST= )) { > + /* Packet is from an untrusted source, re= set actual gso_segs */ > + skb_shinfo(skb)->gso_segs =3D DIV_ROUND_U= P(skb->len - sizeof(*uh), > + = mss); > + skb_shinfo(skb)->gso_type &=3D ~SKB_GSO_D= ODGY; Any reason you want to remove the DODGY here? Is this an optimization? We will lose the chance to recognize/validate it elsewhere. Thanks > + > + segs =3D NULL; > + goto out; > + } else { > + return __udp_gso_segment(skb, features, t= rue); > + } > + } > + > 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_buff = *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 >