netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leonard Crestez <cdleonard@gmail.com>
To: Eric Dumazet <edumazet@google.com>
Cc: David Ahern <dsahern@kernel.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Francesco Ruggeri <fruggeri@arista.com>,
	Salam Noureddine <noureddine@arista.com>,
	Philip Paeps <philip@trouble.is>, Shuah Khan <shuah@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Kuniyuki Iwashima <kuniyu@amazon.co.jp>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Yuchung Cheng <ycheng@google.com>,
	Mat Martineau <mathew.j.martineau@linux.intel.com>,
	Christoph Paasch <cpaasch@apple.com>,
	Ivan Delalande <colona@arista.com>,
	Caowangbao <caowangbao@huawei.com>,
	Priyaranjan Jha <priyarjha@google.com>,
	netdev <netdev@vger.kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 01/26] tcp: authopt: Initial support and key management
Date: Wed, 7 Sep 2022 19:19:00 +0300	[thread overview]
Message-ID: <4a47b4ea-750c-a569-5754-4aa0cd5218fc@gmail.com> (raw)
In-Reply-To: <CANn89i+a0mMUMhUhTPoshifNzzuR_gfThPKptB8cuBiw6Bs5jw@mail.gmail.com>

On 9/7/22 01:57, Eric Dumazet wrote:
> On Mon, Sep 5, 2022 at 12:06 AM Leonard Crestez <cdleonard@gmail.com> wrote:
>>
>> This commit adds support to add and remove keys but does not use them
>> further.
>>
>> Similar to tcp md5 a single pointer to a struct tcp_authopt_info* struct
>> is added to struct tcp_sock, this avoids increasing memory usage. The
>> data structures related to tcp_authopt are initialized on setsockopt and
>> only freed on socket close.
>>
> 
> Thanks Leonard.
> 
> Small points from my side, please find them attached.

...

>> +/* Free info and keys.
>> + * Don't touch tp->authopt_info, it might not even be assigned yes.
>> + */
>> +void tcp_authopt_free(struct sock *sk, struct tcp_authopt_info *info)
>> +{
>> +       kfree_rcu(info, rcu);
>> +}
>> +
>> +/* Free everything and clear tcp_sock.authopt_info to NULL */
>> +void tcp_authopt_clear(struct sock *sk)
>> +{
>> +       struct tcp_authopt_info *info;
>> +
>> +       info = rcu_dereference_protected(tcp_sk(sk)->authopt_info, lockdep_sock_is_held(sk));
>> +       if (info) {
>> +               tcp_authopt_free(sk, info);
>> +               tcp_sk(sk)->authopt_info = NULL;
> 
> RCU rules at deletion mandate that the pointer must be cleared before
> the call_rcu()/kfree_rcu() call.
> 
> It is possible that current MD5 code has an issue here, let's not copy/paste it.

OK. Is there a need for some special form of assignment or is current 
plain form enough?

> 
>> +       }
>> +}
>> +
>> +/* checks that ipv4 or ipv6 addr matches. */
>> +static bool ipvx_addr_match(struct sockaddr_storage *a1,
>> +                           struct sockaddr_storage *a2)
>> +{
>> +       if (a1->ss_family != a2->ss_family)
>> +               return false;
>> +       if (a1->ss_family == AF_INET &&
>> +           (((struct sockaddr_in *)a1)->sin_addr.s_addr !=
>> +            ((struct sockaddr_in *)a2)->sin_addr.s_addr))
>> +               return false;
>> +       if (a1->ss_family == AF_INET6 &&
>> +           !ipv6_addr_equal(&((struct sockaddr_in6 *)a1)->sin6_addr,
>> +                            &((struct sockaddr_in6 *)a2)->sin6_addr))
>> +               return false;
>> +       return true;
>> +}
> 
> Always surprising to see this kind of generic helper being added in a patch.

I remember looking for an equivalent and not finding it. Many places 
have distinct code paths for ipv4 and ipv6 and my use of 
"sockaddr_storage" as ipv4/ipv6 union is uncommon.

It also wastes some memory.

>> +int tcp_get_authopt_val(struct sock *sk, struct tcp_authopt *opt)
>> +{
>> +       struct tcp_sock *tp = tcp_sk(sk);
>> +       struct tcp_authopt_info *info;
>> +
>> +       memset(opt, 0, sizeof(*opt));
>> +       sock_owned_by_me(sk);
>> +
>> +       info = rcu_dereference_check(tp->authopt_info, lockdep_sock_is_held(sk));
> 
> Probably not a big deal, but it seems the prior sock_owned_by_me()
> might be redundant.

The sock_owned_by_me call checks checks lockdep_sock_is_held

The rcu_dereference_check call checks lockdep_sock_is_held || 
rcu_read_lock_held()

This is a getsockopt so caller ensures socket locking but 
rcu_read_lock_held() == 0.

The sock_owned_by_me is indeed redundant because it seems very unlikely 
the sockopt calling conditions will be changes. It was mostly there to 
clarify for myself because I had probably at one time with locking 
warnings. I guess they can be removed.

>> +int tcp_set_authopt_key(struct sock *sk, sockptr_t optval, unsigned int optlen)
>> +{
>> +       struct tcp_authopt_key opt;
>> +       struct tcp_authopt_info *info;
>> +       struct tcp_authopt_key_info *key_info, *old_key_info;
>> +       struct netns_tcp_authopt *net = sock_net_tcp_authopt(sk);
>> +       int err;
>> +
>> +       sock_owned_by_me(sk);
>> +       if (!ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN))
>> +               return -EPERM;
>> +
>> +       err = _copy_from_sockptr_tolerant((u8 *)&opt, sizeof(opt), optval, optlen);
>> +       if (err)
>> +               return err;
>> +
>> +       if (opt.flags & ~TCP_AUTHOPT_KEY_KNOWN_FLAGS)
>> +               return -EINVAL;
>> +
>> +       if (opt.keylen > TCP_AUTHOPT_MAXKEYLEN)
>> +               return -EINVAL;
>> +
>> +       /* Delete is a special case: */
>> +       if (opt.flags & TCP_AUTHOPT_KEY_DEL) {
>> +               mutex_lock(&net->mutex);
>> +               key_info = tcp_authopt_key_lookup_exact(sk, net, &opt);
>> +               if (key_info) {
>> +                       tcp_authopt_key_del(net, key_info);
>> +                       err = 0;
>> +               } else {
>> +                       err = -ENOENT;
>> +               }
>> +               mutex_unlock(&net->mutex);
>> +               return err;
>> +       }
>> +
>> +       /* check key family */
>> +       if (opt.flags & TCP_AUTHOPT_KEY_ADDR_BIND) {
>> +               if (sk->sk_family != opt.addr.ss_family)
>> +                       return -EINVAL;
>> +       }
>> +
>> +       /* Initialize tcp_authopt_info if not already set */
>> +       info = __tcp_authopt_info_get_or_create(sk);
>> +       if (IS_ERR(info))
>> +               return PTR_ERR(info);
>> +
>> +       key_info = kmalloc(sizeof(*key_info), GFP_KERNEL | __GFP_ZERO);
> 
> kzalloc() ?

Yes

>> +static int tcp_authopt_init_net(struct net *full_net)
> 
> Hmmm... our convention is to use "struct net *net"
> 
>> +{
>> +       struct netns_tcp_authopt *net = &full_net->tcp_authopt;
> 
> Here, you should use a different name ...

OK, will replace with net_ao

>> @@ -2267,10 +2268,11 @@ void tcp_v4_destroy_sock(struct sock *sk)
>>                  tcp_clear_md5_list(sk);
>>                  kfree_rcu(rcu_dereference_protected(tp->md5sig_info, 1), rcu);
>>                  tp->md5sig_info = NULL;
>>          }
>>   #endif
>> +       tcp_authopt_clear(sk);
> 
> Do we really own the socket lock at this point ?

Not sure how I would tell but there is a lockdep_sock_is_held check 
inside tcp_authopt_clear. I also added sock_owned_by_me and there were 
no warnings.

  reply	other threads:[~2022-09-07 16:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05  7:05 [PATCH v8 00/26] tcp: Initial support for RFC5925 auth option Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 01/26] tcp: authopt: Initial support and key management Leonard Crestez
2022-09-06 22:57   ` Eric Dumazet
2022-09-07 16:19     ` Leonard Crestez [this message]
2022-09-07 16:28       ` Eric Dumazet
2022-09-07 18:09         ` Leonard Crestez
2022-09-08  6:35   ` Paolo Abeni
2022-09-08 10:47     ` Leonard Crestez
2022-09-08 10:53       ` David Ahern
2022-09-05  7:05 ` [PATCH v8 02/26] docs: Add user documentation for tcp_authopt Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 03/26] tcp: authopt: Add crypto initialization Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 04/26] tcp: Refactor tcp_sig_hash_skb_data for AO Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 05/26] tcp: authopt: Compute packet signatures Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 06/26] tcp: Refactor tcp_inbound_md5_hash into tcp_inbound_sig_hash Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 07/26] tcp: authopt: Hook into tcp core Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 08/26] tcp: authopt: Disable via sysctl by default Leonard Crestez
2022-09-06 23:11   ` Eric Dumazet
2022-09-07 16:53     ` Leonard Crestez
2022-09-07 17:04       ` Eric Dumazet
2022-09-07 17:58         ` Leonard Crestez
2022-09-07 22:49     ` Herbert Xu
2022-09-07 22:58       ` Eric Dumazet
2022-09-05  7:05 ` [PATCH v8 09/26] tcp: authopt: Implement Sequence Number Extension Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 10/26] tcp: ipv6: Add AO signing for tcp_v6_send_response Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 11/26] tcp: authopt: Add support for signing skb-less replies Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 12/26] tcp: ipv4: Add AO signing for " Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 13/26] tcp: authopt: Add NOSEND/NORECV flags Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 14/26] tcp: authopt: Add initial l3index support Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 15/26] tcp: authopt: Add prefixlen support Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 16/26] tcp: authopt: Add send/recv lifetime support Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 17/26] tcp: authopt: Add key selection controls Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 18/26] tcp: authopt: Add v4mapped ipv6 address support Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 19/26] tcp: authopt: Add /proc/net/tcp_authopt listing all keys Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 20/26] tcp: authopt: If no keys are valid for send report an error Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 21/26] tcp: authopt: Try to respect rnextkeyid from SYN on SYNACK Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 22/26] tcp: authopt: Initial support for TCP_AUTHOPT_FLAG_ACTIVE Leonard Crestez
2022-09-05  7:05 ` [PATCH v8 23/26] tcp: authopt: Initial implementation of TCP_REPAIR_AUTHOPT Leonard Crestez
2022-09-05  7:06 ` [PATCH v8 24/26] selftests: nettest: Rename md5_prefix to key_addr_prefix Leonard Crestez
2022-09-05  7:06 ` [PATCH v8 25/26] selftests: nettest: Initial tcp_authopt support Leonard Crestez
2022-09-05  7:06 ` [PATCH v8 26/26] selftests: net/fcnal: " Leonard Crestez
2022-09-09 21:41 ` [PATCH v8 00/26] tcp: Initial support for RFC5925 auth option Salam Noureddine
2022-11-28 14:06 ` Leonard Crestez

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=4a47b4ea-750c-a569-5754-4aa0cd5218fc@gmail.com \
    --to=cdleonard@gmail.com \
    --cc=0x7f454c46@gmail.com \
    --cc=caowangbao@huawei.com \
    --cc=colona@arista.com \
    --cc=cpaasch@apple.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=fruggeri@arista.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kuba@kernel.org \
    --cc=kuniyu@amazon.co.jp \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mathew.j.martineau@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=noureddine@arista.com \
    --cc=philip@trouble.is \
    --cc=priyarjha@google.com \
    --cc=shuah@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).