All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: Kyle Zeng <kylebot@openai.com>, edumazet@kernel.org
Cc: netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, dsahern@kernel.org,
	outbounddisclosures@openai.com
Subject: Re: [PATCH net] neighbour: stop using device addresses in hashes
Date: Wed, 7 Oct 2026 11:25:00 +0300	[thread overview]
Message-ID: <20261007082500.GA918849@shredder> (raw)
In-Reply-To: <20261006224118.50200-1-kylebot@openai.com>

On Tue, Oct 06, 2026 at 03:41:18PM -0700, Kyle Zeng wrote:
> RTM_GETNEIGHTBL exposes the live hash multiplier and bucket mask. For
> ARP, that multiplier is applied to the IPv4 key XOR hash32_ptr(dev).
> Since hash32_ptr() merely folds the address, timing chosen-key misses
> through the unprivileged SIOCGARP ioctl can reveal the folded address
> of the loopback net_device. NDISC uses the same address-dependent
> first hash term.
> 
> Give each net_device an independent random neighbour hash discriminator
> at allocation time and use it in both protocol hashes. Keep it immutable
> so that lookups, insertion and rehashing agree even if the device's
> ifindex or network namespace changes. This retains the cross-namespace
> hash distribution that motivated using the device pointer, without
> putting a kernel address into the observable hash. A dedicated value
> also avoids making a salt used by unrelated network hashes observable.
> 
> The existing NDTA_CONFIG fields and neighbour key comparisons can stay
> unchanged. Update the net_device cacheline documentation and assertions
> for the new read-mostly field.
> 
> Fixes: b14f243a42c7 ("net: Dont use ifindices in hash fns")
> Assisted-by: Codex:gpt-6-astra
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
> ---
>  Documentation/networking/net_cachelines/net_device.rst | 1 +
>  include/linux/netdevice.h                              | 2 ++
>  include/net/arp.h                                      | 3 +--
>  include/net/ndisc.h                                    | 3 +--
>  net/core/dev.c                                         | 4 +++-
>  5 files changed, 8 insertions(+), 5 deletions(-)

Eric,

Given [1], do you think this should be targeted at net-next?

In net-next the neighbour tables are per-netns, so we can return to
hashing based on the device index instead of its pointer. Something like
[2].

[1] https://lore.kernel.org/netdev/CAL4WiiqWwV+8JaYjsHrWDvoSt8Ng01xs9Orv4xhRpFAvhMnD6w@mail.gmail.com/
[2]
diff --git a/include/net/arp.h b/include/net/arp.h
index e932def63d62..9e583624f5b2 100644
--- a/include/net/arp.h
+++ b/include/net/arp.h
@@ -4,7 +4,6 @@
 #define _ARP_H
 
 #include <linux/if_arp.h>
-#include <linux/hash.h>
 #include <net/neighbour.h>
 
 static inline struct neigh_table *arp_table(struct net *net)
@@ -15,7 +14,7 @@ static inline struct neigh_table *arp_table(struct net *net)
 static inline u32 arp_hashfn(const void *pkey, const struct net_device *dev, u32 *hash_rnd)
 {
 	u32 key = *(const u32 *)pkey;
-	u32 val = key ^ hash32_ptr(dev);
+	u32 val = key ^ dev->ifindex;
 
 	return val * hash_rnd[0];
 }
diff --git a/include/net/ndisc.h b/include/net/ndisc.h
index 96e3bb6e83af..a97be2e69409 100644
--- a/include/net/ndisc.h
+++ b/include/net/ndisc.h
@@ -54,7 +54,6 @@ enum {
 #include <linux/types.h>
 #include <linux/if_arp.h>
 #include <linux/netdevice.h>
-#include <linux/hash.h>
 
 #include <net/neighbour.h>
 
@@ -355,7 +354,7 @@ static inline u32 ndisc_hashfn(const void *pkey, const struct net_device *dev, _
 {
 	const u32 *p32 = pkey;
 
-	return (((p32[0] ^ hash32_ptr(dev)) * hash_rnd[0]) +
+	return (((p32[0] ^ dev->ifindex) * hash_rnd[0]) +
 		(p32[1] * hash_rnd[1]) +
 		(p32[2] * hash_rnd[2]) +
 		(p32[3] * hash_rnd[3]));


  parent reply	other threads:[~2026-10-07  8:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06 22:41 [PATCH net] neighbour: stop using device addresses in hashes Kyle Zeng
2026-10-06 22:44 ` netdev-bot+sinfo
2026-10-07  8:25 ` Ido Schimmel [this message]
2026-10-07  8:54   ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261007082500.GA918849@shredder \
    --to=idosch@nvidia.com \
    --cc=dsahern@kernel.org \
    --cc=edumazet@kernel.org \
    --cc=kylebot@openai.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=outbounddisclosures@openai.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.