From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D90DEB64DD for ; Sat, 12 Aug 2023 01:37:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236089AbjHLBh4 (ORCPT ); Fri, 11 Aug 2023 21:37:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229573AbjHLBh4 (ORCPT ); Fri, 11 Aug 2023 21:37:56 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB0463580 for ; Fri, 11 Aug 2023 18:37:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 83A7C64389 for ; Sat, 12 Aug 2023 01:37:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 451E3C433C7; Sat, 12 Aug 2023 01:37:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691804274; bh=Y3jlMG7U38Uvwq9s8XM0hS54dhwwvJi9rI3hlZA/GwI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VdN+8WRIQQxtvmjwzfT7j1VOMGnph7TNmRcEOh4aQLRZCCkVy3IAZpsz+LWNMGCfg JbrSTIuEDEhfRG3NzmXqZg6hPXzstIu/bYrKC59z5Z9pb2SlSrvCpoG5dCDpn23dw4 X0iySDDTK3MYwAOQIAA4/upzUGDOouZIulxQnkzOrGgmeA3Fxvr06Wg7e2nRm8UVWx xldYuIePbx+G3NN86+HPaeNpzq/6/JG1GVhzhNaCkPVjoGUxJ8nS+o9AYGRMlnrw8D x6kdbi6MCRP8i7cmKcYZZHfftrQHtG/kc8MUK3yU/jWNVn6+ukfAhz4Fnx+FCpVuj9 P/ZnfDEvYyOPQ== Date: Fri, 11 Aug 2023 18:37:53 -0700 From: Jakub Kicinski To: Sabrina Dubroca Cc: netdev@vger.kernel.org, Vadim Fedorenko , Frantisek Krenzelok , Kuniyuki Iwashima , Apoorv Kothari , Boris Pismenny , John Fastabend , Shuah Khan , linux-kselftest@vger.kernel.org, Gal Pressman , Marcel Holtmann Subject: Re: [PATCH net-next v3 2/6] tls: block decryption when a rekey is pending Message-ID: <20230811183753.3a18a09a@kernel.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On Wed, 9 Aug 2023 14:58:51 +0200 Sabrina Dubroca wrote: > +static int tls_check_pending_rekey(struct sock *sk, struct sk_buff *skb) > +{ > + const struct tls_msg *tlm = tls_msg(skb); > + const struct strp_msg *rxm = strp_msg(skb); > + > + if (tlm->control == TLS_RECORD_TYPE_HANDSHAKE) { unlikely() does the nachine code look worse if we flip the condition and return early instead of indenting the entire function? > + char hs_type; > + int err; I'd probably err on the side of declaring those on the outside, but if we don't we should move rxm in here, it's not needed outside. Either, or. > + 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_context *ctx = tls_get_ctx(sk); feels a bit like we should just pass ctx rather than sk? > + struct tls_sw_context_rx *rx_ctx = ctx->priv_ctx_rx; > + > + rx_ctx->key_update_pending = true; > + } > + } > + > + return 0; > +}