linux-kernel - Re: [PATCH net-next] wireguard: use rhashtables instead of hashtables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z9r35H2rfLV8m5iW@zx2c4.com>
Date: Wed, 19 Mar 2025 17:59:16 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Dmitrii Ermakov <demonihin@...il.com>
Cc: wireguard@...ts.zx2c4.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] wireguard: use rhashtables instead of hashtables

On Sun, Jan 05, 2025 at 12:00:17PM +0100, Dmitrii Ermakov wrote:
> @@ -74,7 +75,6 @@ struct noise_handshake {
>  	u8 remote_static[NOISE_PUBLIC_KEY_LEN];
>  	u8 remote_ephemeral[NOISE_PUBLIC_KEY_LEN];
>  	u8 precomputed_static_static[NOISE_PUBLIC_KEY_LEN];
> -
>  	u8 preshared_key[NOISE_SYMMETRIC_KEY_LEN];
>  
>  	u8 hash[NOISE_HASH_LEN];
> @@ -83,6 +83,8 @@ struct noise_handshake {
>  	u8 latest_timestamp[NOISE_TIMESTAMP_LEN];
>  	__le32 remote_index;
>  
> +	siphash_key_t hash_seed;

Why?

> +#include "linux/printk.h"
> +#include "linux/rcupdate.h"
> +#include "linux/rhashtable-types.h"
> +#include "linux/rhashtable.h"
> +#include "linux/siphash.h"

Seems wrong.

> +#include "messages.h"
>  #include "peer.h"
>  #include "noise.h"
> +#include "linux/memory.h"

Ditto.

>  
> -static struct hlist_head *pubkey_bucket(struct pubkey_hashtable *table,
> -					const u8 pubkey[NOISE_PUBLIC_KEY_LEN])
> +static inline u32 index_hashfn(const void *data, u32 len, u32 seed)
>  {
> -	/* siphash gives us a secure 64bit number based on a random key. Since
> -	 * the bits are uniformly distributed, we can then mask off to get the
> -	 * bits we need.
> -	 */
> -	const u64 hash = siphash(pubkey, NOISE_PUBLIC_KEY_LEN, &table->key);
> +	const u32 *index = data;
> +	return *index;
> +}

But shouldn't this actually use siphash? What's happening here?

> +struct peer_hash_pubkey {
> +	siphash_key_t key;
> +	u8 pubkey[NOISE_PUBLIC_KEY_LEN];
> +};
> +
> +static inline u32 wg_peer_obj_hashfn(const void *data, u32 len, u32 seed)
> +{
> +	const struct wg_peer *peer = data;
> +	struct peer_hash_pubkey key;
> +	u64 hash;
> +
> +	memcpy(&key.key, &peer->handshake.hash_seed, sizeof(key.key));
> +	memcpy(&key.pubkey, &peer->handshake.remote_static, NOISE_PUBLIC_KEY_LEN);
> +
> +	hash = siphash(&key.pubkey, NOISE_PUBLIC_KEY_LEN, &key.key);

Why this weird construction with this other struct?

I'll stop reading here. There's a lot of strangeness with this patch.
Maybe it's workable with enough care, but I think to review this into
shape, in its current state, would be about the same as just rewriting
it.