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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 27 Sep 2014 15:29:58 +0200 From: Hannes Frederic Sowa <hannes@...essinduktion.org> To: David Ahern <dsahern@...il.com>, "Eric W. Biederman" <ebiederm@...ssion.com> Cc: nicolas.dichtel@...nd.com, netdev@...r.kernel.org Subject: Re: VRFs and the scalability of namespaces Hi, On Sat, Sep 27, 2014, at 00:37, David Ahern wrote: > The Linux kernel needs proper VRF support -- as an L3 concept. A > capability to run a process in a "VRF any" context provides a resource > efficient solution where a single process with a single listen socket > works across all VRFs in a namespace and then connected sockets have a > specific VRF context. In case you want to have full blown VRF support as in BGP-MPLS-VRF setups I agree that namespaces seem to be not the right tool for the job, even not closely. Although if those namespaces get split up in a more lightweight routing/forwarding namespace and the normal full blown network namespace it seems to be too cumbersome for user space to manage those. Did you already did an investigation how maybe the rule and table features could be exploited to suite your needs? Some time back I suggested something like "ip route table foo exec ....", keep an default routing lookup indicator in task_struct which gets implicitly propagated to rtnetlink routing table requests/modification for the requested table. Tables already can be specified via rtnetlink, so no change would be needed here. For sockets something like SO_BINDTOTABLE might work, maybe even we can by default use the task_struct information to also bind the sockets to the per-process table. We certainly need to preserve the routing information on the socket as we need those in icmp error handling (e.g. where to apply ipv4/ipv6 redirects too). Directing incoming packets to specific table also works via ip-rule-iif match. Advantage with the ip route table foo exec... method would be, that conversion of some unmodified routing management daemons might be easier, others can either use rtnetlink extended attributes which are already available, and we only need to have per-process context routing table control, which seems not too hard to implement in ip-rule subsystem, but I haven't checked. The problem I see with rules is that some of those tables already work hand in hand, they already have a implicit semantics, e.g. local, main, default and unspec (this is even worse for IPv6, where addrconf already uses hardcoded tables). Working around this might be very tricky and even more problematic to do from user space. I think I am not yet sure what features you want from VRFs, some things seem to match the rule/table features but others I think are pretty hard to implement. I worry a bit about icmp error handling and updates of the routing table, but this is a detail we can look into later if all needed features are known. Bye, Hannes -- 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
Powered by blists - more mailing lists