linux-kernel - Re: [PATCH net-next v3 2/2] net/smc: support ipv4 mapped ipv6 addr client for smc-r v2

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: <1fc33d2e-83c1-4651-b761-27188d22fba0@linux.ibm.com>
Date: Mon, 9 Dec 2024 15:10:56 +0100
From: Wenjia Zhang <wenjia@...ux.ibm.com>
To: Guangguan Wang <guangguan.wang@...ux.alibaba.com>, pasic@...ux.ibm.com,
        jaka@...ux.ibm.com, alibuda@...ux.alibaba.com,
        tonylu@...ux.alibaba.com, guwen@...ux.alibaba.com, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
        horms@...nel.org
Cc: linux-rdma@...r.kernel.org, linux-s390@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Dust Li <dust.li@...ux.alibaba.com>
Subject: Re: [PATCH net-next v3 2/2] net/smc: support ipv4 mapped ipv6 addr
 client for smc-r v2



On 09.12.24 14:06, Guangguan Wang wrote:
> AF_INET6 is not supported for smc-r v2 client before, even if the
> ipv6 addr is ipv4 mapped. Thus, when using AF_INET6, smc-r connection
> will fallback to tcp, especially for java applications running smc-r.
> This patch support ipv4 mapped ipv6 addr client for smc-r v2. Clients
> using real global ipv6 addr is still not supported yet.
> 
> Signed-off-by: Guangguan Wang <guangguan.wang@...ux.alibaba.com>
> Reviewed-by: Wen Gu <guwen@...ux.alibaba.com>
> Reviewed-by: Dust Li <dust.li@...ux.alibaba.com>
> Reviewed-by: D. Wythe <alibuda@...ux.alibaba.com>
> Reviewed-by: Wenjia Zhang <wenjia@...ux.ibm.com>
> ---
>   net/smc/af_smc.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 9d76e902fd77..c3f9c0457418 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -1116,7 +1116,10 @@ static int smc_find_proposal_devices(struct smc_sock *smc,
>   	ini->check_smcrv2 = true;
>   	ini->smcrv2.saddr = smc->clcsock->sk->sk_rcv_saddr;
>   	if (!(ini->smcr_version & SMC_V2) ||
> -	    smc->clcsock->sk->sk_family != AF_INET ||
> +#if IS_ENABLED(CONFIG_IPV6)
> +	    (smc->clcsock->sk->sk_family == AF_INET6 &&
> +	     !ipv6_addr_v4mapped(&smc->clcsock->sk->sk_v6_rcv_saddr)) ||
> +#endif
>   	    !smc_clc_ueid_count() ||
>   	    smc_find_rdma_device(smc, ini))
>   		ini->smcr_version &= ~SMC_V2;

@Guangguan, I think Halil's point is valid, and we need to verify if 
checking on saddr is sufficient before this patch is applied. i.e. what 
about one peer with ipv4 mapped ipv6 communicates with another peer with 
a real ipv6 address? Is it possible? If yes, would SMCRv2 be used? I 
still haven't thought much on this yet, but it is worth to verify. Maybe 
you already have the answer?

@Jakub, could you please give us some more time to verify the issue 
mentioned above?

Thanks,
Wenjia