From: Jakub Kicinski <kuba@kernel.org>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: netdev@vger.kernel.org, Vadim Fedorenko <vfedorenko@novek.ru>,
Frantisek Krenzelok <fkrenzel@redhat.com>,
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>,
Simon Horman <horms@kernel.org>
Subject: Re: [PATCH net-next v4 1/6] tls: block decryption when a rekey is pending
Date: Tue, 3 Dec 2024 19:47:01 -0800 [thread overview]
Message-ID: <20241203194701.48e74c8e@kernel.org> (raw)
In-Reply-To: <327cb575d15fa5c5379f9c38a5132d78953fb648.1731597571.git.sd@queasysnail.net>
On Thu, 14 Nov 2024 16:50:48 +0100 Sabrina Dubroca wrote:
> +static int tls_check_pending_rekey(struct tls_context *ctx, struct sk_buff *skb)
> +{
> + const struct tls_msg *tlm = tls_msg(skb);
> + const struct strp_msg *rxm = strp_msg(skb);
> + char hs_type;
> + int err;
> +
> + if (likely(tlm->control != TLS_RECORD_TYPE_HANDSHAKE))
> + return 0;
> +
> + if (rxm->full_len < 1)
> + return -EINVAL;
> +
> + err = skb_copy_bits(skb, rxm->offset, &hs_type, 1);
> + if (err < 0)
> + return err;
> +
> + if (hs_type == TLS_HANDSHAKE_KEYUPDATE) {
> + struct tls_sw_context_rx *rx_ctx = ctx->priv_ctx_rx;
> +
> + WRITE_ONCE(rx_ctx->key_update_pending, true);
> + }
> +
> + return 0;
> +}
> +
> static int tls_rx_one_record(struct sock *sk, struct msghdr *msg,
> struct tls_decrypt_arg *darg)
> {
> @@ -1739,6 +1769,10 @@ static int tls_rx_one_record(struct sock *sk, struct msghdr *msg,
> rxm->full_len -= prot->overhead_size;
> tls_advance_record_sn(sk, prot, &tls_ctx->rx);
>
> + err = tls_check_pending_rekey(tls_ctx, darg->skb);
> + if (err < 0)
> + return err;
Sorry if I already asked this, is this 100% safe to error out from here
after we decrypted the record? Normally once we successfully decrypted
and pulled the message header / trailer we always call tls_rx_rec_done()
The only reason the check_pending_rekey() can fail is if the message is
mis-formatted, I wonder if we are better off ignoring mis-formatted
rekeys? User space will see them and break the connection, anyway.
Alternatively - we could add a selftest for this.
next prev parent reply other threads:[~2024-12-04 3:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-14 15:50 [PATCH net-next v4 0/6] tls: implement key updates for TLS1.3 Sabrina Dubroca
2024-11-14 15:50 ` [PATCH net-next v4 1/6] tls: block decryption when a rekey is pending Sabrina Dubroca
2024-12-04 3:47 ` Jakub Kicinski [this message]
2024-12-10 16:16 ` Sabrina Dubroca
2024-12-10 23:33 ` Jakub Kicinski
2024-12-05 12:30 ` Parthiban.Veerasooran
2024-11-14 15:50 ` [PATCH net-next v4 2/6] tls: implement rekey for TLS1.3 Sabrina Dubroca
2024-12-04 3:58 ` Jakub Kicinski
2024-11-14 15:50 ` [PATCH net-next v4 3/6] tls: add counters for rekey Sabrina Dubroca
2024-12-04 3:54 ` Jakub Kicinski
2024-12-05 11:29 ` Sabrina Dubroca
2024-11-14 15:50 ` [PATCH net-next v4 4/6] docs: tls: document TLS1.3 key updates Sabrina Dubroca
2024-12-04 3:51 ` Jakub Kicinski
2024-12-05 11:06 ` Sabrina Dubroca
2024-12-06 0:34 ` Jakub Kicinski
2024-11-14 15:50 ` [PATCH net-next v4 5/6] selftests: tls: add key_generation argument to tls_crypto_info_init Sabrina Dubroca
2024-11-14 15:50 ` [PATCH net-next v4 6/6] selftests: tls: add rekey tests Sabrina Dubroca
2024-11-19 3:41 ` [PATCH net-next v4 0/6] tls: implement key updates for TLS1.3 Jakub Kicinski
2024-12-03 16:16 ` Sabrina Dubroca
2024-12-04 4:02 ` Jakub Kicinski
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=20241203194701.48e74c8e@kernel.org \
--to=kuba@kernel.org \
--cc=apoorvko@amazon.com \
--cc=borisp@nvidia.com \
--cc=fkrenzel@redhat.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--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.