netdev - Re: [PATCHv2 RFC net-next 0/7] net: dst

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]

Date:   Mon, 30 Jan 2017 10:13:39 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     ja@....bg
Cc:     netdev@...r.kernel.org, linux-sctp@...r.kernel.org,
        yuehaibing@...wei.com
Subject: Re: [PATCHv2 RFC net-next 0/7] net: dst_confirm replacement

From: Julian Anastasov <ja@....bg>
Date: Sat, 28 Jan 2017 16:26:11 +0200

> 	This patchset addresses the problem of neighbour
> confirmation where received replies from one nexthop
> can cause confirmation of different nexthop when using
> the same dst. Thanks to YueHaibing <yuehaibing@...wei.com>
> for tracking the dst->pending_confirm problem.
> 
> 	Sockets can obtain cached output route. Such
> routes can be to known nexthop (rt_gateway=IP) or to be
> used simultaneously for different nexthop IPs by different
> subnet prefixes (nh->nh_scope = RT_SCOPE_HOST, rt_gateway=0).
> 
> 	At first look, there are more problems:
> 
> - dst_confirm() sets flag on dst and not on dst->path,
> as result, indication is lost when XFRM is used
> 
> - DNAT can change the nexthop, so the really used nexthop is
> not confirmed
> 
> 	So, the following solution is to avoid using
> dst->pending_confirm.

For the most part this series looks good to me, nice work.

> - I failed to understand the CXGB* code, I see dst_confirm()
> calls but I'm not sure dst_neigh_output() was called. For now
> I just removed the dst->pending_confirm flag and left all
> dst_confirm() calls there. Any better idea?

It is trying to manage the dst and neigh state for TCP connections
managed by it's offload engine.  So you will not therefore see any
actual packet output for the sessions it is performing confirmation
for.