From: Daniel Borkmann <daniel@iogearbox.net>
To: Eric Dumazet <edumazet@google.com>
Cc: David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
m@lambda.lt, Alexei Starovoitov <ast@kernel.org>,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net 1/2] sock: make cookie generation global instead of per netns
Date: Thu, 8 Aug 2019 13:40:01 +0200 [thread overview]
Message-ID: <31e7c59d-a937-d312-476a-8074704d4bf0@iogearbox.net> (raw)
In-Reply-To: <CANn89iLqhYF=JYtNtB25O=0a_tn50dRko3fqvvC-sWTZXuK+0g@mail.gmail.com>
On 8/8/19 1:37 PM, Eric Dumazet wrote:
> On Thu, Aug 8, 2019 at 1:09 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 8/8/19 12:45 PM, Eric Dumazet wrote:
>>> On Thu, Aug 8, 2019 at 11:50 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>>>
>>>> Socket cookie consumers must assume the value as opqaue in any case.
>>>> The cookie does not guarantee an always unique identifier since it
>>>> could wrap in fabricated corner cases where two sockets could end up
>>>> holding the same cookie,
>>>
>>> What do you mean by this ?
>>>
>>> Cookie is guaranteed to be unique, it is from a 64bit counter...
>>>
>>> There should be no collision.
>>
>> I meant the [theoretical] corner case where socket_1 has cookie X and
>> we'd create, trigger sock_gen_cookie() to increment, close socket in a
>> loop until we wrap and get another cookie X for socket_2; agree it's
>> impractical and for little gain anyway. So in practice there should be
>> no collision which is what I tried to say.
>
> If a 64bit counter, updated by one unit at a time could overflow
> during the lifetime of a host,
> I would agree with you, but this can not happen, even if we succeed to
> make 1 billion
> locked increments per second (this would still need 584 years)
>
> I would prefer not mentioning something that can not possibly happen
> in your changelog ;)
Yep fair enough, makes sense. I'll fix it :)
next prev parent reply other threads:[~2019-08-08 11:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 9:49 [PATCH net 0/2] Fix collisions in socket cookie generation Daniel Borkmann
2019-08-08 9:49 ` [PATCH net 1/2] sock: make cookie generation global instead of per netns Daniel Borkmann
2019-08-08 10:45 ` Eric Dumazet
2019-08-08 11:09 ` Daniel Borkmann
2019-08-08 11:37 ` Eric Dumazet
2019-08-08 11:40 ` Daniel Borkmann [this message]
2019-08-08 9:49 ` [PATCH net 2/2] bpf: sync bpf.h to tools infrastructure Daniel Borkmann
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=31e7c59d-a937-d312-476a-8074704d4bf0@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=m@lambda.lt \
--cc=netdev@vger.kernel.org \
--cc=willemb@google.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 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 NNTP newsgroup(s).