From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: "<netdev@vger.kernel.org>" <netdev@vger.kernel.org>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org,
Jason Baron <jbaron@akamai.com>,
cpaasch@apple.com, David Laight <David.Laight@aculab.com>,
Yuchung Cheng <ycheng@google.com>
Subject: Re: [PATCH v3] net: ipv4: move tcp_fastopen server side code to SipHash library
Date: Tue, 18 Jun 2019 08:56:57 +0200 [thread overview]
Message-ID: <CAKv+Gu9O0YjyftEEQgZqBcTtZ37co5_H1m6s2GCqk+onza7A-g@mail.gmail.com> (raw)
In-Reply-To: <20190618041408.GB2266@sol.localdomain>
On Tue, 18 Jun 2019 at 06:14, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Mon, Jun 17, 2019 at 10:09:33AM +0200, Ard Biesheuvel wrote:
> > diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> > index c23019a3b264..9ea0e71f5c6a 100644
> > --- a/include/linux/tcp.h
> > +++ b/include/linux/tcp.h
> > @@ -58,12 +58,7 @@ static inline unsigned int tcp_optlen(const struct sk_buff *skb)
> >
> > /* TCP Fast Open Cookie as stored in memory */
> > struct tcp_fastopen_cookie {
> > - union {
> > - u8 val[TCP_FASTOPEN_COOKIE_MAX];
> > -#if IS_ENABLED(CONFIG_IPV6)
> > - struct in6_addr addr;
> > -#endif
> > - };
> > + u64 val[TCP_FASTOPEN_COOKIE_MAX / sizeof(u64)];
> > s8 len;
> > bool exp; /* In RFC6994 experimental option format */
> > };
>
> Is it okay that the cookies will depend on CPU endianness?
>
That depends on whether keys shared between hosts with different
endiannesses are expected to produce cookies that can be shared.
> > diff --git a/include/net/tcp.h b/include/net/tcp.h
> > index 96e0e53ff440..184930b02779 100644
> > --- a/include/net/tcp.h
> > +++ b/include/net/tcp.h
> > @@ -1628,9 +1628,9 @@ bool tcp_fastopen_defer_connect(struct sock *sk, int *err);
> >
> > /* Fastopen key context */
> > struct tcp_fastopen_context {
> > - struct crypto_cipher *tfm[TCP_FASTOPEN_KEY_MAX];
> > - __u8 key[TCP_FASTOPEN_KEY_BUF_LENGTH];
> > - struct rcu_head rcu;
> > + __u8 key[TCP_FASTOPEN_KEY_MAX][TCP_FASTOPEN_KEY_LENGTH];
> > + int num;
> > + struct rcu_head rcu;
> > };
>
> Why not use 'siphash_key_t' here? Then the (potentially alignment-violating)
> cast in __tcp_fastopen_cookie_gen_cipher() wouldn't be needed.
>
These data structures are always kmalloc'ed so the alignment is never
violated in practice. But I do take your point. My idea at the time of
the first RFC was that the actual MAC algo should be an implementation
detail, and so the key is just a buffer. However, after Eric pointed
out that setting the same key across different hosts should produce
compatible cookies (module the upgrade scenario), it is true that the
algorithm is an externally visible property, so it might be better to
change this into siphash_key_t[] here.
> > int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
> > void *primary_key, void *backup_key,
> > unsigned int len)
> > @@ -115,11 +75,20 @@ int tcp_fastopen_reset_cipher(struct net *net, struct sock *sk,
> > struct fastopen_queue *q;
> > int err = 0;
> >
> > - ctx = tcp_fastopen_alloc_ctx(primary_key, backup_key, len);
> > - if (IS_ERR(ctx)) {
> > - err = PTR_ERR(ctx);
> > + ctx = kmalloc(sizeof(*ctx), GFP_KERNEL);
> > + if (!ctx) {
> > + err = -ENOMEM;
> > goto out;
> > }
> > +
> > + memcpy(ctx->key[0], primary_key, len);
> > + if (backup_key) {
> > + memcpy(ctx->key[1], backup_key, len);
> > + ctx->num = 2;
> > + } else {
> > + ctx->num = 1;
> > + }
> > +
> > spin_lock(&net->ipv4.tcp_fastopen_ctx_lock);
> > if (sk) {
> > q = &inet_csk(sk)->icsk_accept_queue.fastopenq;
>
> Shouldn't there be a check that 'len == TCP_FASTOPEN_KEY_LENGTH'? I see that
> all callers pass that, but it seems unnecessarily fragile for this to accept
> short lengths and leave uninitialized memory in that case.
>
Sure, I can add back the error handling path the previously handled
any errors from crypto_cipher_setkey() [which would perform the input
length checking in that case]
I'll spin an incremental patch covering the above.
prev parent reply other threads:[~2019-06-18 6:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 8:09 [PATCH v3] net: ipv4: move tcp_fastopen server side code to SipHash library Ard Biesheuvel
2019-06-17 17:00 ` Eric Dumazet
2019-06-17 20:57 ` David Miller
2019-06-17 22:09 ` Eric Dumazet
2019-06-18 4:14 ` Eric Biggers
2019-06-18 6:56 ` Ard Biesheuvel [this message]
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=CAKv+Gu9O0YjyftEEQgZqBcTtZ37co5_H1m6s2GCqk+onza7A-g@mail.gmail.com \
--to=ard.biesheuvel@linaro.org \
--cc=David.Laight@aculab.com \
--cc=cpaasch@apple.com \
--cc=davem@davemloft.net \
--cc=ebiggers@kernel.org \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=jbaron@akamai.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-crypto@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=ycheng@google.com \
--cc=yoshfuji@linux-ipv6.org \
/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).