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: <20160225.143106.1173673610254814867.davem@davemloft.net>
Date:	Thu, 25 Feb 2016 14:31:06 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	kouya@...fujitsu.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] ipv4: do not cache local route when using
 SO_BINDTODEVICE

From: Kouya Shimura <kouya@...fujitsu.com>
Date: Tue, 23 Feb 2016 14:27:32 +0900

> After v3.6, output routes are cached, however, the 'rt_iif' field of
> struct rtable can not be shared by various traffics using SO_BINDTODEVICE.
> It causes that traffic can not reach the local receiver which also uses 
> SO_BINDTODEVICE after another traffic creates a local route cache. 
> 
>   /* sender and receiver are running on same host. */
>   sender:
>     - socket(SOCK_DGRAM)
>     - setsockopt(SO_BINDTODEVICE, "eth0")
>     - connect(INADDR_ANY)
>     - send("message") ------>[loopback]------+
>                                              |
>   receiver:                                  |
>     - socket(SOCK_DGRAM)                     |
>     - setsockopt(SO_BINDTODEVICE, "eth0")    |
>     - bind(INADDR_ANY)                       |
>     - recv()  <------------------------------+
>       /* sometimes reach, sometimes not reach!!! */
> 
> Before v3.6, above traffics always reached. It seems to be a
> regression. Actually the 'dhcp_release' command relies on it.
> 
> Commit 7bd86cc282a458b66c41e3f6 ("ipv4: Cache local output routes")
> originated this issue. Revert it conditionally.
> 
> Signed-off-by: Kouya Shimura <kouya@...fujitsu.com>

I strongly fear that this will cause a performance regression for some important
cases.  If you elide the cache, it means that every route lookup has to allocate,
create, and destroy the cache object.  This is really expensive.

There has to be a better way to do so, so I'm not applying this patch, sorry.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ