Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <e7f0449a-2bad-99ad-4737-016a0e6b8b84@gmail.com>
Date:   Fri, 5 Nov 2021 01:22:28 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: [PATCH v2 01/25] tcp: authopt: Initial support and key management
Content-Language: en-US
To:     Leonard Crestez <cdleonard@gmail.com>
Cc:     "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>,
        Francesco Ruggeri <fruggeri@arista.com>,
        Mat Martineau <mathew.j.martineau@linux.intel.com>,
        Christoph Paasch <cpaasch@apple.com>,
        Ivan Delalande <colona@arista.com>,
        Priyaranjan Jha <priyarjha@google.com>, netdev@vger.kernel.org,
        linux-crypto@vger.kernel.org, linux-kselftest@vger.kernel.org,
        linux-kernel@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
        Shuah Khan <shuah@kernel.org>, David Ahern <dsahern@kernel.org>
References: <cover.1635784253.git.cdleonard@gmail.com>
 <51044c39f2e4331f2609484d28c756e2a9db5144.1635784253.git.cdleonard@gmail.com>
From:   Dmitry Safonov <0x7f454c46@gmail.com>
In-Reply-To: <51044c39f2e4331f2609484d28c756e2a9db5144.1635784253.git.cdleonard@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Leonard,

On 11/1/21 16:34, Leonard Crestez wrote:
[..]
> +struct tcp_authopt_key {
> +	/** @flags: Combination of &enum tcp_authopt_key_flag */
> +	__u32	flags;
> +	/** @send_id: keyid value for send */
> +	__u8	send_id;
> +	/** @recv_id: keyid value for receive */
> +	__u8	recv_id;
> +	/** @alg: One of &enum tcp_authopt_alg */
> +	__u8	alg;
> +	/** @keylen: Length of the key buffer */
> +	__u8	keylen;
> +	/** @key: Secret key */
> +	__u8	key[TCP_AUTHOPT_MAXKEYLEN];
> +	/**
> +	 * @addr: Key is only valid for this address
> +	 *
> +	 * Ignored unless TCP_AUTHOPT_KEY_ADDR_BIND flag is set
> +	 */
> +	struct __kernel_sockaddr_storage addr;
> +};
[..]
> +/* Free key nicely, for living sockets */
> +static void tcp_authopt_key_del(struct sock *sk,
> +				struct tcp_authopt_info *info,
> +				struct tcp_authopt_key_info *key)
> +{
> +	sock_owned_by_me(sk);
> +	hlist_del_rcu(&key->node);
> +	atomic_sub(sizeof(*key), &sk->sk_omem_alloc);
> +	kfree_rcu(key, rcu);
> +}
[..]
> +#define TCP_AUTHOPT_KEY_KNOWN_FLAGS ( \
> +	TCP_AUTHOPT_KEY_DEL | \
> +	TCP_AUTHOPT_KEY_EXCLUDE_OPTS | \
> +	TCP_AUTHOPT_KEY_ADDR_BIND)
> +
> +int tcp_set_authopt_key(struct sock *sk, sockptr_t optval, unsigned int optlen)
> +{
[..]
> +	/* Delete is a special case: */
> +	if (opt.flags & TCP_AUTHOPT_KEY_DEL) {
> +		info = rcu_dereference_check(tcp_sk(sk)->authopt_info, lockdep_sock_is_held(sk));
> +		if (!info)
> +			return -ENOENT;
> +		key_info = tcp_authopt_key_lookup_exact(sk, info, &opt);
> +		if (!key_info)
> +			return -ENOENT;
> +		tcp_authopt_key_del(sk, info, key_info);
> +		return 0;

I remember we discussed it in RFC, that removing a key that's currently
in use may result in random MKT to be used.

I think, it's possible to make this API a bit more predictable if:
- DEL command fails to remove a key that is current/receive_next;
- opt.flags has CURR/NEXT flag that has corresponding `u8 current_key`
and `u8 receive_next` values. As socket lock is held - that makes
current_key/receive_next change atomic with deletion of an existing key
that might have been in use.

In result user may remove a key that's not in use or has to set new
current/next. Which avoids the issue with random MKT being used to sign
segments.

Thanks,
          Dmitry