All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: netdev@vger.kernel.org, Vadim Fedorenko <vfedorenko@novek.ru>,
	Frantisek Krenzelok <fkrenzel@redhat.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Kuniyuki Iwashima <kuniyu@amazon.com>,
	Apoorv Kothari <apoorvko@amazon.com>,
	Boris Pismenny <borisp@nvidia.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org, Gal Pressman <gal@nvidia.com>,
	Marcel Holtmann <marcel@holtmann.org>
Subject: Re: [PATCH net-next v3 3/6] tls: implement rekey for TLS1.3
Date: Thu, 10 Aug 2023 19:56:31 +0200	[thread overview]
Message-ID: <ZNUkz7UNMPQVOr2M@vergenet.net> (raw)
In-Reply-To: <c0ef5c0cf4f56d247081ce366eb5de09bf506cf4.1691584074.git.sd@queasysnail.net>

On Wed, Aug 09, 2023 at 02:58:52PM +0200, Sabrina Dubroca wrote:
> This adds the possibility to change the key and IV when using
> TLS1.3. Changing the cipher or TLS version is not supported.
> 
> Once we have updated the RX key, we can unblock the receive side. If
> the rekey fails, the context is unmodified and userspace is free to
> retry the update or close the socket.
> 
> This change only affects tls_sw, since 1.3 offload isn't supported.
> 
> v2:
>  - reverse xmas tree
>  - turn the alt_crypto_info into an else if
>  - don't modify the context when rekey fails
> 
> v3:
>  - only call tls_sw_strparser_arm when setting the initial RX key, not
>    on rekeys
>  - update tls_sk_poll to not say the socket is readable when we're
>    waiting for a rekey, and wake up poll() when the new key is installed
>  - use unsafe_memcpy to make FORTIFY_SOURCE happy
> 
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>

...

> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c

...

> @@ -2873,14 +2911,24 @@ int tls_set_sw_offload(struct sock *sk, int tx)
>  
>  	ctx->push_pending_record = tls_sw_push_pending_record;
>  
> +	/* setkey is the last operation that could fail during a
> +	 * rekey. if it succeeds, we can start modifying the
> +	 * context.
> +	 */
>  	rc = crypto_aead_setkey(*aead, key, keysize);
> +	if (rc) {
> +		if (new_crypto_info)
> +			goto out;
> +		else
> +			goto free_aead;
> +	}
>  
> -	if (rc)
> -		goto free_aead;
> -
> -	rc = crypto_aead_setauthsize(*aead, prot->tag_size);
> -	if (rc)
> -		goto free_aead;
> +	if (!new_crypto_info) {
> +		rc = crypto_aead_setauthsize(*aead, prot->tag_size);
> +		if (rc) {
> +			goto free_aead;
> +		}

nit: no need for {} here.

> +	}
>  
>  	if (sw_ctx_rx) {
>  		tfm = crypto_aead_tfm(sw_ctx_rx->aead_recv);

...

  reply	other threads:[~2023-08-10 17:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-09 12:58 [PATCH net-next v3 0/6] tls: implement key updates for TLS1.3 Sabrina Dubroca
2023-08-09 12:58 ` [PATCH net-next v3 1/6] tls: remove tls_context argument from tls_set_sw_offload Sabrina Dubroca
2023-08-10 17:42   ` Simon Horman
2023-08-09 12:58 ` [PATCH net-next v3 2/6] tls: block decryption when a rekey is pending Sabrina Dubroca
2023-08-10 17:44   ` Simon Horman
2023-08-12  1:37   ` Jakub Kicinski
2023-08-09 12:58 ` [PATCH net-next v3 3/6] tls: implement rekey for TLS1.3 Sabrina Dubroca
2023-08-10 17:56   ` Simon Horman [this message]
2023-08-12  1:43   ` Jakub Kicinski
2023-08-14 15:06     ` Sabrina Dubroca
2023-08-14 15:21       ` Jakub Kicinski
2023-08-14 15:46         ` Sabrina Dubroca
2023-08-09 12:58 ` [PATCH net-next v3 4/6] docs: tls: document TLS1.3 key updates Sabrina Dubroca
2023-08-09 12:58 ` [PATCH net-next v3 5/6] selftests: tls: add key_generation argument to tls_crypto_info_init Sabrina Dubroca
2023-08-09 12:58 ` [PATCH net-next v3 6/6] selftests: tls: add rekey tests Sabrina Dubroca
2023-08-10 17:58   ` Simon Horman
2023-08-14 15:09     ` Sabrina Dubroca

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=ZNUkz7UNMPQVOr2M@vergenet.net \
    --to=horms@kernel.org \
    --cc=apoorvko@amazon.com \
    --cc=borisp@nvidia.com \
    --cc=fkrenzel@redhat.com \
    --cc=gal@nvidia.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@amazon.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=netdev@vger.kernel.org \
    --cc=sd@queasysnail.net \
    --cc=shuah@kernel.org \
    --cc=vfedorenko@novek.ru \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.