[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190618182253.GK184520@gmail.com>
Date: Tue, 18 Jun 2019 11:22:54 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: netdev@...r.kernel.org, linux-crypto@...r.kernel.org,
herbert@...dor.apana.org.au, edumazet@...gle.com,
davem@...emloft.net, kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
jbaron@...mai.com, cpaasch@...le.com, David.Laight@...lab.com,
ycheng@...gle.com
Subject: Re: [PATCH 2/2] net: fastopen: use endianness agnostic
representation of the cookie
On Tue, Jun 18, 2019 at 11:32:07AM +0200, Ard Biesheuvel wrote:
> Use an explicit little endian representation of the fastopen
> cookie, so that the value no longer depends on the endianness
> of the system. This fixes a theoretical issue only, since
> fastopen keys are unlikely to be shared across load balancing
> server farms that are mixed in endiannes, but it might pop up
> in validation/selftests as well, so let's just settle on little
> endian across the board.
>
> Note that this change only affects big endian systems.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
> ---
> include/linux/tcp.h | 2 +-
> net/ipv4/tcp_fastopen.c | 16 ++++++++--------
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
What about the TCP_FASTOPEN_KEY option for setsockopt and getsockopt? Those
APIs treat the key as an array of bytes (let's say it's little endian), so
doesn't it need to be converted to/from the CPU endianness of siphash_key_t?
- Eric
Powered by blists - more mailing lists