public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH 10/10] tcp: Fix small error in tcp_seq_init() time handling
Date: Mon, 7 Nov 2022 19:08:46 +0100	[thread overview]
Message-ID: <20221107190846.32ece8ac@elisabeth> (raw)
In-Reply-To: <20221104084333.3761760-11-david@gibson.dropbear.id.au>

On Fri,  4 Nov 2022 19:43:33 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> It looks like tcp_seq_init() is supposed to advance the sequence number
> by one every 32ns.  However we only right shift the ns part of the timespec
> not the seconds part, meaning that we'll advance by an extra 32 steps on
> each second.
> 
> I don't know if that's exploitable in any way, but it doesn't appear to be
> the intent, nor what RFC 6528 suggests.

Oh, oops, nice catch.

Well, as long as the step, modulo 32 bits, is not 0, it's still
arguably the 250 KHz / 4 µs period clock from RFC 793, so there's no
practical difference (other than the overflow period). See also the
note in RFC 1948:

   More precisely, RFC 793 specifies that the 32-bit counter be
   incremented by 1 in the low-order position about every 4
   microseconds.  Instead, Berkeley-derived kernels increment it by a
   constant every second [...]

I kind of wonder if adding a time non-linearity like the unintended one
I added actually increases entropy.

But indeed ~4 seconds overflow is also not intended, and we should just
stick to RFC 6528.

> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  tcp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tcp.c b/tcp.c
> index 59e03ff..941fafb 100644
> --- a/tcp.c
> +++ b/tcp.c
> @@ -2027,8 +2027,8 @@ static void tcp_seq_init(const struct ctx *c, struct tcp_conn *conn,
>  
>  	seq = siphash_36b((uint8_t *)&in, c->tcp.hash_secret);
>  
> -	ns = now->tv_sec * 1E9;
> -	ns += now->tv_nsec >> 5; /* 32ns ticks, overflows 32 bits every 137s */
> +	/* 32ns ticks, overflows 32 bits every 137s */
> +	ns = (now->tv_sec * 1E9 + now->tv_nsec) >> 5;
>  
>  	conn->seq_to_tap = seq + ns;
>  }

-- 
Stefano


  reply	other threads:[~2022-11-07 18:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-04  8:43 [PATCH 00/10] RFC: Preliminaries for using share IPv4 & IPv6 sockets David Gibson
2022-11-04  8:43 ` [PATCH 01/10] tcp: no v6 flag in ref David Gibson
2022-11-07 18:07   ` Stefano Brivio
2022-11-08  0:35     ` David Gibson
2022-11-04  8:43 ` [PATCH 02/10] tcp: Helper to encode IPv4-mapped IPv6 addresses David Gibson
2022-11-07 18:08   ` Stefano Brivio
2022-11-08  0:46     ` David Gibson
2022-11-04  8:43 ` [PATCH 03/10] tcp: Partially unify IPv4 and IPv6 paths in tcp_hash_match() David Gibson
2022-11-07 18:08   ` Stefano Brivio
2022-11-08  0:51     ` David Gibson
2022-11-04  8:43 ` [PATCH 04/10] tcp: Hash IPv4 and IPv4-mapped-IPv6 addresses the same David Gibson
2022-11-04  8:43 ` [PATCH 05/10] tcp: Take tcp_hash_insert() address from struct tcp_conn David Gibson
2022-11-04  8:43 ` [PATCH 06/10] tcp: Unify IPv4 and IPv6 paths for hashing and matching David Gibson
2022-11-04  8:43 ` [PATCH 07/10] tcp: Remove ugly address union from struct tcp_conn David Gibson
2022-11-07 18:08   ` Stefano Brivio
2022-11-08  0:54     ` David Gibson
2022-11-04  8:43 ` [PATCH 08/10] tcp: Unify initial sequence numbers for IPv4 and IPv6 David Gibson
2022-11-04  8:43 ` [PATCH 09/10] tcp: Have tcp_seq_init() take its parameters from struct tcp_conn David Gibson
2022-11-04  8:43 ` [PATCH 10/10] tcp: Fix small error in tcp_seq_init() time handling David Gibson
2022-11-07 18:08   ` Stefano Brivio [this message]
2022-11-08  0:59     ` David Gibson
2022-11-04  8:47 ` [PATCH 00/10] RFC: Preliminaries for using share IPv4 & IPv6 sockets Stefano Brivio

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=20221107190846.32ece8ac@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=passt-dev@passt.top \
    /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.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).