netdev - Re: [PATCH net-next] net: Remove VRF change to udp

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, 31 Aug 2015 10:58:17 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	David Ahern <dsa@...ulusnetworks.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Shrijeet Mukherjee <shm@...ulusnetworks.com>
Subject: Re: [PATCH net-next] net: Remove VRF change to udp_sendmsg

On Mon, Aug 31, 2015 at 10:40 AM, David Ahern <dsa@...ulusnetworks.com> wrote:
> Hi Tom:
>
> On 8/31/15 11:22 AM, Tom Herbert wrote:
>>
>> It's a major departure from current convention. The source address of
>> the packet should be set before doing ip_send_skb. In UDP unconnected
>> case ip_route_output_flow calls inet_select_addr. AKAIK there is no
>> provision for not setting the source address and relying on the output
>> device to do this in its transmit routine. I still think it would be
>> better to call into the VRF device from inet_select_addr using an ndo
>> function.
>
>
> I was not disregarding your suggestion and definitely appreciate the advice.
> I will look into it in time. In fact I was looking at how to better
> encapsulate FIB oif changes (e.g., with ndo) on the plane home yesterday,
> but those take time and seem more appropriate for 4.4.
>
> My intention with this patch is to reign in the VRF footprint and by
> extension impact for 4.3 without losing functionality. During the merge
> window for 4.3 net-next will be closed and it provides a good time to
> investigate abstractions like ndo handlers.
>
Personally, I would opt to keep the existing patches as they are until
the underlying abstraction issues can be properly addressed. Turning
this into some sort of NAT problem for expediency doesn't seem like
the right approach.

Tom

> David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html