netdev - Re: [PATCH net-next 4/4] net/tls: byte swap device req TCP seq no upon setting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ae640b1070dca16b318c314a77e824ff18b8aed1.camel@mellanox.com>
Date:   Thu, 25 Apr 2019 19:31:51 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "davem@...emloft.net" <davem@...emloft.net>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>
CC:     "daniel@...earbox.net" <daniel@...earbox.net>,
        "davejwatson@...com" <davejwatson@...com>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>,
        Boris Pismenny <borisp@...lanox.com>,
        "john.fastabend@...il.com" <john.fastabend@...il.com>,
        Aviad Yehezkel <aviadye@...lanox.com>,
        "alexei.starovoitov@...il.com" <alexei.starovoitov@...il.com>,
        "simon.horman@...ronome.com" <simon.horman@...ronome.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 4/4] net/tls: byte swap device req TCP seq no
 upon setting

On Thu, 2019-04-25 at 09:56 -0700, Jakub Kicinski wrote:
> To avoid a sparse warning byteswap the be32 sequence number
> before it's stored in the atomic value.  While at it drop
> unnecessary brackets and use kernel's u64 type.
> 
> Signed-off-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Reviewed-by: Reviewed-by: Simon Horman <simon.horman@...ronome.com>
> ---
>  include/net/tls.h    | 2 +-
>  net/tls/tls_device.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/net/tls.h b/include/net/tls.h
> index 41a2ee643fc5..39ea62f0c1f6 100644
> --- a/include/net/tls.h
> +++ b/include/net/tls.h
> @@ -562,7 +562,7 @@ static inline void
> tls_offload_rx_resync_request(struct sock *sk, __be32 seq)
>  	struct tls_context *tls_ctx = tls_get_ctx(sk);
>  	struct tls_offload_context_rx *rx_ctx =
> tls_offload_ctx_rx(tls_ctx);
>  
> -	atomic64_set(&rx_ctx->resync_req, ((((uint64_t)seq) << 32) |
> 1));
> +	atomic64_set(&rx_ctx->resync_req, ((u64)ntohl(seq) << 32) | 1);
>  }
>  
>  
> diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
> index cb368efe3567..6686013b4e9e 100644
> --- a/net/tls/tls_device.c
> +++ b/net/tls/tls_device.c
> @@ -567,7 +567,7 @@ void (struct sock *sk, u32
> seq, u64 rcd_sn)
>  
>  	rx_ctx = tls_offload_ctx_rx(tls_ctx);
>  	resync_req = atomic64_read(&rx_ctx->resync_req);
> -	req_seq = ntohl(resync_req >> 32) - ((u32)TLS_HEADER_SIZE - 1);
> +	req_seq = (resync_req >> 32) - ((u32)TLS_HEADER_SIZE - 1);

this is not equivalent to what was before, 
resync_req is expected to be in network order, 
(TLS_HEADER_SIZE -1) is still in cpu indianness.


>  	is_req_pending = resync_req;
>  
>  	if (unlikely(is_req_pending) && req_seq == seq &&