From patchwork Fri Aug 11 00:57:00 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Cengiz Can X-Patchwork-Id: 1820081 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=e9yHwX6r; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4RMQPD5djpz1yfH for ; Fri, 11 Aug 2023 10:57:19 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1qUGSm-00020f-KT; Fri, 11 Aug 2023 00:57:12 +0000 Received: from smtp-relay-internal-1.internal ([10.131.114.114] helo=smtp-relay-internal-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1qUGSj-000204-A4 for kernel-team@lists.ubuntu.com; Fri, 11 Aug 2023 00:57:09 +0000 Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id EBA1D3F20F for ; Fri, 11 Aug 2023 00:57:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1691715428; bh=9+fsdiPfUXgEatBYGm2Xp16hPLVvzyaITHRudV779j8=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=e9yHwX6rt8g03knDNHWlAeELsFVG2KD0GDAQ2aihRcXTcUgC9jeArE4rCxIz2i3nB dVwXp7JEPumz0t4pDM8SNabm4FTl+F+1yWPGZHT8MfTH3OImuQl56TqN8yi8s0NYQR 6/90Exhi1afo/zb+m1rpYcxsspZiplhI6xf+8CmlYPmkoZua+s0bP8pPfxjDFpPMug BbEjbg/5dAp4Sjz/kDWMpRHuepV5ep1M28C3GUgRewASGhZllWRIXGno7YR1UUYz4O zmmjaM+diVZKt/q65e+0MlbvTn6q1YmlSTf7s3ye8l4+f4ynWTroZVzoxtlva9CSFs L0NAHBFrals3A== Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2b9ba3d6191so16424451fa.2 for ; Thu, 10 Aug 2023 17:57:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691715428; x=1692320228; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9+fsdiPfUXgEatBYGm2Xp16hPLVvzyaITHRudV779j8=; b=IlHDJiIvmqCEvJ/I92qqj8NN1gibN+cD0tj1F85wogDXhgGaGr9EBq3GWENYr3l42L n5udn7RpQBBgU0IUJM8W7qJlN9hprNSid3wuzbbAc0AjnotHMsDtybR+V+GqQQYkUO/7 /Z5vKkbZcL2GOw/fIQfrd9LCb+t3T7u/24eIY6qxw2JbMqjF0DWZSj9Qpyvio1H5tfEc 9FcfDs//HRdqqDpXj2hC0i0kR8uP9/MTKE4o+F/Le3v7nz7awuXPiN2U/Epad/PEVHHM cq774PUCdRsdxpiDKpJPmtZYi2qqOxcj6O8yesagvXN5WboATUK4JYJ5kIiv4UYAEcSX +oFg== X-Gm-Message-State: AOJu0YxoHct3J20jD1XjlYqzFZ30PCbaMRf1VVG/aG7g+XpEI5Cg1D/4 tu3+GFg+Hk4KTQeyZhCjHkG3mTQDqM2c30bSGFKfijuAX9vST3h0A256VqtLUOdPxZS1CyRGqKN zngyTyJgRrDkx/fRI7C7CGKnJeKhYacW6PpbTMOGx+sJsW5R1RiO8Iwo= X-Received: by 2002:a05:6512:3d1d:b0:4f9:607a:6508 with SMTP id d29-20020a0565123d1d00b004f9607a6508mr187116lfv.50.1691715428088; Thu, 10 Aug 2023 17:57:08 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHL50RV1lSZNu/Cj0M/4QZbHSn1gyVsjN+qZyzJuwDdvWjqsAppM7WA0d6g508dEJ+XzdKRVA== X-Received: by 2002:a05:6512:3d1d:b0:4f9:607a:6508 with SMTP id d29-20020a0565123d1d00b004f9607a6508mr187105lfv.50.1691715427586; Thu, 10 Aug 2023 17:57:07 -0700 (PDT) Received: from localhost ([176.234.219.253]) by smtp.gmail.com with ESMTPSA id j18-20020aa7ca52000000b00522594a614fsm1394791edt.13.2023.08.10.17.57.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Aug 2023 17:57:07 -0700 (PDT) From: Cengiz Can To: kernel-team@lists.ubuntu.com Subject: [SRU Focal/Jammy/HWE-5.19/OEM-6.0/OEM-6.1/Lunar 1/1] tcp: Reduce chance of collisions in inet6_hashfn(). Date: Fri, 11 Aug 2023 03:57:00 +0300 Message-Id: <20230811005700.441021-2-cengiz.can@canonical.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230811005700.441021-1-cengiz.can@canonical.com> References: <20230811005700.441021-1-cengiz.can@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Stewart Smith For both IPv4 and IPv6 incoming TCP connections are tracked in a hash table with a hash over the source & destination addresses and ports. However, the IPv6 hash is insufficient and can lead to a high rate of collisions. The IPv6 hash used an XOR to fit everything into the 96 bits for the fast jenkins hash, meaning it is possible for an external entity to ensure the hash collides, thus falling back to a linear search in the bucket, which is slow. We take the approach of hash the full length of IPv6 address in __ipv6_addr_jhash() so that all users can benefit from a more secure version. While this may look like it adds overhead, the reality of modern CPUs means that this is unmeasurable in real world scenarios. In simulating with llvm-mca, the increase in cycles for the hashing code was ~16 cycles on Skylake (from a base of ~155), and an extra ~9 on Nehalem (base of ~173). In commit dd6d2910c5e0 ("netfilter: conntrack: switch to siphash") netfilter switched from a jenkins hash to a siphash, but even the faster hsiphash is a more significant overhead (~20-30%) in some preliminary testing. So, in this patch, we keep to the more conservative approach to ensure we don't add much overhead per SYN. In testing, this results in a consistently even spread across the connection buckets. In both testing and real-world scenarios, we have not found any measurable performance impact. Fixes: 08dcdbf6a7b9 ("ipv6: use a stronger hash for tcp") Signed-off-by: Stewart Smith Signed-off-by: Samuel Mendoza-Jonas Suggested-by: Eric Dumazet Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20230721222410.17914-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski CVE-2023-1206 (cherry picked from commit d11b0df7ddf1831f3e170972f43186dad520bfcc) Signed-off-by: Cengiz Can --- include/net/ipv6.h | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/include/net/ipv6.h b/include/net/ipv6.h index 03f3af02a9a6..cc93084ac2d1 100644 --- a/include/net/ipv6.h +++ b/include/net/ipv6.h @@ -751,12 +751,8 @@ static inline u32 ipv6_addr_hash(const struct in6_addr *a) /* more secured version of ipv6_addr_hash() */ static inline u32 __ipv6_addr_jhash(const struct in6_addr *a, const u32 initval) { - u32 v = (__force u32)a->s6_addr32[0] ^ (__force u32)a->s6_addr32[1]; - - return jhash_3words(v, - (__force u32)a->s6_addr32[2], - (__force u32)a->s6_addr32[3], - initval); + return jhash2((__force const u32 *)a->s6_addr32, + ARRAY_SIZE(a->s6_addr32), initval); } static inline bool ipv6_addr_loopback(const struct in6_addr *a)